Droid Ek

Posted on Nov 6

Azure Landing Zone

#azure #devops #architecture #security

The Complete Guide to Production-Grade Azure Landing Zones

Note; If you find any mistakes please do not burn me kindly let me know.

Intro

An Azure Landing Zone is the foundational output of a multi-subscription Azure environment that considers scale, security, governance, networking, and identity. It provides a well-defined, repeatable starting point for all your cloud workloads, ensuring they are deployed into a secure, compliant, and operationally excellent environment from day one. A landing zone solves critical enterprise challenges like inconsistent security postures, sprawling and ungoverned environments, lack of visibility, and ballooning costs by establishing a baseline architecture and "guardrails" through policy.

Architect and Design: Confidently design an enterprise-grade Azure Landing Zone based on the Cloud Adoption Framework's principles.
Build with Confidence: Use Infrastructure as Code (Bicep and Terraform) to deploy a complete, modular, and repeatable landing zone.
Govern at Scale: Implement robust governance using Azure Policy, Management Groups, and Role-Based Access Control (RBAC) to enforce security and compliance.
Automate Everything: Build and configure CI/CD pipelines in GitHub Actions and Azure DevOps to enable safe, automated, and auditable deployments.
Operate with Excellence: Establish centralized monitoring, logging, and security to ensure the health, performance, and security of your Azure environment.
Validate and Test: Write and execute automated tests to continuously validate the compliance and health of your landing zone.

1. Prerequisites: Tools, Accounts, and Setup

(Estimated Time: 2 Hours)

Before we build, we must prepare our workshop. This module ensures you have all the necessary tools and permissions.

Lab 1.1: Tool Installation

Lab 1.2: Account and Permissions Verification

Why this matters: A landing zone deployment creates and configures fundamental resources like management groups. These actions require elevated permissions. Verifying them now prevents failures later.

Step	Action	Command/Instructions	Expected Output/Success Indicator	Time
1	Verify Role	`az ad signed-in-user show --query "userPrincipalName"` and check permissions in the Azure portal at the tenant root management group.	You need `Owner` or a role with `Microsoft.Management/managementGroups/write` permissions at the root scope.	10m
2	Register Providers	`az provider register --namespace Microsoft.Management` `az provider register --namespace Microsoft.Network` `az provider register --namespace Microsoft.Insights`	For each command, the output `RegistrationState` should eventually be `Registered`.	25m

2. High-Level Architecture, Naming, and Tagging

This section outlines the target state architecture we will build.

Architecture Diagram (Hub-and-Spoke)

/------------------------------------------------------\
| Azure Tenant / Root Management Group                 |
|                                                      |
|   /---------------------------------------------\    |
|   | Platform Management Group                   |    |
|   |   /------------------\   /----------------\ |    |
|   |   | Identity MG      |   | Management MG  | |    |
|   |   | (Sub: Identity)  |   | (Sub: Mgmt)    | |    |
|   |   \------------------/   \----------------/ |    |
|   |   /------------------\                      |    |
|   |   | Connectivity MG  |                      |    |
|   |   | (Sub: Hub Ntwk)  |                      |    |
|   |   \------------------/                      |    |
|   \---------------------------------------------/    |
|                                                      |
|   /---------------------------------------------\    |
|   | Landing Zones Management Group              |    |
|   |   /------------------\   /----------------\ |    |
|   |   | Prod MG          |   | Non-Prod MG    | |    |
|   |   | (Sub: Prod-App1) |   | (Sub: Dev-App1)| |    |
|   |   \------------------/   \----------------/ |    |
|   \---------------------------------------------/    |
\------------------------------------------------------/

Network Flow:
[Spoke VNet (Prod-App1)] <--VNet Peering--> [Hub VNet] <--Firewall--> [Internet/On-Prem]

Naming Convention and Tagging Strategy

Why this matters: A consistent naming and tagging strategy is the bedrock of good governance. It enables automation, simplifies cost management, improves clarity, and enhances security by making resources easily identifiable and groupable.

Naming Convention: [ResourceType]-[WorkloadName]-[Environment]-[AzureRegion]-[Instance]

Examples: rg-myapp-prod-eastus-001, vnet-hub-prod-eastus-001

Tagging Strategy (Mandatory Tags):

Tag Key	Purpose	Example Value
`owner`	Identifies the business or technical owner.	`finance-team@example.com`
`costCenter`	Associates resource with an internal cost center.	`12345`
`environment`	The deployment environment.	`prod` / `dev`
`appName`	The name of the application or service.	`SAP-HANA`

