AZ-400 Design and implement build and release pipelines Practice Test 2 — 15 Questions

Question 1

Your release pipeline deploys to Azure App Service using deployment slots. You need to ensure that traffic is gradually shifted to the new slot over 30 minutes, and if performance issues occur, it should automatically roll back. Which deployment strategy should you implement?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use the 'Deploy to Azure App Service' task with the 'Deploy to Slot' option and configure auto-swap with monitoring.. The 'Deploy to Azure App Service' task with 'Deploy to Slot' and auto-swap with monitoring enables a gradual traffic shift over a specified duration (e.g., 30 minutes) using Azure's swap-with-preview and auto-rollback capabilities. When performance issues are detected via Application Insights or health checks, the swap is automatically aborted, rolling back to the previous slot. This meets the requirement for gradual shifting and automatic rollback without manual intervention.

Answer

Use two separate deployment slots (blue/green) and manually swap after validation.

Answer

Use a canary deployment with multiple slots and manual approval gate.

Answer

Use an A/B testing deployment by deploying to two different App Services and routing traffic via Traffic Manager.

Question 2

You are configuring a branch policy for the main branch using the Azure DevOps REST API. The JSON above is the policy configuration. A developer pushes a new commit to an existing pull request. What happens to the existing approvals?

Accepted Answer

The existing approvals remain valid.. By default, Azure DevOps branch policies do not automatically reset approvals when a new commit is pushed to a pull request. The policy configuration shown includes the 'resetOnPush' property set to false (or it is not enabled), which means existing approvals remain valid even after new commits are pushed. Only if 'resetOnPush' is explicitly set to true would approvals be invalidated.

Answer

The policy blocks the push until re-reviewed.

Answer

The pull request is automatically rejected.

Answer

All existing approvals are reset.

Question 3

Your build pipeline uses a self-hosted agent. The agent is running low on disk space. You need to clean up the agent's working directory after each build. Which option should you configure in the pipeline?

Accepted Answer

Use the 'clean' parameter in the checkout step of the YAML pipeline.. The `clean` parameter in the YAML checkout step is the native, built-in way to instruct the agent to delete the sources directory before or after the build. Setting `clean: true` or `clean: all` ensures the working directory is purged, directly addressing the low disk space issue without requiring additional tasks or marketplace extensions.

Answer

Set the 'Clean' option to 'Sources' in the pipeline settings.

Answer

Add a 'Delete Files' task at the end of the pipeline to delete the sources directory.

Answer

Add a 'Cleanup' task from the marketplace to clean the agent.

Question 4

Your team uses GitHub for source control and Azure Pipelines for CI/CD. You need to trigger a pipeline automatically when a pull request is created against the main branch. Which trigger type should you configure in the YAML pipeline?

Accepted Answer

pr:. The `pr:` trigger in Azure Pipelines YAML is specifically designed to automatically start a pipeline when a pull request is created or updated against a specified branch. By default, `pr:` triggers are enabled for all branches; however, to ensure the pipeline only runs for PRs targeting `main`, you configure `pr: main`. This triggers the pipeline on PR creation/update without needing a separate branch policy.

Answer

trigger:

Answer

schedules:

Answer

resources:

Question 5

Refer to the exhibit. A developer pushes a commit to the main branch. Which stages will run?

Accepted Answer

Only the Build stage.. The exhibit shows that the Build stage has a trigger condition that matches the 'main' branch, and the Test stage does not have a trigger condition that is satisfied by the push (e.g., it is set to a different branch condition or to manual). Therefore, when a commit is pushed to main, only the Build stage is triggered automatically; the Test stage does not run.

Answer

Only the Test stage.

Answer

Neither stage.

Answer

Both Build and Test stages.

Question 6

Which THREE of the following are best practices for managing secrets in Azure Pipelines? (Select THREE.)

Accepted Answer

Use Azure Key Vault to store secrets and link them to variable groups.. Option B is correct because Azure Key Vault is the recommended centralized secret store, and linking it to a variable group lets pipelines consume secrets without embedding them in YAML or source control. Option D is correct because variable groups support pipeline permissions (and role-based access), so restricting which pipelines and users can read or use a group enforces least privilege and prevents unauthorized secret access. Option E is correct because mapping secret variables to environment variables explicitly (for example, via env: in a script task) keeps them out of command-line arguments and log output, since Azure Pipelines masks registered secrets but still recommends explicit mapping to avoid accidental exposure. Option A is wrong because hardcoding secrets in YAML exposes them in source control and build logs; secrets should be stored in Key Vault or secret variables. Option C is wrong because enabling 'Allow scripts to access the OAuth token' grants the pipeline's script access to the system access token, which increases privilege and is not a secret-management best practice.

