AZ-400 - Design and Implement Build and Release Pipelines - Section 3.12

Define and implement an infrastructure as code strategy and configuration management, including ARM, Bicep, desired state configuration, and Azure Deployment Environments.

Define infrastructure as code using Bicep and Azure Resource Manager templates, and apply desired state configuration through Azure Automation State Configuration to enforce consistent server configuration. Use Azure Deployment Environments to give development teams self-service, policy-governed environment provisioning within a pipeline.

BicepAzure Resource Manager templatesdesired state configurationAzure Automation State ConfigurationAzure Deployment Environments

Practice question for this objective

Free sampleDesign and Implement Build and Release Pipelinesmedium

A team registers an Azure Kubernetes Service cluster as a resource inside a "production" environment in "Azure Pipelines", then writes a deployment job that targets that specific resource within the environment. They want the approvals and checks they configured on the environment to apply, while the job acts only against that registered cluster. How should the deployment job reference the target so both conditions hold?

jobs:
  - deployment: RolloutWeb
    environment:
      name: production
      resource: aks-prod-cluster
    strategy:
      runOnce:
        deploy:
          steps:

ASpecify both the environment name and the registered resource under the deployment job's environment block, so checks apply and the job binds to that cluster resource. Correct
BReference the environment by name only and omit the resource, then add a manual step inside the job that runs kubectl against the chosen cluster context.
CReference the cluster resource alone without naming the environment, relying on the resource registration to carry the approvals and checks across to the job.
DUse a standard job with a service connection to the cluster, since deployment jobs cannot target an individual registered resource within an environment.

Bind a deployment job to a registered environment resource by naming both the environment and the resource so environment checks still apply. A deployment job that names an environment is subject to that environment's approvals and checks. Adding the resource field scopes the job to a specific registered resource, such as a Kubernetes cluster, inside that environment. Both the name and the resource are needed so the checks apply and the deployment targets the intended resource.

Why A is correct: Giving the environment name plus the resource binds the deployment job to the registered Kubernetes resource while still subjecting the run to the environment's approvals and checks, satisfying both conditions.

Why B is wrong: Naming the environment alone still triggers its checks, but omitting the resource means the job is not scoped to the registered cluster, so a scripted context switch loses the resource binding the team wants.

Why C is wrong: This is tempting because the resource lives inside the environment, but the deployment job must name the environment for its checks to bind; a resource reference without the environment name does not attach environment-level approvals.

Why D is wrong: Deployment jobs can target a resource inside an environment, and a standard job bypasses the environment entirely, so its approvals and checks would never run on the deployment.

See more AZ-400 practice questions, answers explained.

More in this domain

Back to all Design and Implement Build and Release Pipelines objectives, or the AZ-400 cert hub.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.