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

Question 1

You have a multi-stage YAML pipeline in Azure DevOps that deploys to multiple environments. The pipeline uses a deployment job with environment approvals. You need to ensure that the deployment to the production environment is only triggered after a manual approval is granted. However, you also want the deployment to automatically roll back if the post-deployment health check fails. Which configuration should you implement?

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

Accepted Answer

Enable 'Auto-revert' on the production environment and set post-deployment conditions.. Azure DevOps environments support an 'Auto-revert' setting that automatically triggers a rollback to the previous successful deployment when a post-deployment health check (defined via post-deployment conditions) fails. This combines manual approval (pre-deployment approvals on the environment) with automatic rollback, meeting both requirements without additional tasks or release pipelines.

Answer

Use a release pipeline with a pre-deployment approval and a post-deployment automatic rollback trigger.

Answer

Configure pre-deployment approvals on the production environment and use a post-deployment gate that fails the deployment.

Answer

Configure pre-deployment approvals and add a manual intervention task to roll back if health check fails.

Question 2

Your team uses Azure Repos Git and wants to enforce a policy that all pushes to the main branch must pass a build validation pipeline. The pipeline runs unit tests and code analysis. You need to configure this in the branch policy. Which setting should you enable?

Accepted Answer

Build validation. The Build validation policy in Azure Repos Git enforces that a specified pipeline must succeed before a pull request can be merged into the target branch. This directly meets the requirement to run unit tests and code analysis on all pushes to the main branch, blocking merges if the build fails.

Answer

Require comment resolution

Answer

Linked work items

Answer

Limit merge types

Question 3

Your organization uses GitHub Actions with self-hosted runners on Azure virtual machines. You notice that some workflows are taking longer than expected because runners are busy. You need to improve the performance without adding more permanent runners. Which solution should you implement?

Accepted Answer

Implement auto-scaling for self-hosted runners using a scale set or Kubernetes-based runner controller.. Auto-scaling self-hosted runners using a scale set or a Kubernetes-based runner controller (e.g., actions-runner-controller) dynamically provisions and deprovisions runner instances based on workflow demand. This eliminates idle runner waste while ensuring sufficient capacity during peak loads, directly addressing the bottleneck without adding permanent infrastructure.

Answer

Migrate all workflows to GitHub-hosted runners.

Answer

Reduce the number of concurrent jobs in each workflow.

Answer

Increase the size of the existing self-hosted runner VMs to handle more jobs.

Question 4

You have a YAML pipeline that builds a Java project using Maven. The pipeline uses a private artifact feed in Azure Artifacts. You need to authenticate to the feed from the pipeline. Which authentication method should you use?

Accepted Answer

Use the 'MavenAuthenticate' task with a settings.xml file.. The 'MavenAuthenticate' task is specifically designed to authenticate Maven builds against Azure Artifacts feeds. It injects credentials into a settings.xml file, which Maven uses to resolve dependencies from the private feed. This task handles the OAuth token exchange required for Azure DevOps authentication.

Answer

Use the 'PipAuthenticate' task with a pip.conf file.

Answer

Use the 'npmAuthenticate' task with a .npmrc file.

Answer

Use the 'NuGetAuthenticate' task with a nuget.config file.

Question 5

Which THREE of the following are valid considerations when designing a release pipeline to deploy to multiple environments (dev, test, prod) using Azure Pipelines YAML?

Accepted Answer

Use variable groups scoped to environments to override variables per stage.. Variable groups can be reused across pipelines and stages. In a multi-stage YAML pipeline, you can use different variable groups for each environment by referencing them in the `variables` section of each stage (e.g., a variable group for dev, test, and prod). This allows you to override values such as connection strings per environment without duplicating pipeline code. For production deployments, you should configure approvals and checks on the Azure Pipelines environment resource (e.g., 'prod') to require manual sign-off before the deployment job runs. Stage-level approvals do not exist in Azure Pipelines; approvals are always attached to an environment or a service connection. For branch-based filtering, you can use stage `condition` expressions, such as `and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`, to control which stages run based on the source branch. To reduce duplication, use YAML templates with parameters to define a single deployment template that is reused across environments rather than creating separate templates per environment.