3. Curriculum: The Learning Path

Module 1: Governance Foundation with Management Groups

Summary: Establish the core hierarchical structure of your Azure environment.
Time: 3 Hours
Difficulty: Beginner

Module 2: Identity & Access Management (IAM)

Summary: Configure the identity backbone, defining who can do what.
Time: 4 Hours
Difficulty: Intermediate

Module 3: Policy-Driven Governance & Security Baselines

Summary: Implement automated guardrails to enforce security and compliance.
Time: 5 Hours
Difficulty: Intermediate

Module 4: Network Foundation (Hub-and-Spoke)

Summary: Build the core network topology for secure connectivity.
Time: 6 Hours
Difficulty: Advanced

Module 5: Centralized Operations & Shared Services

Summary: Deploy and configure centralized services for logging and secrets.
Time: 4 Hours
Difficulty: Intermediate

Module 6: Infrastructure as Code (IaC) & Repository Structure

Summary: Organize your Bicep/Terraform code for scalability and reuse.
Time: 5 Hours
Difficulty: Intermediate

Module 7: CI/CD & GitOps Automation

Summary: Build automated pipelines to deploy landing zone changes safely.
Time: 6 Hours
Difficulty: Advanced

Module 8: Capstone Project

Summary: Apply all learned concepts to build a complete landing zone from scratch.
Time: 8 Hours
Difficulty: Expert

Module 1: Governance Foundation with Management Groups

Why this matters: Management groups provide a level of scope above subscriptions, allowing you to apply governance controls like policies and access assignments efficiently and consistently across your entire Azure estate. A well-designed hierarchy is the first and most critical step to scaling your cloud environment securely.

Hands-on Lab: Creating the Management Group Hierarchy

Step	Action	Command/Instructions	Expected Output/Success Indicator	Time
1	Create Platform MG	`az account management-group create --name "lz-platform"`	JSON output describing the new `lz-platform` MG.	10m
2	Create Child MGs	`az account management-group create --name "lz-identity" --parent "lz-platform"` `az account management-group create --name "lz-management" --parent "lz-platform"` `az account management-group create --name "lz-connectivity" --parent "lz-platform"`	JSON output for each new MG.	15m
3	Create Landing Zones MG	`az account management-group create --name "lz-landingzones"`	JSON output for the `lz-landingzones` MG.	10m
4	Create Prod/NonProd MGs	`az account management-group create --name "lz-prod" --parent "lz-landingzones"` `az account management-group create --name "lz-nonprod" --parent "lz-landingzones"`	JSON output for each new MG.	10m
5	Verify Hierarchy	`az account management-group show --name "lz-platform" --expand --recurse`	A tree structure in the JSON output showing the parent-child relationships.	5m

Bicep Artifact: `managementGroups.bicep`

targetScope = 'tenant'

resource mgPlatform 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'lz-platform'
  properties: { displayName: 'Platform' }
}

resource mgConnectivity 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'lz-connectivity'
  properties: {
    displayName: 'Connectivity'
    details: { parent: { id: mgPlatform.id } }
  }
}
// ... other MGs follow the same pattern

Deployment: az deployment tenant create --location eastus --template-file managementGroups.bicep

Terraform Artifact: `management_groups.tf`

resource "azurerm_management_group" "platform" {
  display_name = "Platform"
  name         = "lz-platform"
}

resource "azurerm_management_group" "connectivity" {
  display_name               = "Connectivity"
  name                       = "lz-connectivity"
  parent_management_group_id = azurerm_management_group.platform.id
}
// ... other MGs follow the same pattern

Deployment: terraform init && terraform apply

Architectural Deep Dive & Use Case

Deep Dive: The recommended CAF hierarchy is relatively shallow to reduce complexity. A deep hierarchy modeled after an org chart can become difficult to manage due to complex policy and RBAC inheritance. The functional design (Platform, Landing Zones) provides a more robust model for applying governance.
Use Case - Preventing Cloud Sprawl: An enterprise is struggling with uncontrolled resource creation and costs. By creating Prod and Non-Prod management groups, they can apply stricter policies (like limiting expensive VM SKUs) to the Non-Prod group while applying stricter security policies to the Prod group, all from a central point of control.

Module 2: Identity & Access Management (IAM)

Why this matters: Identity is the modern security perimeter. This pillar focuses on ensuring all access to Azure is authenticated, authorized, and audited according to Zero Trust principles.

Hands-on Lab: Implementing Least Privilege

