Azure Landing Zone Checklist

Azure Landing Zone Checklist Skill

This skill guides you through filling out the Microsoft Azure Landing Zone (ALZ) Accelerator checklist — the spreadsheet that captures all decisions needed before deploying an ALZ using Bicep or Terraform via the ALZ Accelerator tool.

The goal is to produce a filled Excel checklist where every decision is justified, best practices are applied by default, and items requiring human input are clearly flagged for the user's attention.

Why this matters

The ALZ Accelerator checklist is the single source of truth for a platform landing zone deployment. Getting it wrong means misconfigured networking, security gaps, or hours of rework. This skill ensures consistency by applying Microsoft's Cloud Adoption Framework (CAF) recommendations while respecting the user's existing infrastructure (IP ranges, subscriptions, naming conventions).

Workflow

Phase 1: Read the checklist

Read the uploaded .xlsx checklist using openpyxl to understand its structure. ALZ checklists typically have three tabs:

• Accelerator - Bootstrap: IaC type, VCS, subscriptions, naming, CI/CD settings
• Accelerator - Bicep: Scenario selection, component toggles, IP addressing, policies
• Accelerator - Terraform: Same as Bicep with additional options (AMBA, Sovereign LZ)

Parse the checklist to identify which fields already have values (column F = "Chosen Value") and which are empty. This tells you what the user has already decided vs. what needs input.

Phase 2: Interview the user

Gather decisions through structured questions. Ask in batches of 3-4 questions to avoid overwhelming the user. Prioritize in this order:

Batch 1 — Foundational decisions:

• IaC type (Bicep or Terraform)
• Version control system (Azure DevOps, GitHub, or local)
• Network topology scenario (Hub & Spoke vs vWAN, single vs multi-region, Azure Firewall vs NVA)
• Azure region

Batch 2 — Component decisions:

• Which components to deploy (DDoS, Private DNS, Bastion, VPN Gateway, ExpressRoute, Zero Trust)
• Security posture (AMA, Defender plans)

Batch 3 — Environment-specific details:

• Azure DevOps / GitHub organization and project names
• Subscription IDs (Management, Connectivity, Identity, Security)
• Pipeline approvers
• IP addressing (ask if they have existing documentation)

When the user says "use best practices" or defers a decision, apply the recommendations from references/alz-best-practices.md. Always explain why a recommendation is made — users trust recommendations they understand.

Phase 3: Map subscriptions

If the user provides a subscription list (from az account list or similar), map subscriptions to ALZ roles by matching naming patterns:

If a required subscription is missing (commonly Security), flag it with a yellow highlight and a comment explaining the options:

1. Create a dedicated subscription (recommended)
2. Share with Management subscription (budget-constrained alternative)

Phase 4: Integrate IP addressing

If the user provides IP documentation (Markdown, CSV, Excel, or text), parse it to extract:

• Subscription-level CIDR blocks — map to ALZ hub/spoke VNets
• Existing hub VNet layout — identify subnet allocations (Gateway, Firewall, Bastion, shared services)
• On-premises public IPs — include in comments for VPN/firewall rule reference
• AKS networking — pod/service CIDRs if applicable

For the ALZ hub VNet, recommend this subnet layout using the connectivity subscription's CIDR block:

Hub VNet: <connectivity-base>/16
  GatewaySubnet:                <base>.0.0/27     (30 hosts)
  AzureFirewallSubnet:          <base>.0.64/26    (62 hosts)
  AzureFirewallManagementSubnet:<base>.0.128/26   (62 hosts)
  AzureBastionSubnet:           <base>.0.192/26   (62 hosts)
  Shared Services:              <base>.1.0/24     (254 hosts)
  DNS Resolver Inbound:         <base>.2.0/28
  DNS Resolver Outbound:        <base>.2.16/28

If no IP documentation is provided, use ALZ defaults and flag for review.

Phase 5: Fill the checklist

Use openpyxl to write values into column F ("Chosen Value") of the appropriate tabs. Apply consistent formatting:

from openpyxl.styles import Font, PatternFill, Alignment
from openpyxl.comments import Comment

# Confirmed values — green background
green_fill = PatternFill('solid', fgColor='CCE5CC')

