Microsoft AZ-400: Infrastructure as Code and Configuration Management — Study Guide

Part of the Microsoft DevOps Engineer Expert AZ-400 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Infrastructure as Code (IaC) and Configuration Management on Azure let you define, provision, and enforce infrastructure and application settings repeatedly and safely. Azure natively supports ARM JSON and Bicep, and integrates well with Terraform and Ansible. Configuration state can be declared with PowerShell Desired State Configuration (DSC), Azure Automation DSC, Chef, and Puppet. Application feature rollout and key management are centralized with Azure App Configuration and Key Vault. Immutable images built with Packer reduce drift. Governance is enforced as policy-as-code with Azure Policy and OPA/Gatekeeper for Kubernetes.

Azure-Native IaC: ARM Templates and Bicep

ARM templates are declarative JSON documents the Azure Resource Manager uses to create and update resources. The top-level structure includes $schema, contentVersion, parameters, variables, resources, and outputs. Parameters allow environment-specific input; variables help derive calculated values; resources declare the desired state; outputs publish results like resource IDs. Templates support template expressions and runtime functions (e.g., resourceId, reference, concat, uniqueString) so you can compose names and retrieve properties.

To break large deployments into maintainable units you can use nested or linked templates. A nested template inlines JSON in a Microsoft.Resources/deployments resource’s template property. A linked template references a remote template via templateLink.uri, typically stored in Azure Storage with time-scoped SAS for integrity. Use nested templates when everything can live in a single artifact and you want transactional deployment across parts. Use linked templates for very large topologies or when reusing templates across repositories or teams. Scope your deployments to resource group, subscription, management group, or tenant as needed by setting the deployment scope on the deployments resource.

ARM supports two deployment modes. Incremental (default) creates or updates resources present in the template without deleting anything not declared. Complete deletes resources at the target scope that are not specified in the template, making it useful to guarantee minimal drift but also riskier if the template is not authoritative for that scope. Validate and What-If operations help preview changes to reduce risk before execution.

Bicep is a domain-specific language that compiles to ARM JSON and offers first-class authoring ergonomics. Resource declarations use symbolic names, enforce types, and support existing keyword to reference pre-existing resources without redeployment. Parameters, variables, outputs, and resource declarations are concise, and parent-child relationships and scopes are explicit. Modules enable composition and reuse; each module is a Bicep file referenced with the module keyword and can be published to and consumed from template spec or OCI artifact registries. Conditions are expressed inline with if on resources or modules, and loops use for expressions to declare multiple instances with clear dependency handling. Migration from ARM JSON is straightforward: az bicep decompile (or bicep decompile) converts JSON to Bicep; you then refactor into modules and adopt symbolic names. Bicep is lossless with ARM and supports the full platform surface; bicep build emits standard ARM JSON for deployment.

Cross-Platform IaC on Azure with Terraform

Terraform complements Azure-native IaC when multi-cloud or provider-agnostic workflows are needed. The azurerm provider manages Azure Resource Manager resources and should be version-pinned; include features {} even if empty to enable provider features. Other common providers include azuread for AAD objects and random for utility values. Authenticate via a service principal, Managed Identity on hosted agents, or Azure CLI. Adopt a clear provider configuration strategy for each environment, and centralize reusable modules with input variables and outputs.

State management is critical. Use the azurerm backend to store remote state in Azure Storage: configure resource_group_name, storage_account_name, container_name, and key; authenticate with managed identity or SAS; and enable soft delete and versioning on the blob container. The backend uses blob leases to lock state and prevent concurrent mutations. Access to the storage account should be RBAC-gated and optionally restricted with Private Endpoints. Keep state files environment-isolated, and never store secrets in state by design—use Key Vault and data sources for secret retrieval when necessary.

Workspaces provide logical isolation of state within the same configuration for environment branching such as dev, test, and prod. Use terraform workspace select and ensure the backend key encodes the workspace to avoid collisions (e.g., myapp-${terraform.workspace}.tfstate). Workspaces are excellent for environment parity with small deltas; when topologies diverge significantly, use separate configurations or modules to avoid drift and conditional complexity. Integrate with Azure Pipelines using service connections and the Terraform CLI tasks to standardize init/plan/apply across stages and to gate applies on approvals and policy checks.

Configuration Management at Scale: DSC, Azure Automation DSC, Ansible, Chef, and Puppet

