ScenarioCert
AZ-400 ยท Design and implement build and release pipelines (50-55%)

Design and implement infrastructure as code (IaC)

Practice questions and explanations for the "Design and implement infrastructure as code (IaC)" objective of the Designing and Implementing Microsoft DevOps Solutions exam. Skills measured as of 2026-07-27.

Skills in this objective

  • Recommend a configuration management technology for application infrastructure
  • Implement a configuration management strategy for application infrastructure
  • Define an IaC strategy, including source control and automation of testing and deployment
  • Design and implement desired state configuration for environments, including Azure Automation State Configuration, Azure Resource Manager, Bicep, and Azure Machine Configuration
  • Design and implement Azure Deployment Environments for on-demand self-deployment

Test yourself on this domain

Take the free 15-question test, or unlock all 150 questions and practice this domain on its own.

Sample questions

4 of the 8 questions we have for this objective, shown with the answer and the reasoning.

Design and implement infrastructure as code (IaC)

Wexford County Libraries uses Azure Automation State Configuration to keep 60 Windows Server VMs compliant with a baseline that disables SMBv1 and enforces TLS 1.2. Microsoft has announced that Azure Automation State Configuration retires on September 30, 2027. The team wants a supported Azure service that audits and remediates the same in-guest settings and reports compliance centrally.

Which service should the team migrate to?

  1. AAzure Machine Configuration assigned through Azure PolicyMachine Configuration is the successor for in-guest desired state, using DSC-based packages assigned through Azure Policy to audit or apply and auto-correct settings, with compliance shown in Azure Policy.
  2. BBicep templates redeployed nightlyBicep manages Azure resources through Resource Manager and cannot configure settings inside the guest operating system.
  3. CAzure Automation Update ManagementUpdate Management dealt with patching and has itself been retired in favor of Azure Update Manager; it does not enforce configuration baselines.
  4. DAzure Deployment EnvironmentsDeployment Environments provisions environments from templates for developers and does not manage VM guest configuration.
Why: Desired state configuration exists at two levels: Azure resources, which Resource Manager templates and Bicep define, and settings inside the operating system, which need an in-guest agent. Azure Machine Configuration fills the in-guest role for Azure VMs and Azure Arc-enabled servers, using configuration packages assigned through Azure Policy with audit or apply-and-autocorrect modes. Because Azure Automation State Configuration retires on September 30, 2027, existing DSC configurations should be migrated to Machine Configuration packages. Resource-level IaC cannot reach in-guest settings.
Design and implement infrastructure as code (IaC)

Bluefin Software wants developers on the Payments team to create their own short-lived sandbox environments from approved Bicep templates without being granted Contributor on any subscription. Environments must land in a dedicated sandbox subscription, and the platform team must update templates in one Git repository. Developers should create environments from the developer portal or CLI.

Which three items should the platform team configure in Azure Deployment Environments? Each correct answer presents part of the solution.

  1. AA dev center with a catalog that points to the Git repository containing the environment definitionsThe catalog syncs environment definitions, each with its IaC template and manifest, from a GitHub or Azure Repos repository attached to the dev center.
  2. BAn environment type named Sandbox, enabled on the Payments project and mapped to the sandbox subscription with a deployment identityA project environment type sets the target subscription and the identity that deploys resources, so developers do not need permissions on the subscription themselves.
  3. CA project for the Payments team, with team members assigned the Deployment Environments User roleProjects scope access, and the Deployment Environments User role lets members create environments from the project's allowed definitions and types.
  4. DA Contributor role assignment for each developer on the sandbox subscriptionThe scenario rules out direct Contributor access; the environment type's deployment identity performs the deployment instead.
  5. EAn Azure DevTest Labs lab with formulas for each templateDevTest Labs is a separate service for lab VMs and does not use dev centers, catalogs, or environment types.
Why: Azure Deployment Environments separates the platform team's responsibilities from developer self-service. The dev center holds catalogs of environment definitions from Git, so template updates flow from one repository. Projects group developers, and project environment types define where environments are deployed and which identity performs the deployment. Developers with the Deployment Environments User role can create environments from the developer portal or the CLI without holding subscription permissions.
Design and implement infrastructure as code (IaC)

Northwind Aviation deploys a flight-ops environment to resource group rg-flightops with a Bicep file from a pipeline. When a resource is removed from the Bicep file, it must be deleted from Azure on the next deployment. Administrators must not be able to modify or delete the managed resources in the portal, but the pipeline's service principal must still be able to update them. Resources in the group that the template never managed must not be touched.

Which command should the pipeline run?

  1. Aaz deployment group create -g rg-flightops -f main.bicep --mode Complete, plus a CanNotDelete lock on the groupComplete mode deletes every resource in the group not in the template, including unmanaged ones, and a delete lock would also block the pipeline's deletions.
  2. Baz stack group create -n flightops -g rg-flightops -f main.bicep --action-on-unmanage deleteResources --deny-settings-mode denyWriteAndDelete --deny-settings-excluded-principals <pipeline-sp-object-id>A deployment stack tracks the resources it manages, deletes those removed from the template, applies deny assignments that block changes by others, and exempts the listed pipeline principal.
  3. Caz stack group create -n flightops -g rg-flightops -f main.bicep --action-on-unmanage detachAll --deny-settings-mode nonedetachAll leaves removed resources in Azure, and deny mode none does not stop administrators from changing them.
  4. Daz deployment group create -g rg-flightops -f main.bicep --mode Incremental with an Azure Policy deny effect on the groupIncremental mode never deletes removed resources, and a policy deny effect evaluates resource properties rather than blocking all changes by non-pipeline users.
Why: Bicep deployment stacks make a template the managed owner of a set of resources. The stack records exactly which resources it deployed, so actionOnUnmanage can delete resources that drop out of the template without affecting other resources in the scope, unlike Complete mode. Deny settings create deny assignments such as denyWriteAndDelete, and excluded principals let the deploying identity keep making changes. This combination enforces desired state at the resource level and prevents out-of-band drift.
Design and implement infrastructure as code (IaC)

Hollybrook Shipping uses Terraform to manage its Azure landing zone. Engineers run terraform apply from laptops, and state files are stored locally and sometimes committed to Git. Two engineers recently applied at the same time and corrupted the state. The team wants all applies to run from Azure Pipelines with a shared state that is locked during runs and never stored in the repository.

How should you configure Terraform state?

  1. ACommit terraform.tfstate to a protected branch that only the pipeline can push toState in Git can contain secrets and offers no locking, so concurrent runs can still conflict.
  2. BStore state as a pipeline artifact and download it at the start of each runArtifacts are immutable per run and provide no locking, so two runs can start from the same state and overwrite each other.
  3. CConfigure the azurerm backend with resource_group_name, storage_account_name, container_name, and key that point to a blob container in an Azure Storage accountThe azurerm backend stores state as a blob and uses blob leases to lock it during operations, so concurrent applies are blocked and state stays out of the repository.
  4. DUse the local backend on a self-hosted agent and limit the pipeline to one parallel jobLocal state on one agent is a single point of failure and still allows conflicts if anyone runs Terraform elsewhere.
Why: Terraform state is the source of truth for what Terraform manages, so it must be shared, protected, and locked. The azurerm backend stores state in an Azure Storage blob container and acquires a lease on the blob during plan and apply, which prevents concurrent writes. Combined with a pipeline identity that alone has write access, it removes laptop applies and Git-stored state. Storage account features such as versioning and soft delete add recovery for the state file itself.

Written from the public documentation. Not affiliated with Microsoft. Official study guide.