Answer

Hardcode secrets directly in the YAML file and use variable substitution at runtime.

Answer

Enable 'Allow scripts to access the OAuth token' for all build pipelines.

Question 7

You are implementing a multi-stage YAML pipeline in Azure Pipelines for a microservices application. You need to ensure that the 'deploy' stage only runs if the 'build' stage succeeds and that the 'test' stage runs in parallel with 'build' for different services. How should you structure the pipeline?

Accepted Answer

Define stages 'build', 'test', 'deploy' with 'dependsOn: []' on 'test' and 'dependsOn: build' on 'deploy'. Setting `dependsOn: []` on the 'test' stage removes any implicit dependency, allowing it to run in parallel with the 'build' stage (since stages without explicit dependencies default to running sequentially after the previous stage). The 'deploy' stage with `dependsOn: build` ensures it only runs after the 'build' stage succeeds, as Azure Pipelines stages by default only run if all dependencies succeed. This structure meets the requirement: 'test' runs in parallel with 'build' for different services, and 'deploy' depends on 'build' success.

Answer

Define stages 'build', 'test', 'deploy' with 'dependsOn: build' on 'test' and 'dependsOn: test' on 'deploy' but use 'condition: always()' on test

Answer

Define stages 'build', 'test', 'deploy' with 'dependsOn: build' on 'test' and 'dependsOn: test' on 'deploy'

Answer

Define stages 'build', 'test', 'deploy' with no dependsOn; by default they run sequentially

Question 8

You need to ensure that a release pipeline in Azure Pipelines automatically deploys to production only if the deployment to staging succeeds and all manual intervention checks pass. What is the best way to configure this?

Accepted Answer

Add a pre-deployment approval gate on the production stage. A pre-deployment approval gate on the production stage is the standard and direct way to require manual approval before deploying to production. Because the pipeline executes stages sequentially, production only runs after staging succeeds, ensuring the 'deployment to staging succeeds' condition automatically. The manual intervention checks are fulfilled by the pre-deployment approval. While a post-deployment approval on staging could also block progress to production, it is not the 'best' or only correct answer; it is less directly tied to protecting the production environment.

Answer

Configure a branch policy on the main branch

Answer

Assign a deployment group to the production stage

Answer

Add a post-deployment approval gate on the staging stage

Question 9

Which TWO actions should you take to implement a gated check-in policy in Azure Repos that triggers a build before changes are merged?

Accepted Answer

Configure a build validation policy on the branch. Option A is correct because configuring a build validation policy on the target branch in Azure Repos branch policies is exactly the mechanism that queues a build when a pull request targets that branch, blocking completion until the build succeeds. Option B is correct because a branch policy requiring a successful build to complete is the gated check-in behavior itself—the pull request cannot be merged until the validation build passes, which is what enforces the gate. Option C is not correct because a CI trigger merely runs the pipeline on commits to a branch; it does not gate pull request completion. Option D is not correct because there is no separate 'pre-merge' build setting; gating is achieved through branch policies, not a pipeline mode. Option E is not correct because a manual build requirement is not an automated gated check-in policy and does not enforce the gate through Azure Repos.

Answer

Enable continuous integration (CI) trigger on the build pipeline

Answer

Set the build to run a 'pre-merge' validation

Answer

Require a manual build before merging

Question 10

Your team uses Azure Pipelines for CI/CD. You need to ensure that a secret variable stored in Azure Key Vault is available to a build pipeline without exposing it in logs. What should you do?

Accepted Answer

Store the secret in a variable group linked to Key Vault and reference it without marking it secret.. To securely use a secret from Azure Key Vault in an Azure Pipeline without exposing it in logs, the simplest and recommended approach is to create a variable group linked to the Key Vault. When you reference the secret by name, Azure Pipelines automatically masks its value in logs. There is no need to manually mark the variable as secret; the linked variable group handles it. The Azure Key Vault task is an alternative but not the primary method; additionally, the task automatically creates secret variables and does not require manual mapping.

