# Azure Landing Zone Architecture Operations

Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.

## What people get wrong

- Drawing a management-group tree before clarifying operating model and ownership.
- Treating a landing-zone accelerator deployment as proof that governance is complete.
- Putting every workload under one subscription because it is simpler today.
- Ignoring identity, security, monitoring, backup, policy, and cost baselines in a network-only design.
- Copying hub-spoke without proving routing, DNS, inspection, and shared-service ownership.

## Officially grounded service shape

Microsoft Learn evidence says Azure landing zones are platform foundations spanning platform and application landing zones, management groups, subscriptions, policy inheritance, connectivity, identity, governance, security, management, and platform automation. The design-areas guidance explicitly calls out billing/tenant, identity/access, resource organization, network topology/connectivity, security, management, governance, and platform automation/DevOps as decisions that affect the foundation.

- A landing zone separates platform shared services from application landing zones while preserving governance and autonomy.
- Management-group and subscription design control policy inheritance, RBAC scope, chargeback, quota, and blast radius.
- The platform needs identity/access, governance, management, security, network connectivity, and automation decisions before workload scale.
- Application landing zones need guardrails but must still let workload teams operate within defined boundaries.
- Implementation options are starting points; documented design areas must be tailored to business and technical requirements.

## Non-negotiable design rules

- Start with design areas and decision records, not tooling preference.
- Require explicit ownership for platform subscriptions, application subscriptions, policies, connectivity, monitoring, and incident response.
- Prefer least-privilege and subscription democratization with policy guardrails over central bottlenecks or unmanaged autonomy.
- Document exceptions, inheritance boundaries, and migration path for brownfield environments.
- Never claim production readiness without current-state evidence and operational ownership.

## Minimal safe implementation flow

- Scope business units, environments, regulatory boundaries, connectivity model, identity model, and platform-team responsibilities.
- Map current or proposed management groups, subscriptions, policy inheritance, RBAC, and shared services.
- Evaluate each landing-zone design area for missing decisions and unsafe coupling.
- Rank architecture gaps by blast radius and irreversibility: tenant, management group hierarchy, connectivity, policy, identity, and logging first.
- Return a staged target architecture with blockers, decision points, and safe next actions.

## High-risk assumptions to kill

- A management-group diagram is not a landing zone unless identity, governance, network, security, management, cost, and automation decisions are explicit.
- Deploying an accelerator is not proof that the operating model, ownership, exceptions, and brownfield migration risks are solved.
- Subscription democratization fails if application teams get autonomy without inherited guardrails, monitoring, budget visibility, and recovery boundaries.
- Hub-spoke is not automatically correct; routing, DNS, inspection, private access, shared-service ownership, and failure domains decide fitness.
- Broad platform Owner assignments and shared identities destroy the very blast-radius boundaries landing zones are meant to create.

## Safe command/code verification targets

- Inspect architecture docs or IaC for management group hierarchy, platform/application subscription split, environment isolation, and policy inheritance.
- Review role-assignment patterns for group-based least privilege, PIM/JIT where appropriate, and separation between platform and application responsibilities.
- Check networking artifacts for hub/spoke or alternative topology, DNS, egress inspection, private endpoint strategy, route tables, and connectivity ownership.
- Verify governance, security, management, backup, cost, and diagnostic baselines are assigned at intentional scopes with exception handling.
- Confirm subscription vending or onboarding automation can repeatedly create governed landing zones without hard-coded tenant-specific secrets or one-off manual grants.

## Safe verification targets

- Management group and subscription model supports platform/application separation and environment isolation.
- Policy, RBAC, diagnostic, security, cost, and backup baselines are inherited where intended.
- Connectivity design includes routing, DNS, private access, inspection, and failure domains.
- Subscription vending or onboarding process can produce repeatable, governed application landing zones.
- Brownfield migration steps avoid breaking existing workloads and preserve rollback options.

## When to push back

- The user wants Terraform/Bicep before design decisions are made.
- The architecture depends on broad permanent Owner assignments.
- Shared services have no owner, budget, monitoring, or recovery model.
- A single subscription or network boundary is hiding compliance, quota, or blast-radius problems.

# Documentation and Evidence Path

## Preferred evidence order

1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
2. Sampled read-only Azure or Kubernetes evidence, when safely available, for current configured-environment observations.
3. Sanitized user-provided evidence.
4. Clearly labeled inference.

## What each evidence type can prove

- Microsoft Learn documentation can prove documented service behavior, supported concepts, and recommended patterns.
- Sampled read-only evidence can prove the sampled configured state at the time observed.
- Sanitized user evidence can prove only what the snippet shows.
- None of these alone prove broad regional availability, future success, full account posture, or production readiness.

