Design and implement build and release pipelines →mediumMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement build and release pipelines

Exhibit

Refer to the exhibit.
```bicep
resource appService 'Microsoft.Web/sites@2022-09-01' = {
  name: 'myapp-${environment}'  
  location: resourceGroup().location
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      appSettings: [
        {
          name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
          value: appInsights.properties.InstrumentationKey
        }
      ]
    }
  }
}
```

Refer to the exhibit. You are deploying this Bicep file using Azure Pipelines. The 'environment' parameter should be set to 'dev', 'qa', or 'prod' based on the release stage. How should you pass the parameter value?

⚠ Common exam trap

Many candidates confuse YAML pipeline parameters (defined with `parameters:`) with Bicep file parameters, or assume that modifying the Bicep file's default value is a valid dynamic override, when in fact `overrideParameters` is the intended mechanism for stage-specific value injection.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Set a pipeline variable named 'environment' and reference it in the AzureResourceManagerTemplateDeployment task's overrideParameters.

The AzureResourceManagerTemplateDeployment task's `overrideParameters` property allows you to dynamically pass parameter values at deployment time. By setting a pipeline variable named `environment` (which can be scoped per stage) and referencing it as `$(environment)` in `overrideParameters`, you can inject the correct value ('dev', 'qa', or 'prod') based on the release stage without modifying the Bicep file or its defaults.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Define the parameter in the 'parameters:' section of the YAML pipeline.
Why it's wrong here
YAML pipeline parameters are compile-time inputs that control pipeline execution, not values passed to the Bicep deployment. They must be explicitly consumed by tasks, and simply defining a parameter doesn't inject it into the ARM template deployment—use overrideParameters to map pipeline variables to Bicep parameters.
✓
Set a pipeline variable named 'environment' and reference it in the AzureResourceManagerTemplateDeployment task's overrideParameters.
Why this is correct
The overrideParameters field in the AzureResourceManagerTemplateDeployment task accepts key-value pairs that override Bicep/ARM template parameters at deployment time. By setting a pipeline variable and referencing it like -environment $(environment), you dynamically supply the environment-specific value per stage, leveraging Azure DevOps native variable scoping.
✗
Use a task to replace the string '${environment}' in the Bicep file before deployment.
Why it's wrong here
Bicep files compile into ARM templates where parameter substitution is handled by the deployment engine; manually replacing placeholders is redundant and fragile. It also breaks the declarative nature of Bicep and makes the pipeline less maintainable because you're modifying code artifacts instead of passing parameters.
✗
Modify the Bicep file to include a default value for environment.
Why it's wrong here
A default value would apply only when no override is provided, so it cannot vary across deployment stages without explicit overrides. It might be useful for local development, but in a multi-stage pipeline you still need to pass different values via overrideParameters, otherwise all stages would deploy to the same environment.

Visual reference

Go deeper

AZ-400 Practice Question: Design and implement build and release pipelines

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question