Day-2 Operations: Maintaining and Evolving Your Azure Landing Zone

Apr 11, 2026 min read
Day-2 Operations: Maintaining and Evolving Your Azure Landing Zone

Deploying your landing zone was the easy part. Now you have to live with it.

The most common failure mode in platform engineering is not a bad initial deployment — it is treating the landing zone as a finished project rather than an ongoing product. Azure releases new services and deprecates old ones. Organizational requirements change. Configuration drift is not a hypothetical risk; it is a certainty. Without an operational strategy that anticipates these pressures, a well-governed environment gradually becomes a collection of special cases and undocumented manual changes. This guide teaches you the habits and technical patterns required to maintain a healthy, evolving foundation.

1. Managing Configuration Drift

Drift takes two forms: IaC State Drift (code vs. actual resources) and Policy Compliance Drift (actual resources vs. security standards).

Automated Drift Remediation Loop

[145...GIS`HTTctURHheMIUerAGBdrNGuaEAlfTRCeoRTdrIRImAEORGMNupEESnlDaI]nA`TION236...[[(OPepoAD.elZrgniUi.cRf,GyEtHSFPDKIiLeUsxAtsTeCu/FcheOtaRReneMdg-eA]])pply7.[[CLGOISTEHDUB]ISSUES]

Run drift scans weekly using terraform plan --refresh-only or Bicep what-if. A scheduled GitHub Actions workflow that opens a GitHub Issue when drift is found provides the audit trail and visibility needed for incident response.

2. Remediating Drift Without Downtime

When drift is detected, you must decide whether to import the manual change into your code or revert the resource to its authorized state.

  • Accepting the change: Use Terraform’s import block to bring a portal-made change into your state file.
  • Rejecting the change: Update your YAML/Bicep logic to the desired state and re-deploy.
  • Policy remediation: Use Remediation Tasks to fix auxiliary resource gaps (like missing logs) without touching the primary resource.
# Example: Bulk remediation of diagnostic settings
az policy remediation create \
  --name "fix-logging-baseline-$(date +%Y%m%d)" \
  --policy-assignment "/providers/Microsoft.Management/managementGroups/mg-intermediate/providers/Microsoft.Authorization/policyAssignments/deploy-vnet-diagnostic-settings" \
  --resource-discovery-mode ReEvaluateCompliance \
  --resource-type "Microsoft.Network/virtualNetworks"

3. The Migration Path: Moving to Azure Verified Modules (AVM)

In 2026, the legacy CAF modules are archived. Migration to AVM is a maintenance requirement. A naive migration destroys and recreates resources, but the Terraform moved block allows you to remap the state address without any physical resource impact.

AVM Module Migration (The moved Block)

[(LTeEgm.RaoaRcdzAyuuFlrOAeeRd.rMdemrn_SetmTsegAsrmT)ptEr_ig]sreo_uspc.aplreod[moved{(Z]eroDe[(sAtRVrEMm.uFoacAAdztCduuiTdlroOreenRe.rsEsmm)Dsg_)mmCtgO_mDgtEr_og]urposu_pa.vtmhis

Bicep Pattern: Use Deployment Stacks to manage the transition. The stack reconciles the template change and updates existing resources in-place rather than replacing them.

4. Governance and Identity Lifecycle

The average landing zone accumulates RBAC cruft faster than any other category. Every quarter, your platform team should perform two key reviews:

  1. Orphaned Role Review: Use PowerShell to find role assignments linked to “Identity not found” (deleted) principals and remove them.
  2. Access Review: Use Entra ID Access Reviews (P2) to force on-call engineers to justify their PIM eligibility every 90 days. A “Deny-by-Inaction” default is the safest posture.

5. Hub Evolution: Scaling to Multi-Region

When you expand to a second Azure region, the decision between Global VNet Peering (for simplicity) and Azure Virtual WAN (for massive scale) is your primary architectural pivot. For most organizations, regional hub-to-hub peering is sufficient for up to 4 regions.

# Adding a secondary hub is additive logic
module "hub_secondary" {
  source = "./modules/hub-networking"
  location = "westeurope"
  address_space = ["10.1.0.0/16"]
  peer_to_hub_id = module.hub_primary.vnet_id
}

Key Takeaways

  1. Platform as a Product: Give your landing zone a roadmap and a dedicated maintenance window.
  2. Weekly Drift Scans: Catch deviations in days, not months.
  3. Remediate via Policy: Avoid manual “Quick Fixes.” Use the policy engine to maintain the audit trail.
  4. Pin Your Versions: Never use latest for AVM modules. Use Renovate or Dependabot to manage upgrades as code.

The Azure Platform Engineering series is complete. You have built a production-ready foundation from scratch, secured it with Zero Trust identity, and established the operational habits to keep it healthy as you scale.

Sources