## Safe usage pattern

- State whether each claim is documentation-based, sampled-current-state, user-provided, or inference.
- Use read-only queries before recommending changes.
- Do not include sensitive internal identifiers, tenant identifiers, subscription identifiers, or secrets in committed docs or final findings.
- If no sampled evidence is available, say the review is documentation-based and list the exact evidence still needed.

## Asset guidance

Use Microsoft Learn documentation through the user's configured documentation MCP for documented landing-zone design areas and patterns. Use sampled read-only Azure evidence only to inspect current hierarchy, policies, RBAC, resources, and diagnostics, and label it as sampled evidence.

# Official Sources

Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, RBAC, quotas, deployed resources, or production readiness.

## Primary Microsoft Learn sources

- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/
- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-areas
- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access
- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance
- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/security
- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/management
- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/platform-automation-devops
- https://learn.microsoft.com/azure/architecture/networking/architecture/hub-spoke

## Grounding notes

- Documentation-based claim: Microsoft Learn evidence says Azure landing zones are platform foundations spanning platform and application landing zones, management groups, subscriptions, policy inheritance, connectivity, identity, governance, security, management, and platform automation. The design-areas guidance explicitly calls out billing/tenant, identity/access, resource organization, network topology/connectivity, security, management, governance, and platform automation/DevOps as decisions that affect the foundation.
- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
- Inference: allowed only when labeled and tied to observed fields or documented behavior.
- Do not include sensitive internal identifiers or secret material in findings.

## Source use rules

- Prefer Microsoft Learn documentation through the user's configured documentation MCP for current Azure service behavior.
- Use sampled read-only Azure evidence only to validate current configured-environment observations.
- If documentation and sampled evidence appear to conflict, report both and stop short of a production-ready verdict.
- Re-check official sources before changing high-risk guidance, because cloud behavior and feature availability can change.

# Safety Checklist

## Evidence labels

- `documentation-based`: grounded in Microsoft Learn or official Kubernetes documentation where listed.
- `sampled-current-state`: grounded in read-only Azure or Kubernetes observations from the user's configured tools.
- `user-provided`: grounded in sanitized snippets supplied by the user.
- `inference`: reasoned from evidence but not directly proven.

## Mutation boundary

- Default to read-only review.
- Do not perform create, update, delete, rotate, purge, recover, apply, restart, drain, cordon, scale, rollout, role-assignment, policy-assignment, or network changes unless the user explicitly asks and approval is clear.
- Prefer preview, dry-run, status, describe, what-if, list, show, and policy evaluation evidence before any mutation.

## Credential and data boundary

- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, kubeconfig contents, CA requester credentials, secret values, or connection strings.
- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.

## Risk gates

- Stop on ambiguous target, ambiguous principal, missing approval, missing rollback, or missing owner for high-impact assets.
- Treat broad permissions, permanent privileged access, public exposure, purge authority, destructive operations, and live rollout changes as high-risk.
- Separate documented product behavior from sampled configured-environment evidence.

## Asset-specific hard line

Do not prescribe a one-size-fits-all hierarchy, broad admin grants, or production-ready verdict without identity, governance, security, management, network, subscription, cost, and recovery dependencies being addressed.

# Workflow and Output Contract

## Execution flow

1. Scope the exact asset, environment boundary, owner, and requested decision.
2. Load `official-sources.md`, then the component operations guide for service behavior and risk gates.
3. Gather sampled read-only evidence only when available and safe.
4. Compare observed posture against documented behavior, least-privilege expectations, and operational safety rules.
5. Return a verdict with evidence level, blockers, safe next actions, and open questions.

## Required output

- `verdict`: pass, warn, fail, or blocked.
- `evidence_level`: documentation-based, sampled-current-state, user-provided, inference, or mixed.
- `scope`: what was reviewed and what was not reviewed.
- `blockers`: issues that prevent a safe or production-ready conclusion.
- `findings`: severity-labeled risks with source labels.
- `safe_next_actions`: reversible actions first; mutation only with explicit approval.
- `open_questions`: missing facts that would change the verdict.

## Stress checks

- What assumption would make this recommendation unsafe?
- Which role, policy, network, lifecycle, or rollout action has the largest blast radius?
- What evidence would disprove the claimed readiness?
- Is the answer accidentally treating documentation as tenant-specific proof?

## Response discipline

Use Microsoft Learn documentation through the user's configured documentation MCP for documented landing-zone design areas and patterns. Use sampled read-only Azure evidence only to inspect current hierarchy, policies, RBAC, resources, and diagnostics, and label it as sampled evidence.