Common Mistakes
These mistakes are not theoretical. They are the ones that create platform debt before the first serious workload is even onboarded — and most of them are far cheaper to avoid than to fix.
Purpose
This page consolidates the most common Azure Landing Zone anti-patterns from across the series into a single, actionable checklist.
Design Reasoning
Most landing zone problems are not caused by a missing service. They are caused by scope, ownership, guardrails, and operating responsibilities being unclear from the beginning. When management groups copy the org chart, RBAC is assigned directly to users, DNS is unplanned, or logging is not standardized, the debt starts accruing before anyone notices.
Architecture Decision Record
| Decision | Choice | Rationale |
|---|---|---|
| How this page is used | As an action list, not a passive reference | The value is in checking the estate against it — twice: before the first production workload, and again after months of operation. |
Recommended Configuration
| Mistake | Why it is a problem | Better approach |
|---|---|---|
| Treating ALZ as only a management group tree | Ignores platform capabilities (identity, network, logging, governance) | Use the platform plus application landing zone model |
| Putting everything in one subscription | Blurs ownership, cost, policy, and security boundaries | Split by purpose, isolation, and ownership |
| Assigning RBAC directly to users | Creates audit and joiner/mover/leaver problems | Use groups and PIM |
| No DNS plan for private endpoints | Private endpoint deployments become unreliable | Design private DNS zones and resolver patterns early |
| Leaving policies in audit mode forever | Provides visibility but no real guardrail | Use a lifecycle from audit to enforcement |
| No exemption lifecycle | Leads to undocumented exceptions and shadow IT | Use formal exemptions with owners and expiry dates |
| No centralized logging | Creates operational blind spots | Use a management subscription and a central Log Analytics workspace |
| Blindly copying the reference architecture | Creates complexity nobody owns | Document intentional design decisions and deviations |
| No workload onboarding process | Produces inconsistent subscriptions | Use subscription vending and product lines |
| No operating cadence | The platform drifts after deployment | Define reviews, ownership, and change management |
Example Implementation
Turn the table into a review workshop. For each row, ask:
- Do we have this issue today?
- Which scope is affected?
- Who owns the fix?
- Can it be fixed through Infrastructure as Code?
- Is there a target date?
- Does the fix require a policy, RBAC, network, or process change?
For tenant-wide visibility into management groups, policy, and RBAC while you run this review, the Azure Governance Visualizer (AzGovViz) can document and inspect governance configuration across the tenant.
Validation Steps
- Run the workshop above before onboarding the first production workload, and record the answers.
- Re-run it after the platform has been operating for several months — different mistakes surface once real workloads are present.
- Confirm each identified issue has an owner and a target date, not just a description.
Common Mistakes
The biggest mistake with a “common mistakes” page is treating it as a passive reference. It is an action list. If nothing changes after reading it, it has not done its job.