# Items needing user action — yellow background + red bold text
yellow_fill = PatternFill('solid', fgColor='FFFF00')
action_font = Font(bold=True, color='FF0000', size=10)

# Informational notes — italic yellow background
note_fill = PatternFill('solid', fgColor='FFFFCC')
note_font = Font(italic=True, size=10)

For every cell you fill:

• Add a Comment explaining the rationale or best practice reference
• Use green fill for confirmed decisions
• Use yellow fill + red text for items requiring user action (e.g., "TO BE DEFINED", "TO BE PROVIDED")
• Use light yellow fill + italic for items using defaults that the user should review

Tab-specific logic:

Only fill the tab matching the user's IaC choice. Clear the other tab if it had values from a previous attempt. For the active tab:

1. Scenarios section: Set the chosen scenario to "Yes", all others to "No". Highlight the selected one with a brighter green.
2. Options section: Apply the user's component choices. For any option not explicitly discussed, apply best practice defaults and note this in the comment.
3. Bootstrap tab: Always fill regardless of IaC choice — it's shared.

Phase 6: Present results

After saving the filled checklist:

1. Print a summary table showing all filled values
2. List the items flagged for user action (yellow highlights)
3. Call out any architectural considerations (e.g., cross-region peering needed if ALZ region differs from existing infrastructure)
4. Provide the file link for download

Best practice recommendations

Read references/alz-best-practices.md for the full set of recommendations. The key defaults to apply when the user defers:

• Private networking: true (state storage should never be publicly accessible)
• Separate CI/CD template repo: true (security boundary between code and pipeline definitions)
• Branch policies: true (require PRs for all changes)
• Self-hosted agents/runners: true (required for private networking)
• DDoS Protection: Yes (network-layer protection for all VNet resources)
• Private DNS Zones: Yes (required for Private Endpoints across hub-spoke)
• Azure Bastion: Yes (secure VM access without public IP exposure)
• AMA (Azure Monitoring Agent): Keep enabled (centralized monitoring)
• Defender plans: Keep enabled (threat detection across all resource types)
• Zero Trust: Yes (least-privilege access and micro-segmentation)
• AMBA alerts (Terraform only): Yes (proactive monitoring of platform resources)
• Sovereign Landing Zone: No (unless explicitly required for compliance)

Cross-region considerations

If the user's existing infrastructure is in a different region than the ALZ deployment, flag this in the Bootstrap tab's region comment. They'll need to plan for cross-region VNet peering between the ALZ hub and any existing hub-spoke topology.

Cell Reference Map

The checklist has a fixed structure. Use these exact cell references when writing values to avoid row-offset bugs. Always verify by checking that column B (Name) matches the expected field before writing to column F.

Bootstrap Tab (Accelerator - Bootstrap)

Note: Rows 7, 14, 19, 20, 26, 27, 35, 36, 41 are blank or section headers — skip them.

Bicep Tab (Accelerator - Bicep) — Scenarios

Bicep Tab — Options (rows 17-30)

Terraform Tab (Accelerator - Terraform)

Same scenario layout as Bicep (rows 6-14). Options are rows 17-32:

Validation approach: Before writing any value, read cell B{row} and verify it matches the expected field name. If it doesn't match, scan the sheet to find the correct row. This prevents silent data corruption from template version differences.

Output format

The final deliverable is an .xlsx file with:

• All three tabs preserved from the original template
• Column F filled with chosen values
• Cell comments with rationale and best practice references
• Color coding: green (confirmed), yellow (needs action), light yellow (defaults to review)
• A clear summary in the conversation listing all decisions and flagged items

Gotchas

• openpyxl row indices are 1-based — off-by-one bugs corrupt the wrong row silently; verify with cell.value read-back before commit.
• Subscription regex matching breaks on non-standard naming (e.g., sub-xyz-platform-mgmt) — fall back to enumeration when pattern fails.
• Cross-region considerations: VNet peering across regions costs egress traffic; default ALZ template doesn't price this.
• Excel checkboxes vs cell values: openpyxl can't write checkbox state — use cell value "✓" + named range to indicate checked.
• Subscription quota propagation: requested quota increases show as "Approved" before the quota is actually applied — verify with az vm list-usage.