LEARN. PRACTICE. GROW.Bind the plan to the state being changed
A delivery including database changes must identify more than the application version. Record the schema artifact, publishing properties, target and state used to prepare the plan. DeployReport describes proposed changes; DriftReport describes differences from a registered database’s registration. Neither proves the change executed. A reviewed SQL script also stops being sufficient evidence if the target has materially changed since analysis. In the exercise, D4 was analyzed against S0, but an attempt left S1 and committed a rule. The next decision begins by observing S1 and applied effects. Do not substitute the pipeline’s failed result for that observation or conclude that the target remains at S0. Approval should refer to the applicable change, including the assumptions that make its execution valid.
Interpret safeguards without adding guarantees
BlockOnPossibleDataLoss can stop a schema change even on an empty table. Disabling it does not transform incompatible values or establish that the change is accepted. Analyze the identified risk and data handling before choosing the property. Removal options also have scope: DoNotDropObjectTypes=Tables protects an object type, not just Archive. If TempImport must disappear, the broad exception does not express the complete intent. Review the resulting plan and separate retention decisions from authorized cleanup. IncludeTransactionalScripts uses transactions where possible without automatically including instructions sent to a partner by another step. For Azure SQL Database, do not use BackupDatabaseBeforeChanges as recovery evidence because the option does not apply. The plan needs a mechanism and evidence appropriate to the service and available window.
Review scripts outside the model
A pre-script executes before the plan, but the plan has already been calculated before that execution. Changing schema in the pre-script can therefore invalidate comparison assumptions. Pre- and post-deployment scripts are included in the dacpac but are not compiled or validated with the object model. A successful build does not replace reviewing them. In the R7 example, the post-script performs an INSERT with a unique key; a second execution finds an existing row. Define expected behavior when the row is absent, already has the correct value or has a different value. An existence check can prevent duplication while still concealing value drift. The procedure should observe and reconcile that state, retaining evidence of the decision and authorized changes. Repeatability requires a defined outcome, not merely suppressing an error.
Choose a verifiable migration strategy
A non-idempotent EF script starts from a known migration state. If M2 is last applied and M4 is the goal, the range starts at M2. An idempotent script on a supported provider consults history to apply missing migrations. That history does not automatically detect a column manually removed after M4. Bundles simplify transport and execution; a suitable self-contained bundle can remove SDK and source requirements from the agent. However, it does not replace reviewed SQL when that is a delivery condition. Keep the artifact, script and accepted inputs aligned. Explicitly set environment and target connection, and supply non-secret files read by the context. A job named Production does not establish that its process received production configuration. Confirm the resolved target before authorizing changes.
Separate serialization, compatibility and recovery
EF Core 9 and later migration locking protects concurrent migration execution. It does not establish that an old application instance keeps working while schema changes. Rehearsing version coexistence, controlling schema privileges and ordering dependencies remain team decisions. An application should not receive additional privileges merely because startup can run a migration. Consider a separate step when review and availability require it. Also distinguish Down from data restoration: recreating an empty column does not restore removed values. In a partial-failure case, identify commits, consumed rules and external effects before repeating work. Reviewed continuation may be appropriate, as may authorized recovery; both must demonstrate intended state and data that must be preserved. A successful command alone does not establish the business outcome.
Read rollout state for the intended revision
In Kubernetes, Available can remain true because of old Pods while the new revision fails to progress. Read conditions alongside updated replicas, template identity and functional results. ProgressDeadlineExceeded does not automatically roll back through the Deployment controller. Recovery decisions must be explicit. For three replicas and 25% limits, maxUnavailable rounds to zero and maxSurge to one. If there is no extra capacity, do not count on removing a healthy Pod first to create space. minReadySeconds requires sustained readiness before counting a replica as available. Changing only an annotation outside spec.template does not start a new revision. Finally, confirm history retention: a revision number whose ReplicaSet was removed cannot recover the template through rollout undo without another preserved definition. Capacity, progress and acceptance answer different questions.
Validate effective feature-flag decisions
An enabled=true flag with audience and time-window filters needs requirement_type=All when both are mandatory. Any, the Microsoft schema default, permits one true filter. In targeting, an exclusion takes precedence over membership in an enabled ring. Use boundary cases to verify intended behavior, including an excluded user and a request outside the window. If two components within one request must retain the first decision, the snapshot provides consistency within that scope; it does not freeze values across every instance. Also confirm which flags are loaded: parameterless UseFeatureFlags selects unlabelled flags. A production filter for ordinary key-values does not establish selection of a flag with that label. Before attributing the result to filters, verify that the provider loaded the correct definition. Selection and evaluation are separate diagnostic steps.
Decide promotion with per-instance evidence
In the example, the new revision exceeded its deadline and an idle instance retains FeesV2 enabled despite the portal change. The documented middleware refreshes configuration in response to requests and respects the refresh interval; the request triggering asynchronous refresh can still see earlier values. Do not present a portal save as confirmation across every instance. Keep exposure contained, investigate progress and confirm configuration actually loaded and evaluated. Use the fictional records below to write a three-part decision: criterion, observed evidence and missing work. Explain an acceptable alternative and a condition for deferral. The exercise runs no SQL, Kubernetes or Azure; it practises interpretation. A real rehearsal should identify versions, configuration, identities and results without turning a course example into a bank’s internal procedure.
{
"exercise": "fictional-delivery-review",
"database": {
"approvedPlanTargetState": "S0",
"observedTargetState": "S1",
"schemaChangeCommitted": true,
"ruleR7Committed": true,
"postScriptResult": "failed"
},
"deployment": {
"intendedRevision": 8,
"availableOldPods": 3,
"availableNewPods": 0,
"conditions": {
"Available": true,
"Progressing": false,
"reason": "ProgressDeadlineExceeded"
}
},
"featureFlag": {
"id": "FeesV2",
"portalEnabled": false,
"instanceAObservedEnabled": false,
"instanceBObservedEnabled": true,
"instanceBRefreshMode": "request-driven",
"instanceBHasReceivedNewRequest": false
},
"acceptance": {
"requiresApplicableReviewedDatabasePlan": true,
"requiresNewRevisionStable": true,
"requiresFlagOffOnEveryInstance": true,
"approvedException": false
}
}A SQL rule committed before failure; in another stage, old Pods maintain availability while the new revision fails and a flag retains earlier state.
Common pitfalls
Treating a plan as execution, failure as rollback, old availability as candidate acceptance and a portal save as completed propagation.
Related topics: Pipeline evidence and artifact identity · Version compatibility and service continuity · Migrations, recovery and RUN handover
Each decision needs evidence of current state and the intended candidate. Technical safeguards have scope and do not replace compatibility, recovery and acceptance criteria.
Reference: SqlPackage deploy report and drift report · AZ-400 objectives 2026-07-27