Resource drift

Understand the concept

In plain English

Resource drift is what happens when the Azure environment no longer matches the design, template, policy, or runbook that teams believe is true. Someone may change a firewall rule in the portal, create a resource outside the pipeline, remove a tag, resize a SKU, or leave behind a resource after migration. The workload may still run, but the source of truth is now unreliable. Drift is not always malicious. It is often the quiet result of urgent fixes, incomplete cleanup, or automation that was never reconciled.

Why it matters

Resource drift matters because trust in the platform depends on knowing what is actually deployed. A security team may believe public access is disabled while a manual exception exists. A FinOps team may forecast costs from templates while someone resized a database. A deployment may fail because a portal change introduced a dependency the template does not know about. Drift also weakens disaster recovery because rebuilding from code will not reproduce the live environment. The impact is slower troubleshooting, unreliable compliance, surprise costs, and risky releases. Treating drift as operational debt gives teams a practical way to reconcile urgent fixes with durable engineering controls.

Technical context

In Azure architecture, resource drift appears across the control plane, governance layer, and operations model. It is detected with Azure Resource Graph, what-if deployments, deployment stacks, Azure Policy compliance, Activity Log, inventory exports, and service-specific configuration checks. Drift can affect tags, SKUs, networking rules, identity assignments, diagnostic settings, locks, private endpoints, and deployed resource counts. It is especially important for infrastructure-as-code platforms because templates may look correct while Azure state has changed. CLI gives operators repeatable discovery, comparison, and evidence export across subscriptions.

Exam context

Compare with

Where it is used

Where you see it

1. In Azure Resource Graph exports, resources appear with unexpected SKUs, missing tags, public access settings, diagnostic gaps, or owner values that do not match the template.
2. In deployment what-if output, resources show modify or delete actions that surprise the team because live Azure state changed after the last approved deployment during review.
3. In Activity Log, manual portal changes, role assignment edits, or automation identity updates reveal when a resource diverged from the expected baseline during incident review.

Common situations

• Find manually created resources before a migration so landing-zone code does not miss hidden dependencies or preserve unmanaged cost.
• Detect public access, firewall, diagnostic, identity, or SKU changes that weaken security and reliability controls after emergency fixes.
• Reconcile what-if differences before redeployment so templates do not overwrite necessary hotfixes or keep outdated settings.
• Identify untagged, orphaned, or scaled-up resources that escaped FinOps ownership and now distort chargeback or forecast reports.
• Use deployment stacks, policy state, and Activity Log evidence to decide whether drift should be deleted, detached, remediated, or codified.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Azure CLI

After ten years of Azure engineering work, I use Azure CLI for drift because drift is an estate-wide question. The portal shows one blade at a time, but CLI can export resources, tags, SKUs, identities, diagnostic settings, locks, and policy states across subscriptions. It also works in scheduled jobs, pull-request checks, and incident reviews. I can compare expected configuration with live output, run what-if before redeployment, and capture Activity Log evidence showing who changed what. For drift, speed and repeatability matter. A scriptable CLI check turns vague suspicion into a concrete list of differences owners can fix without portal guesswork.

az graph query -q "Resources | project id, name, type, resourceGroup, subscriptionId, location, tags, sku=sku.name | order by type asc" --output json

az deployment group what-if --resource-group <resource-group> --template-file main.bicep --parameters @main.bicepparam

az policy state list --filter "ComplianceState eq 'NonCompliant'" --query "[].{resourceId:resourceId,policyAssignmentName:policyAssignmentName,complianceState:complianceState}" --output table

az monitor activity-log list --resource-group <resource-group> --max-events 100 --query "[].{time:eventTimestamp,caller:caller,operation:operationName.value,status:status.value,resource:resourceId}" --output table

az resource show --ids <resource-id> --query "{id:id,name:name,type:type,location:location,tags:tags,identity:identity,sku:sku}" --output json

Architecture context