Answer

Use stage-level approvals to gate each stage.

Answer

Use YAML templates to define each environment's deployment steps.

Question 6

Which TWO of the following are true about multi-stage pipelines in Azure Pipelines?

Accepted Answer

Stages can run in parallel if dependencies allow.. Azure Pipelines allows stages to run in parallel when their dependencies are configured appropriately. By default, stages run sequentially, but you can use the 'dependsOn' keyword to define dependencies, and if a stage has no dependencies on another, it can execute concurrently. This enables faster pipeline execution by running independent stages simultaneously.

Answer

Each stage can contain only one job.

Answer

Each stage must run on the same agent.

Answer

Stages cannot have conditions.

Question 7

You have an Azure Pipelines YAML file with the following trigger configuration:

```yaml
trigger:
  branches:
    include:
    - main
  paths:
    include:
    - /src/*
```

The team reports that the pipeline does not trigger when changes are pushed to the main branch that modify files outside the /src folder. What is the most likely reason?

Accepted Answer

The path filter restricts the trigger to only changes in /src/.. The most likely reason is that a path filter is configured in the trigger, restricting the pipeline to only trigger on changes under /src/. The other options are incorrect because they either refer to minor syntax issues or irrelevant details.

Answer

The trigger syntax is incorrect; 'branch' should be 'branches'.

Answer

The script step is missing a display name.

Answer

The pool vmImage is not specified correctly.

Question 8

Refer to the exhibit. This multi-stage YAML pipeline has a variable 'publishEnabled' set to false. The team wants the Publish stage to run only when 'publishEnabled' is true. However, the Publish stage never runs, even when the variable is changed to true at queue time. What is the most likely cause?

Accepted Answer

The variable 'publishEnabled' is not settable at queue time; it is a compile-time variable.. In Azure DevOps YAML pipelines, variables set at the pipeline level (not in a variable group or at queue time) are evaluated at compile time, not at runtime. When 'publishEnabled' is defined as a simple variable in the YAML file, changing it at queue time does not affect the compiled pipeline stages; the condition is evaluated against the compile-time value (false), so the Publish stage never runs. To make it settable at queue time, the variable must be defined as a runtime parameter, or explicitly defined in the pipeline UI with the 'Let users override this value when running this pipeline' checkbox enabled.

Answer

The condition syntax is wrong; it should use 'eq(variables.publishEnabled, true)'.

Answer

The Publish stage is missing 'dependsOn: Build'.

Answer

The 'dependsOn' syntax is incorrect; it should be 'dependsOn: Build'.

Question 9

You are designing a release pipeline for a critical production application. The pipeline must ensure that changes are deployed to a staging environment first, and if integration tests pass, they are automatically deployed to production. However, if the tests fail, the deployment to production must be blocked. What is the best approach?

Accepted Answer

Create a multi-stage YAML pipeline with a gate on the production stage that evaluates test results from the staging stage.. A multi-stage YAML pipeline with a gate on the production stage allows you to evaluate the results of integration tests run in the staging stage before proceeding to production. The gate can be configured to check for test pass/fail status from the staging stage, blocking the production deployment if tests fail. This approach provides a clear, automated approval flow within a single pipeline definition, aligning with the requirement for conditional promotion based on test results.

Answer

Create a single stage in the pipeline with conditional tasks to deploy to staging and then to production based on test results.

Answer

Create two separate pipelines: one for staging and one for production. Use a pipeline trigger to run the production pipeline after staging completes.

Answer

Use a classic release pipeline with pre-deployment approvals on the production stage.

Question 10

Which TWO features in Azure Pipelines allow you to enforce separation of duties between development and operations teams? (Choose two.)

Accepted Answer