PowerShell Desired State Configuration (DSC) declares Windows and cross-platform state via resources. Two delivery modes exist: push sends MOFs directly to nodes; pull has nodes fetch their MOFs from a pull service on a schedule. The Local Configuration Manager (LCM) enforces the policy. Key LCM settings include:

Azure Automation State Configuration (Azure Automation DSC) is a managed pull service. You author configurations in PowerShell, import them to an Automation Account, and start compilation jobs that produce node configurations (MOF). Nodes register with Register-AzAutomationDscNode using a registration key/endpoint and can be grouped and assigned configurations with per-node parameter values. Compliance reporting shows the last applied configuration and drift status; nodes in ApplyAndAutoCorrect will remediate automatically on their next check-in. Compilation jobs are auditable build artifacts, and role-based access control restricts configuration authorship and node assignment.

Ansible is agentless and well-suited for Linux fleet configuration and ad-hoc orchestration. On Azure, use the azure.azcollection, which supplies modules for compute, networking, Key Vault, and more. Dynamic inventory with the azure_rm plugin discovers hosts from your subscriptions or specific resource groups and tags; credential acquisition can use a service principal, Azure CLI, or managed identity. Integrate with Azure Pipelines by installing Ansible on a Linux agent, logging in via AzureCLI@2 or an Azure Resource Manager service connection, and running playbooks that reference the dynamic inventory, variable groups, and secure files. Ansible excels at idempotent, readable tasks and can complement DSC for Windows-heavy estates by handling cross-platform workflows and orchestration.

Chef and Puppet provide mature policy-as-code models and compliance reporting. On Azure VMs, the Chef and Puppet VM extensions bootstrap agents at provision time, guaranteeing early convergence. Chef Infra uses cookbooks and Policyfiles to pin dependencies and ensure reproducible runs; Chef InSpec expresses compliance-as-code and feeds reports to Chef Automate for drift and control posture. Puppet’s manifests and modules encode desired state, with Code Manager and environments providing promotion flows; Puppet Enterprise delivers centralized reporting, role-based classification, and remediation. Both tools integrate with Azure via modules and resource providers and can coexist with Azure-native DSC when migration or mixed estates require it.

Application Configuration, Immutable Images, and Policy as Code

Azure App Configuration centralizes application settings and feature flags. Feature flags enable progressive rollout: you define flags and, if needed, attach filters such as percentage-based rollout or user targeting through Feature Manager libraries. Labels let you separate values by environment or ring. Configuration snapshots capture a point-in-time, immutable view for a set of keys and labels, allowing consistent, reproducible rollouts across many services without race conditions from concurrent key changes. Key Vault references let you keep secrets in Key Vault while storing only references in App Configuration; the application’s managed identity must have get on the secret, and the client libraries resolve and cache secrets with optional dynamic refresh. Use RBAC and network isolation on both services to protect access.

Immutable infrastructure eliminates configuration drift by rebuilding from a known image instead of mutating hosts. Packer’s azure-arm (now azure) builder creates images from a base OS, runs provisioners (shell, PowerShell, Ansible), and publishes to a Shared Image Gallery with replicated regions and semantic versioning. A golden-image pipeline typically lint-checks Packer templates, builds the image, runs vulnerability and compliance scans (e.g., InSpec), integration-tests it, promotes it to the gallery, and then updates VM Scale Sets or host pools. With VM Scale Sets, rolling or health-based upgrades, and automatic OS image upgrades, you get safe, consistent rollouts and easy rollback by selecting a prior image version.

Policy as code enforces guardrails. Azure Policy definitions are JSON objects with a policyRule that evaluates resource properties and effects such as deny, audit, append, modify, or deployIfNotExists to auto-remediate. Parameterize definitions for reuse; group them with initiatives (policy set definitions) for consistent assignments and centralized compliance tracking. Assign policies at management group, subscription, or resource group scope; enable remediation tasks for modify and deployIfNotExists policies to bring existing resources into compliance. Store policy artifacts in source control, review via pull requests, and deploy via Bicep, ARM, or Terraform for consistent promotion through environments.

For Kubernetes, OPA/Gatekeeper enforces admission-time constraints. ConstraintTemplates define Rego policies and their schemas; Constraints instantiate those policies for a cluster. Common controls include restricting images to trusted registries, requiring labels/annotations, or preventing privileged pods. Gatekeeper integrates with GitOps tools (Flux/Argo CD) and CI testing via conftest. Azure Policy for Kubernetes builds on Gatekeeper to give Azure-native assignment and compliance views across AKS clusters, unifying cloud and cluster governance under one posture dashboard.

