Praxislabor — AZ-400 Microsoft Azure DevOps Engineer Expert

Übersicht

Voraussetzungen

Schritte

1. 1.Provider, Ressourcengruppe, Benennung

   Standard Azure-Einstieg.

   Kopieren

   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.Azure Container Registry für Build-Artefakte bereitstellen

   Ressourcen:

   • Azure Container Registry

   ACR ist der Ort, an den die CI-Pipeline Container-Images pusht, die die CD-Pipeline pullt. AZ-400 testet diese Push/Pull-Grenze als Sicherheitsmuster: Die Build-Pipeline erhält AcrPush, das Bereitstellungsziel erhält AcrPull, und die beiden sollen sich niemals treffen.

   Wir verwenden die Basic-Stufe – die günstigste, einzelne Replikationsziel. Premium bietet Geo-Replikation und die Content Trust-Funktion (Image-Signierung); beides sind AZ-400-Prüfungsthemen, aber für das Lab zu kostspielig.

   Kopieren

   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.AKS mit verwalteter Identität + Log Analytics einrichten

   Ressourcen:

   • Azure Kubernetes Service

   AKS ist das AZ-400-Bereitstellungsziel der Wahl für Container-Workloads. Wir verwenden eine systemseitig zugewiesene verwaltete Identität (der moderne Standard; die Authentifizierung mittels Dienstprinzipal wird eingestellt), einen einzelnen kleinen System-Knotenpool und azure_policy_enabled = true (die AZ-400 Compliance implementieren-Antwort für die Richtlinienerzwingung auf Clusterebene über das Azure Policy-Add-on).

   Die Log Analytics-Arbeitsbereich + OMS-Agent-Integration ist die AZ-400 Instrumentierung implementieren-Antwort für die Beobachtbarkeit auf Clusterebene – jedes Pod-Log, jede Knotenmetrik, jedes Kubernetes-Audit-Ereignis landet in Log Analytics zur KQL-Abfrage.

   Kopieren

   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.Key Vault für Pipeline-Geheimnisse anbinden

   Ressourcen:

   • Azure Key Vault

   Pipeline-Geheimnisse – API-Schlüssel, Bereitstellungsanmeldeinformationen, Drittanbieter-Token – sollten niemals in der Pipeline-YAML gespeichert werden. Der AZ-400-Bereich Sicherheit implementieren und Codebasen auf Compliance validieren testet dieses Muster der Key-Vault-Referenz-in-Pipeline-Aufgabe: Pipelines referenzieren Geheimnisse zur Laufzeit namentlich aus dem Key Vault.

   Wir gewähren der AKS Kubelet-Identität die Rolle Key Vault Secrets User, damit bereitgestellte Pods auch Geheimnisse über den Secrets Store CSI Driver lesen können (der In-Cluster-Mount-Mechanismus für vom Key Vault unterstützte Geheimnisse). Mit dieser Rolle liest jeder Pod, der ein Datenbankpasswort benötigt, dieses über den CSI-Treiber und nicht aus einer in das Image integrierten Umgebungsvariable.

   Kopieren

   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.Application Insights für die Beobachtbarkeit auf Anwendungsebene hinzufügen

   Ressourcen:

   • Azure Application Insights

   Log Analytics verarbeitet Signale auf Clusterebene (Knotenmetriken, Pod-Logs); App Insights verarbeitet Signale auf Anwendungsebene (Anforderungsverfolgung, Ausnahme-Telemetrie, Abhängigkeitsverfolgung, verteilte Traces). AZ-400 Instrumentierung implementieren testet beide Ebenen – die Prüfung erwartet, dass Sie sie als Paar verdrahten, wobei App Insights im Arbeitsbereich-basierten Modus den Log Analytics-Arbeitsbereich aus Schritt 3 verwendet.

   Mit diesem letzten Baustein ist die AZ-400 CI/CD-Zielarchitektur vollständig: ACR empfängt Build-Images, AKS stellt sie bereit, Key Vault liefert Geheimnisse, Log Analytics + App Insights überwachen das Ergebnis. Die Pipeline-YAML (Azure DevOps oder GitHub Actions) steuert alles – diese befindet sich im Quell-Repository, nicht in Terraform.

   Kopieren

   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
   }

Bereinigung