Step	Action	Command/Instructions	Expected Output/Success Indicator	Time
1	Create Custom Role	Create `SpokeVnetContributor.json` (see below). Then run: `az role definition create --role-definition @SpokeVnetContributor.json`	JSON output of the new role definition.	20m
2	Assign Role	Get your App Team's Group ID: `GROUP_ID=$(az ad group show --group "YourAppTeamGroup" --query id -o tsv)` Get subscription ID: `SUB_ID=$(az account show --query id -o tsv)` `az role assignment create --assignee $GROUP_ID --role "Spoke VNet Contributor" --scope /subscriptions/$SUB_ID`	JSON output of the role assignment.	15m
3	Configure PIM	In the Azure Portal, navigate to Azure AD > Privileged Identity Management. Make your platform admin account "eligible" for the built-in `Contributor` role on the `lz-platform` management group.	When you go to "My roles" in PIM, you will see the eligible assignment and an "Activate" button.	30m

Artifact: `SpokeVnetContributor.json`

{
  "Name": "Spoke VNet Contributor",
  "Description": "Allows contributing to resources within a spoke VNet without network modification rights.",
  "Actions": [
    "Microsoft.Storage/*",
    "Microsoft.Compute/*",
    "Microsoft.Sql/*",
    "Microsoft.Web/*"
  ],
  "NotActions": [
    "Microsoft.Network/virtualNetworks/*",
    "Microsoft.Network/routeTables/*"
  ],
  "AssignableScopes": [
    "/providers/Microsoft.Management/managementGroups/lz-landingzones"
  ]
}

Architectural Deep Dive & Use Cases

Deep Dive - Managed Identities: The superior architectural choice over service principals with secrets. A Managed Identity is a credential managed entirely by Azure for a resource (like a VM or Web App). This eliminates the entire class of risks associated with developers managing, rotating, and potentially leaking secrets.
Use Case 1 - Secure Emergency Access: A production application is down. Using PIM, an on-call engineer requests to activate the Contributor role for 2 hours, providing the incident ticket number as justification. They get temporary, just-in-time access to fix the issue. All actions are audited, and access is automatically revoked, eliminating the risk of a standing privileged account.
Use Case 2 - Passwordless CI/CD: A CI/CD pipeline needs to deploy resources. Instead of storing a service principal secret in GitHub, the pipeline uses Managed Identity (or workload identity federation) to securely obtain an access token, eliminating secrets from the DevOps toolchain.

Module 3: Policy-Driven Governance & Security Baselines

Why this matters: Azure Policy is the core of governance, enabling you to enforce rules at scale. It ensures that as new resources are created, they automatically adhere to security and compliance standards, preventing misconfigurations before they happen.

Hands-on Lab: Creating and Assigning Policy

Step	Action	Command/Instructions	Expected Output/Success Indicator	Time
1	Create "Enforce Tag" Policy	Create `enforce-tag-policy.json` (see below). Run: `az policy definition create --name "enforce-costCenter-tag" --rules enforce-tag-policy.json --mode All`	JSON output of the created policy definition.	20m
2	Create Initiative	`POLICY_ID=$(az policy definition show --name "enforce-costCenter-tag" --query id -o tsv)` Create `initiative.json` (see below). Then run: `az policy set-definition create --name "landingzone-baseline" --definitions initiative.json`	JSON output of the created initiative.	20m
3	Assign Initiative	`INITIATIVE_ID=$(az policy set-definition show --name "landingzone-baseline" --query id -o tsv)` `MG_ID=$(az account management-group show --name "lz-landingzones" --query id -o tsv)` `az policy assignment create --name "lz-baseline-assignment" --scope $MG_ID --policy-set-definition $INITIATIVE_ID`	JSON output of the policy assignment.	15m
4	Test Policy	Try to create a resource group without the `costCenter` tag under the target MG: `az group create -n "test-rg" -l "eastus"`	The command should fail with a policy violation error.	10m

Azure Policy JSON Artifacts

enforce-tag-policy.json (Deny effect)

{
  "if": {
    "allOf": [
      { "field": "type", "equals": "Microsoft.Resources/subscriptions/resourceGroups" },
      { "field": "tags['costCenter']", "exists": "false" }
    ]
  },
  "then": { "effect": "deny" }
}

initiative.json (placeholder)

{
  "properties": {
    "displayName": "Landing Zone Baseline Policies",
    "policyDefinitions": [
      { "policyDefinitionId": "[POLICY_ID]" }
    ]
  }
}

Architectural Deep Dive & Use Case