A seasoned Azure architect treats drift management as part of the platform operating model, not as a one-time cleanup. The intended state may come from Bicep, Terraform, Azure Policy, deployment stacks, landing-zone modules, or approved design records. The actual state comes from Azure Resource Manager, service APIs, policy compliance, and logs. The architecture decision is how strict reconciliation should be. Some drift should be blocked by policy, some should be remediated automatically, and some emergency changes should be tagged, reviewed, and folded back into code. For production systems, drift reviews should focus on controls that change blast radius: public access, identity, SKU, redundancy, diagnostic coverage, locks, and private connectivity.

Security

Security impact is often direct. Drift can quietly reopen public network access, weaken TLS settings, remove diagnostic logs, add broad role assignments, disable Defender plans, or leave unmanaged keys and secrets. The danger is that diagrams, code, and policy dashboards may no longer describe the live attack surface. Drift does not always mean compromise, but it creates blind spots attackers and misconfigurations can exploit. Use Azure Policy, Resource Graph, Activity Log, Defender for Cloud, and CLI evidence to find security-sensitive differences. Emergency exceptions should have expiration, owner, and approval tags. Reconcile accepted changes into infrastructure code so the next deployment does not erase or preserve the wrong state.

Cost

Drift has an indirect but frequent cost impact. A manually scaled database, forgotten premium disk, untagged environment, extra private endpoint, orphaned public IP, or duplicate workspace can survive outside the cost model because the template or naming standard does not mention it. FinOps teams need drift reports that connect live resources to owners, environments, SKUs, and expected lifecycle. Drift can also hide savings opportunities when policy or code says a resource should be smaller than it is. The best cost control is not blind deletion; it is evidence-based reconciliation. Identify the difference, confirm business need, update the source of truth, or remove the resource through an approved cleanup path.

Reliability

Reliability impact is practical and sometimes severe. Drift can remove redundancy, resize capacity, change autoscale rules, alter firewall dependencies, break diagnostic settings, or leave orphaned resources that confuse failover runbooks. It also makes recovery uncertain because redeploying from code may not recreate the environment that was actually running. Reliable operations require a known source of truth and a process for reconciling live exceptions. What-if, deployment stacks, Activity Log, and scheduled inventory checks help identify differences before a change window. Do not automatically overwrite every drift finding; first decide whether it is a harmful mutation, a necessary emergency change, or a template update that was never captured.

Performance

Runtime performance can be affected when drift changes capacity, routing, caching, indexing, or network paths. A portal resize might improve one symptom while creating cost or reliability risk. A changed firewall or private endpoint can add latency or break dependency resolution. Operational performance is also affected because engineers spend longer reconciling reality with templates and diagrams. Drift detection improves troubleshooting speed by answering whether a recent manual change explains the incident. CLI exports and what-if output are especially useful during performance investigations because they reveal configuration differences before teams chase application code. The goal is faster diagnosis and fewer surprises during redeployment.

Operations

Operators handle resource drift by collecting inventory, comparing it against intended state, classifying differences, and assigning remediation owners. The work usually happens during governance reviews, release failures, incident retrospectives, cost cleanup, and migration preparation. CLI and Resource Graph are useful for exporting name, type, location, SKU, tags, locks, identity, and selected configuration fields. Azure Policy shows compliance state, while Activity Log helps explain who changed a resource and when. Good operations practice separates detection from action: first prove the difference, then decide whether to revert, update code, add an exception, or retire the resource. Otherwise drift cleanup becomes another source of outages.

Common mistakes

• Calling every difference bad drift without checking whether it was an approved emergency change waiting to be merged into code.
• Running automatic remediation that deletes or resizes resources before confirming dependencies, owners, rollback path, and business impact.
• Comparing only names and tags while missing security-sensitive drift in network access, diagnostics, identities, and lock configuration.
• Ignoring Activity Log context and blaming the wrong team for drift created by a service principal or platform automation job.
• Letting policy exemptions become permanent drift because nobody assigned an expiration date or reviewed the exception after the incident.