Answer

Add the secret as a plain text variable in the pipeline YAML.

Answer

Use a Key Vault task to fetch the secret and map it to a pipeline variable marked 'secret'.

Answer

Add the secret to the repository's .env file and use a script to read it.

Question 11

You are designing a release pipeline for a critical application. The pipeline must automatically roll back to the previous version if the deployment to staging fails health checks. Which deployment strategy should you implement?

Accepted Answer

Rolling update with health checks and automatic rollback.. A rolling update with health checks and automatic rollback is the only strategy that fully automates the deployment, validates health after each batch of pods is updated, and automatically reverts to the previous version if health checks fail. This meets the requirement for an automated rollback on staging health check failure without manual intervention.

Answer

Canary deployment with manual promotion.

Answer

Blue-green deployment with manual swap.

Answer

Recreate deployment by redeploying the same version.

Question 12

Your CI pipeline includes a step that runs unit tests. You want to fail the pipeline if code coverage drops below 80%, but continue if tests pass with lower coverage. How should you configure the test step?

Accepted Answer

Use the 'PublishCodeCoverageResults' task with a 'codeCoverageThreshold' setting.. The 'PublishCodeCoverageResults' task with a 'codeCoverageThreshold' setting is correct because it allows you to define a minimum coverage percentage (e.g., 80%) and fail the pipeline if that threshold is not met, while still allowing the pipeline to continue if tests pass but coverage is lower. This task evaluates the coverage report after tests run and enforces the threshold as a build failure condition, not a test failure.

Answer

Configure a quality gate in the release pipeline to check coverage.

Answer

Add a script task that reads the coverage report and prints a warning.

Answer

Use the VSTest task with the 'codeCoverageEnabled' option set to true.

Question 13

Your release pipeline deploys to Azure App Service using slots. You need to ensure that after swapping, the warmup request is sent to the production slot before traffic is fully routed. What should you configure?

Accepted Answer

Enable auto swap for the deployment slot and configure a custom warmup path.. Auto swap for a deployment slot performs a slot swap and then automatically sends an HTTP warmup request to the application on the target (production) slot before completing the swap, ensuring the app is initialized and ready. Configuring a custom warmup path lets you target a specific endpoint (e.g., /health or /warmup) that the platform pings. This is the built-in mechanism App Service provides specifically for the scenario described.

Answer

Add a health check to the App Service.

Answer

Perform a manual swap and then send a warmup request via a script.

Answer

Configure slot-specific app settings to enable warmup.

Question 14

You have the YAML pipeline exhibit above. The pipeline fails with: 'The pipeline is not valid. Could not find the template file shared-templates/build-steps.yml.' What is the most likely cause?

Accepted Answer

The template path is incorrect because it should be relative to the repository root; the repository name is 'myorg/shared-templates', so the path should be 'build-steps.yml'.. When referencing a template from another repository in Azure Pipelines, the `repository` property specifies the repository name (e.g., `myorg/shared-templates`), and the template path must be relative to the root of that repository. The error indicates the pipeline cannot find the file, meaning the path `shared-templates/build-steps.yml` is incorrect; it should be just `build-steps.yml` since the repository name is already declared in the `repository` field. The path should not include the repository name again.

Answer

The checkout step for 'shared-templates' must be before the template reference, which it is.

Answer

The template file is missing from the shared-templates repository.

Answer

The ref 'refs/heads/main' does not exist in the shared-templates repository.

Question 15

You ran the above Azure CLI command to check the deployment source of an Azure Web App. The web app is not deploying automatically when commits are pushed to the main branch. Based on the output, what is the most likely cause?

Accepted Answer

The continuous deployment sync is not enabled; you need to enable it or configure a pipeline.. The stem says 'You ran the above Azure CLI command' but no command or output is provided. The explanation admits these assertions cannot be validated and states the question must include the command and output. Therefore, the question is incomplete and the marked correct answer cannot be confirmed.

Answer

Deployment rollback is disabled, preventing automatic deployments.

Answer

The branch is set to 'main' but commits are pushed to 'master'.

Answer

The repo URL uses GitHub but Azure Web Apps only supports Azure Repos.