Deep Dive - Policy-as-Code: This is the practice of managing your policy definitions and assignments as code in a Git repository. Every change is peer-reviewed via a pull request and deployed through an automated CI/CD pipeline. This provides versioning, validation (using what-if), and an audit trail for all your governance rules. The DeployIfNotExists effect is a powerful remediation tool to automatically configure things like diagnostic settings.
Use Case - Enforcing Data Sovereignty (GDPR): A European company must ensure citizen data remains within the EU. A policy initiative is assigned to their EU management group containing an "Allowed Locations" policy that only permits deployment in West Europe and North Europe. This automated guardrail makes it impossible for developers to accidentally violate GDPR, preventing massive potential fines.

Module 4: Network Foundation (Hub-and-Spoke)

Why this matters: A hub-and-spoke network topology centralizes common services like firewalls and gateways, reducing cost and management overhead. It provides a secure and scalable model for connecting multiple workloads (spokes) while enforcing traffic inspection.

Hands-on Lab: Building the Hub-and-Spoke Network

Step	Action	Command/Instructions	Expected Output/Success Indicator	Time
1	Deploy Hub VNet	Use the `hubNetwork.bicep` file below with the command: `az deployment group create --resource-group "rg-hub-prod-eastus" --template-file hubNetwork.bicep`	Successful deployment. This may take 20-30 minutes for the Firewall to provision.	30m
2	Deploy Spoke VNet	Use `spokeNetwork.bicep` below with the command: `az deployment group create --resource-group "rg-spoke-app1-prod-eastus" --template-file spokeNetwork.bicep`	Successful deployment.	15m
3	Peer the VNets	(Use CLI or Portal to create peering from Hub -> Spoke and Spoke -> Hub) `az network vnet peering create ...`	Peering status becomes `Connected`.	15m
4	Configure Spoke Route	`FW_PRIVATE_IP=$(az network firewall show ... --query "ipConfigurations[0].privateIpAddress")` `az network route-table route create ... --next-hop-type VirtualAppliance --address-prefix 0.0.0.0/0 --next-hop-ip-address $FW_PRIVATE_IP` `az network vnet subnet update ... --route-table <YourRouteTable>`	Route table is associated with the spoke subnet.	20m

Bicep Artifacts

hubNetwork.bicep

param location string = resourceGroup().location
param vnetName string = 'vnet-hub-prod-eastus-001'
param firewallName string = 'fw-hub-prod-eastus-001'

resource publicIpFirewall 'Microsoft.Network/publicIPAddresses@2022-01-01' = {
  name: '${firewallName}-pip'
  location: location
  sku: { name: 'Standard' }
  properties: { publicIPAllocationMethod: 'Static' }
}

resource hubVnet 'Microsoft.Network/virtualNetworks@2022-01-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: { addressPrefixes: [ '10.0.0.0/16' ] }
    subnets: [
      { name: 'AzureFirewallSubnet', properties: { addressPrefix: '10.0.1.0/24' } }
    ]
  }
}

resource firewall 'Microsoft.Network/azureFirewalls@2022-01-01' = {
  name: firewallName
  location: location
  properties: {
    sku: { name: 'AZFW_VNet', tier: 'Standard' }
    ipConfigurations: [
      {
        name: 'fw-ipconfig'
        properties: {
          subnet: { id: hubVnet.properties.subnets[0].id }
          publicIPAddress: { id: publicIpFirewall.id }
        }
      }
    ]
  }
}

spokeNetwork.bicep

param location string = resourceGroup().location
param vnetName string = 'vnet-spoke-app1-prod-eastus-001'

resource spokeVnet 'Microsoft.Network/virtualNetworks@2022-01-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: { addressPrefixes: [ '10.10.0.0/16' ] }
    subnets: [
      { name: 'snet-workload', properties: { addressPrefix: '10.10.1.0/24' } }
    ]
  }
}

Architectural Deep Dive & Use Case

Deep Dive - Azure Virtual WAN (vWAN): For enterprises with a significant global footprint and many on-premises sites, vWAN is the strategic evolution of the hub-spoke model. It's a Microsoft-managed service that creates a global transit network, simplifying routing, providing built-in transitivity (spoke-to-spoke communication), and reducing operational overhead compared to managing a mesh of regional hubs yourself.
Use Case - Securing a Regulated Workload (PCI-DSS): A payment processing application is deployed into a dedicated spoke VNet. A route table forces all its traffic through the central Azure Firewall. The firewall policy is configured to only allow connections to known payment gateways, denying all other internet traffic. This provides the provable network isolation and traffic inspection required to meet PCI compliance.