Approvals and checks on environments. Approvals and checks on environments (B) enforce separation of duties by requiring designated approvers (e.g., operations team members) to approve a deployment before it proceeds, ensuring that development cannot directly push to production. Environment security roles (D) allow you to define who can create, view, or manage environments, restricting developers from modifying production environments without operations oversight.

Answer

Pipeline decorators

Answer

Service connections with different scopes

Answer

Branch policies on the main branch

Question 11

Refer to the exhibit. The YAML pipeline triggers on commits to main and develop branches, and pull requests targeting develop. A developer pushes a commit directly to main. What will happen?

Accepted Answer

The pipeline runs once for the CI trigger.. The pipeline is configured with a CI trigger for both main and develop branches, and a PR trigger only for pull requests targeting develop. When a developer pushes a commit directly to main, the CI trigger fires because the push matches the main branch, causing the pipeline to run once. The PR trigger does not activate because there is no pull request involved.

Answer

The pipeline does not run because the PR trigger requires a pull request.

Answer

The pipeline runs twice: once for the CI trigger and once for the PR trigger.

Answer

The pipeline runs once for the PR trigger only.

Question 12

Which THREE are valid approaches to securely store secrets used in Azure Pipelines? (Choose three.)

Accepted Answer

Secret variables defined in the pipeline UI. Secret variables defined in the pipeline UI (B) are encrypted at rest and masked in logs, preventing exposure in source control. The Azure Key Vault task (C) retrieves secrets from Azure Key Vault at runtime, avoiding storage in Azure DevOps. Variable groups linked to Azure Key Vault (D) allow you to reference Key Vault secrets directly as pipeline variables, keeping them out of YAML and providing centralized access control. All three approaches ensure secrets are not stored in plaintext in repositories or pipeline definitions.

Answer

Inline secret variables defined in the YAML file

Answer

Environment variables set on the build agent

Question 13

Refer to the exhibit. This is a deployment job definition in a multi-stage YAML pipeline. The deployment fails because the Kubernetes service connection 'aks-prod' cannot be found. What is the most likely cause?

Accepted Answer

The service connection 'aks-prod' does not exist in the Azure DevOps project.. The error message explicitly states that the Kubernetes service connection 'aks-prod' cannot be found. In Azure DevOps, a service connection is a stored credential set that must exist in the project before it can be referenced in a YAML pipeline. If the connection name is misspelled, deleted, or never created, the pipeline will fail at the deployment job stage regardless of other configurations.

Answer

The approval for production environment is blocking the deployment.

Answer

The agent pool does not have access to the AKS cluster.

Answer

The namespace 'prod' does not exist in the AKS cluster.

Question 14

You have a multi-stage pipeline that deploys to multiple regions. You want to ensure that if the deployment to one region fails, the pipeline does not proceed to the next region. What is the best way to implement this?

Accepted Answer

Define stage dependencies with 'dependsOn' and set 'condition' to 'succeeded()'.. Azure Pipelines allows you to define stage dependencies using 'dependsOn' and control execution flow with 'condition'. By setting each region deployment as a separate stage that depends on the previous region's stage succeeding (condition: 'succeeded()'), the pipeline will automatically halt if any region deployment fails, preventing progression to subsequent regions.

Answer

Use pipeline decorators to inject error handling steps.

Answer

Add a manual approval between regions.

Answer

Configure each region deployment as a separate stage with no dependencies.

Question 15

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets are not exposed in build logs. What should you use?

Accepted Answer

GitHub Secrets. GitHub Secrets (Option C) is the correct choice because GitHub Actions provides a built-in encrypted secrets store that automatically masks secret values in build logs. When you reference a secret using `${{ secrets.MY_SECRET }}`, GitHub ensures the value is never printed or exposed in workflow output, unlike plaintext or environment variables that can be inadvertently logged.

Answer

Hardcoded values in the workflow YAML

Answer

Environment variables in the workflow

Answer

Artifact storage