Hands-on Lab — AZ-400 Microsoft Azure DevOps Engineer Expert

Overview

Prerequisites

Steps

1. 1.Provider, Resource Group, naming

   Standard Azure opener.

   Copy

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
       random  = { source = "hashicorp/random",  version = "~> 3.6" }
     }
   }
   
   provider "azurerm" {
     features {
       key_vault {
         purge_soft_delete_on_destroy = true
       }
     }
   }
   
   resource "random_id" "suffix" {
     byte_length = 3
   }
   
   data "azurerm_client_config" "current" {}
   
   locals {
     tags = {
       Project   = "certlabpro-az-400"
       ManagedBy = "terraform"
     }
   }
   
   resource "azurerm_resource_group" "main" {
     name     = "certlabpro-az-400-rg"
     location = "eastus"
     tags     = local.tags
   }

2. 2.Provision Azure Container Registry for build artifacts

   Provisions:

   • Azure Container Registry

   ACR is where the CI pipeline pushes container images that the CD pipeline pulls. AZ-400 tests this push/pull boundary as a security pattern: the build pipeline gets AcrPush, the deployment target gets AcrPull, and never the twain shall meet.

   We use the Basic tier — cheapest, single replication target. Premium adds geo-replication and the Content Trust feature (image signing); both are AZ-400 exam topics but cost-prohibitive for the lab.

   Copy

   resource "azurerm_container_registry" "main" {
     name                = "acrcertlabpro${random_id.suffix.hex}"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
     sku                 = "Basic"
     admin_enabled       = false # admin user disabled — Entra-only access
   
     tags = local.tags
   }

3. 3.Stand up AKS with managed identity + Log Analytics

   Provisions:

   • Azure Kubernetes Service

   AKS is the AZ-400 deployment target of choice for container workloads. We use a system-assigned managed identity (the modern default; service-principal auth is deprecating), a single small system nodepool, and azure_policy_enabled = true (the AZ-400 Implement compliance answer for cluster-level policy enforcement via Azure Policy add-on).

   The Log Analytics workspace + OMS agent integration is the AZ-400 Implement instrumentation answer for cluster-level observability — every pod log, every node metric, every Kubernetes audit event lands in Log Analytics for KQL querying.

   Copy

   resource "azurerm_log_analytics_workspace" "main" {
     name                = "log-az400"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
     sku                 = "PerGB2018"
     retention_in_days   = 30
   
     tags = local.tags
   }
   
   resource "azurerm_kubernetes_cluster" "main" {
     name                = "aks-az400"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
     dns_prefix          = "azaks${random_id.suffix.hex}"
   
     default_node_pool {
       name       = "system"
       node_count = 1
       vm_size    = "Standard_D2s_v3"
     }
   
     identity {
       type = "SystemAssigned"
     }
   
     oms_agent {
       log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
     }
   
     azure_policy_enabled = true
   
     tags = local.tags
   }
   
   # Grant the AKS kubelet identity AcrPull on the registry from Step 2.
   # This is the AZ-400 password-less image-pull pattern.
   resource "azurerm_role_assignment" "aks_acr_pull" {
     scope                = azurerm_container_registry.main.id
     role_definition_name = "AcrPull"
     principal_id         = azurerm_kubernetes_cluster.main.kubelet_identity[0].object_id
   }

4. 4.Wire Key Vault for pipeline secrets

   Provisions:

   • Azure Key Vault

   Pipeline secrets — API keys, deployment credentials, third-party tokens — should never sit in pipeline YAML. AZ-400's Implement security and validate code bases for compliance domain tests this Key-Vault-Reference-in-pipeline-task pattern: pipelines reference secrets by name from Key Vault at runtime.

   We grant the AKS kubelet identity Key Vault Secrets User so deployed pods can also read secrets via the Secrets Store CSI Driver (the in-cluster mount mechanism for Key Vault-backed secrets). With the role in place, every pod that needs a database password reads it via the CSI driver, not from an env var baked into the image.

   Copy

   resource "azurerm_key_vault" "main" {
     name                       = "kv-az400-${random_id.suffix.hex}"
     resource_group_name        = azurerm_resource_group.main.name
     location                   = azurerm_resource_group.main.location
     tenant_id                  = data.azurerm_client_config.current.tenant_id
     sku_name                   = "standard"
     enable_rbac_authorization  = true
     soft_delete_retention_days = 7
   
     tags = local.tags
   }
   
   resource "azurerm_role_assignment" "kv_admin_self" {
     scope                = azurerm_key_vault.main.id
     role_definition_name = "Key Vault Administrator"
     principal_id         = data.azurerm_client_config.current.object_id
   }
   
   resource "azurerm_role_assignment" "aks_kv_reader" {
     scope                = azurerm_key_vault.main.id
     role_definition_name = "Key Vault Secrets User"
     principal_id         = azurerm_kubernetes_cluster.main.kubelet_identity[0].object_id
   }

5. 5.Add Application Insights for app-level observability

   Provisions:

   • Azure Application Insights

   Log Analytics handles cluster-level signals (node metrics, pod logs); App Insights handles application-level (request tracing, exception telemetry, dependency tracking, distributed traces). AZ-400 Implement instrumentation tests both layers — the exam expects you to wire them as a pair, with App Insights as the workspace-based mode using the Log Analytics workspace from Step 3.

   With this final piece in place, the AZ-400 CI/CD-target shape is complete: ACR receives build images, AKS deploys them, Key Vault provides secrets, Log Analytics + App Insights observe the result. The pipeline YAML (Azure DevOps or GitHub Actions) drives it all — that lives in the source repo, not in Terraform.

   Copy

   resource "azurerm_application_insights" "main" {
     name                = "appi-az400"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
     workspace_id        = azurerm_log_analytics_workspace.main.id
     application_type    = "web"
   
     tags = local.tags
   }

Cleanup