Module 5: Centralized Operations & Shared Services

Why this matters: Centralizing services like logging and secrets management provides a single pane of glass for security and operations, reduces costs, and simplifies management across the entire estate.

Hands-on Lab: Deploying Centralized Logging

Step	Action	Command/Instructions	Expected Output/Success Indicator	Time
1	Create Mgmt RG	`az group create --name "rg-management-prod-eastus" -l "eastus"`	JSON output of new RG.	5m
2	Deploy Log Analytics	`az deployment group create -g "rg-management-prod-eastus" --template-file logAnalytics.bicep`	Successful deployment.	10m
3	Create Policy	Create a `DeployIfNotExists` policy to send diagnostics from all Key Vaults to this workspace.	Policy definition is created.	20m
4	Assign Policy	Assign the policy to the `lz-landingzones` management group, passing the workspace ID as a parameter.	Policy assignment is created. New Key Vaults will now automatically send logs.	15m

Bicep Artifact: `logAnalytics.bicep`

param location string = resourceGroup().location
param workspaceName string = 'log-analytics-prod-eastus'

resource logAnalyticsWorkspace 'Microsoft.OperationalInsights/workspaces@2021-06-01' = {
  name: workspaceName
  location: location
  properties: {
    sku: {
      name: 'PerGB2018'
    }
    retentionInDays: 90
  }
}

output workspaceId string = logAnalyticsWorkspace.id

Architectural Deep Dive & Use Case

Deep Dive - The Subscription Vending Machine: This is the pinnacle of platform automation. It's a workflow (e.g., Logic App, GitHub Actions) that allows application teams to request and receive a new, fully configured, and compliant subscription without manual intervention. The workflow creates the sub, moves it to the correct MG (inheriting policies), deploys a baseline spoke VNet peered to the hub, and assigns the team RBAC. This transforms the platform team from a gatekeeper into an enabler.
Use Case - Centralized Incident Response: A SOC analyst is alerted to a threat by Azure Defender for Cloud. Because all security signals (Firewall, NSG, Azure AD, Defender) are streamed to a central Log Analytics Workspace and ingested by Azure Sentinel, they can see the entire attack chain in a single incident view—from the initial risky sign-in to the network traffic and the final alert on the VM—drastically reducing investigation time from hours to minutes.

Module 6 & 7: IaC, CI/CD, and GitOps Automation

Why this matters: Applying DevOps principles to infrastructure allows for safe, repeatable, and auditable management of your landing zone. Every change is peer-reviewed and automatically validated before being deployed.

Conceptual Lab: Structuring Your Repository & Pipeline

Repository Structure: Organize your code into a logical structure.

/infra
├── /bicep
│   ├── /modules
│   │   ├── network.bicep
│   │   └── policy.bicep
│   └── main.bicep
└── /pipelines
    └── deploy-landingzone.yml

Terraform State Management: For Terraform, it is critical to use a remote backend to store the state file securely and to manage locking.

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-tfstate"
    storage_account_name = "sttfstateprod"
    container_name       = "tfstate"
    key                  = "landingzone.tfstate"
  }
}

CI/CD Pipeline (GitHub Actions): The pipeline is the engine of GitOps.
- Trigger: On pull request to the main branch.
- CI (Validation) Job:
  - Check out the code.
  - Install Bicep/Terraform.
  - Run a linter to check code style.
  - Run az deployment mg what-if (for Bicep) or terraform plan (for Terraform) to preview the changes.
  - Post the plan results as a comment on the PR.
- CD (Deployment) Job:
  - Trigger: On merge to the main branch.
  - Requires a manual approval step in the pipeline.
  - Run az deployment mg create (for Bicep) or terraform apply (for Terraform) to deploy the changes.

GitHub Actions Artifact: `deploy-landingzone.yml`

name: 'Deploy Landing Zone'

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Azure Login
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    - name: Bicep What-If
      if: github.event_name == 'pull_request'
      run: |
        az deployment tenant what-if \
          --location eastus \
          --template-file ./infra/bicep/main.bicep

  deploy:
    runs-on: ubuntu-latest
    needs: validate
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    environment: production
    steps:
    - uses: actions/checkout@v2
    - name: Azure Login
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    - name: Bicep Deploy
      run: |
        az deployment tenant create \
          --location eastus \
          --template-file ./infra/bicep/main.bicep

Module 8: Capstone Project