Practical Problem Scenario

Spotify must standardize Azure infrastructure, reduce configuration drift, and accelerate safe feature rollouts across microservices that span Windows and Linux, AKS, and VM-based workloads.

  1. Model cloud resources with Bicep modules per domain (networking, data, compute) and deploy them via subscriptions scoped to management groups. This yields typed, maintainable declarations, clear scoping, and reuse without the verbosity of ARM JSON.
  2. Use a small number of linked ARM template specs for shared platform services consumed by multiple teams. Linked templates hosted as template specs provide versioned, immutable artifacts and decouple platform cadence from app teams.
  3. Select Terraform for cross-cloud edge and CDN dependencies, with the azurerm backend storing remote state in Azure Storage per workspace (dev/test/prod) and blob leases for locking. This preserves a single pipeline pattern while isolating state safely and enabling consistent promotion.
  4. Centralize application configuration and feature flags in Azure App Configuration. Feature flags with percentage filters and labels enable ring-based rollouts; configuration snapshots ensure each deployment stage consumes an immutable, audited set of keys.
  5. Store secrets in Azure Key Vault and reference them from App Configuration. Resolving references at runtime with managed identity enables key rotation without redeployments and removes secrets from application config and pipelines.
  6. Adopt immutable images for VM workloads using Packer to build golden images published to Shared Image Gallery. A pipeline runs hardening scripts and InSpec scans, tags images, and promotes only passing versions. VM Scale Sets consume gallery images for blue/green and rolling upgrades, eliminating drift.
  7. Enforce guardrails with Azure Policy initiatives that deny public IP exposure on private subnets, require diagnostic settings to Log Analytics, and auto-deploy backup policies. Assign at the management group level for broad coverage and create remediation tasks for existing resources to converge posture quickly.
  8. Protect AKS with OPA/Gatekeeper by applying constraints that block noncompliant images and privileged pods. Policies are stored and versioned in Git, validated with conftest in CI, and applied via GitOps to ensure cluster state matches policy at all times.
  9. Manage Windows server configuration with Azure Automation DSC. Nodes register with Register-AzAutomationDscNode and use ConfigurationMode=ApplyAndAutoCorrect to detect and remediate drift; compilation jobs emit MOFs per role, and compliance dashboards surface drift for investigation.
  10. Manage Linux configuration and orchestration with Ansible using the azure_rm dynamic inventory and azure.azcollection modules. Azure Pipelines authenticates with managed identity, runs playbooks idempotently, and coordinates updates across services, complementing DSC on Windows.
  11. Leverage Chef InSpec profiles for cross-platform compliance-as-code on both images and running hosts, feeding Chef Automate for reporting. This brings auditable, testable controls into the pipeline and production, ensuring regulatory requirements are continuously validated.

This combination provides typed, modular IaC (Bicep/Terraform), immutable hosts (Packer), centralized app configuration (App Configuration/Key Vault), continuous configuration enforcement (Azure Automation DSC, Ansible), and strong governance (Azure Policy, Gatekeeper). It reduces drift, shortens recovery and rollout times, and makes compliance demonstrable.


CI · All domains · Containerization and Kubernetes

Practice these questions → · Timed practice on ExamRoll.io →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Pass your exam →

Browse Microsoft →

Related guides

All-in-one access

One subscription. Every exam.

Every plan unlocks unlimited answer search, practice tests, AI explanations, and the full resource library — in 20+ languages.

Monthly
24.87
Just €0.83/day
Everything included:
  • Unlimited answer search
  • Unlimited practice tests
  • AI-powered explanations
  • Full resource library
  • 20+ languages
  • Weekly content updates
  • Rewards & referrals
  • Priority support
Start free trial

No credit card required*

Best value
12 months
179.87
Just €0.49/daySave 40%
Everything included:
  • Unlimited answer search
  • Unlimited practice tests
  • AI-powered explanations
  • Full resource library
  • 20+ languages
  • Weekly content updates
  • Rewards & referrals
  • Priority support
Start free trial

No credit card required*

✓ Free plan included · ✓ Cancel anytime · ✓ All plans unlock the full product