Objective: Deploy a complete, multi-subscription landing zone using IaC and a CI/CD pipeline, applying all concepts learned.

Statement of Work:

Governance: Create a management group hierarchy (Platform, Landing Zones, Prod, Non-Prod).
Networking: Deploy a hub-and-spoke topology. The hub must contain an Azure Firewall and a Log Analytics workspace. Deploy two spoke VNets (one prod, one non-prod) and peer them to the hub.
Policy: Author and assign a policy initiative that enforces the costCenter tag on all resource groups and requires diagnostic settings on all storage accounts.
Identity: Create a custom RBAC role for an application team that grants them contributor rights within their spoke VNet but denies them rights to modify the network peering or route tables.
Automation: All infrastructure must be defined in Bicep or Terraform. The deployment must be executed via a GitHub Actions pipeline that validates changes on a pull request and deploys on merge to main.

Acceptance Criteria & Scoring Rubric:

Criteria	Pass Condition	Score ( /100)
Management Groups	Correct hierarchy is deployed and visible.	15
Network	Hub with Firewall and Spokes are deployed. Peering is `Connected`. UDR on spokes forces traffic to Firewall.	30
Policy	Policy initiative is assigned. Attempting to create an untagged RG fails.	20
RBAC	Custom role is created and assigned. Test user can create a VM but cannot alter peering.	15
CI/CD	Pipeline runs `what-if`/`plan` on PR and successfully deploys on merge to `main`.	20
Total		100

Final Checklist & Production Readiness

Before going live, perform this final go/no-go check.

[ ] Governance: All required policies are assigned and showing a compliant state.
[ ] Identity: All administrative access is managed through PIM. No standing privileged accounts exist.
[ ] Networking: Firewall rules are locked down to least privilege. Hybrid connectivity (if any) is stable and redundant.
[ ] Operations: Centralized logging is collecting data from all critical resources. High-priority alerts (e.g., for security events) are configured and tested.
[ ] Costs: Budgets and cost alerts are configured for all subscriptions/management groups.
[ ] Automation: The CI/CD pipeline is the only way infrastructure changes are deployed. The main branch is protected, requiring PRs and reviews.
[ ] Validation: Automated health checks are in place to validate core landing zone functionality (e.g., DNS resolution, connectivity through the firewall).

1. Prerequisites: Tools, Accounts, and Setup

Lab 1.1: Tool Installation

Lab 1.2: Account and Permissions Verification

2. High-Level Architecture, Naming, and Tagging

Architecture Diagram (Hub-and-Spoke)

Naming Convention and Tagging Strategy

3. Curriculum: The Learning Path

Module 1: Governance Foundation with Management Groups

Module 2: Identity & Access Management (IAM)

Module 3: Policy-Driven Governance & Security Baselines

Module 4: Network Foundation (Hub-and-Spoke)

Module 5: Centralized Operations & Shared Services

Module 6: Infrastructure as Code (IaC) & Repository Structure

Module 7: CI/CD & GitOps Automation

Module 8: Capstone Project

Module 1: Governance Foundation with Management Groups

Hands-on Lab: Creating the Management Group Hierarchy

Bicep Artifact: managementGroups.bicep

Terraform Artifact: management_groups.tf

Architectural Deep Dive & Use Case

Module 2: Identity & Access Management (IAM)

Hands-on Lab: Implementing Least Privilege

Artifact: SpokeVnetContributor.json

Architectural Deep Dive & Use Cases

Module 3: Policy-Driven Governance & Security Baselines

Hands-on Lab: Creating and Assigning Policy

Azure Policy JSON Artifacts

Architectural Deep Dive & Use Case

Module 4: Network Foundation (Hub-and-Spoke)

Hands-on Lab: Building the Hub-and-Spoke Network

Bicep Artifacts

Architectural Deep Dive & Use Case

Module 5: Centralized Operations & Shared Services

Hands-on Lab: Deploying Centralized Logging

Bicep Artifact: logAnalytics.bicep

Architectural Deep Dive & Use Case

Module 6 & 7: IaC, CI/CD, and GitOps Automation

Conceptual Lab: Structuring Your Repository & Pipeline

GitHub Actions Artifact: deploy-landingzone.yml

Module 8: Capstone Project

Final Checklist & Production Readiness

Bicep Artifact: `managementGroups.bicep`

Terraform Artifact: `management_groups.tf`

Artifact: `SpokeVnetContributor.json`

Bicep Artifact: `logAnalytics.bicep`

GitHub Actions Artifact: `deploy-landingzone.yml`