AZ-400 Practice Test 6 — 10 Questions

Question 1

You have a release pipeline that deploys to multiple stages (Dev, QA, Prod). You want to automatically deploy to Dev and QA after a successful build, but require a manual approval for Prod. Which deployment strategy should you use?

Accepted Answer

Set pre-deployment approvals on the Prod stage.. Pre-deployment approvals control whether a release can start deploying to a stage. By setting a pre-deployment approval on the Prod stage only, Dev and QA will deploy automatically (since they have no approval requirement), while Prod requires manual sign-off before deployment begins. This matches the requirement exactly.

Answer

Set pre-deployment approvals on the Dev and QA stages.

Answer

Use a post-deployment approval on the QA stage.

Answer

Disable the automatic trigger for all stages.

Question 2

You need to trigger a pipeline whenever changes are pushed to the 'main' branch of a GitHub repository. Which trigger should you configure in the YAML pipeline?

Accepted Answer

trigger:
  branches:
    include:
    - main. Option A is correct because the `trigger` keyword at the root of a YAML pipeline defines the CI trigger that automatically starts a pipeline run when changes are pushed to the specified branch. By including `main` under `branches.include`, the pipeline will trigger on any push to the `main` branch of the GitHub repository, which is the standard way to set up a CI trigger for a single branch.

Answer

pr:
  branches:
    include:
    - main

Answer

resources:
  repositories:
  - repository: self
    trigger:
      branches:
        include:
        - main

Answer

schedules:
- cron: "0 0 * * *"
  branches:
    include:
    - main

Question 3

You have a YAML pipeline that deploys to multiple environments. The pipeline uses environment approvals. You need to ensure that the pipeline waits for manual approval before deploying to the production environment. The production environment is named 'Production'. Which configuration should you add to the deployment job?

Accepted Answer

Add 'environment: Production' to the deployment job and configure approvals on the environment in the Azure DevOps portal. Option A is correct because environment approvals in Azure DevOps are configured on the environment resource itself, not in the pipeline YAML. By adding 'environment: Production' to the deployment job, the pipeline references the environment, and the manual approval gate is enforced by the approvals configured on that environment in the Azure DevOps portal. This ensures the pipeline waits for approval before proceeding to the production deployment job.

Answer

Add 'approvals: Production' to the deployment job

Answer

Add 'checks: Production' to the deployment job

Answer

Add 'dependsOn: ProductionApproval' and use a separate stage for approval

Question 4

You are configuring a YAML pipeline that deploys to multiple environments. The pipeline should automatically trigger when changes are pushed to the main branch, but only if the build artifact changes. Which trigger configuration should you use?

Accepted Answer

trigger: paths: include: - src/*. Option B is correct because the `trigger: paths: include: - src/*` configuration specifies that the pipeline should only trigger when changes are pushed to the `main` branch AND those changes affect files under the `src/` directory. This ensures that the pipeline runs only when the build artifact (source code) changes, not for other changes like documentation or configuration files. The `paths` filter works in conjunction with the branch filter to provide fine-grained control over pipeline triggers.

Answer

trigger: branches: include: - main

Answer

pr: branches: include: - main

Answer

resources: containers: - container: myContainer

Question 5

You are designing a release pipeline that uses Azure App Service deployment slots. The pipeline must perform a swap after deployment to the staging slot. Which three tasks or actions should you include in the pipeline? (Select all that apply.)

Accepted Answer

Azure App Service deploy: Deploy to staging slot. Option A is correct because the Azure App Service deploy task with the 'Deploy to staging slot' action is the standard method to deploy an application to a staging slot before a swap. This ensures the new release is validated in an isolated environment without affecting the production slot.

Answer

Azure App Service manage: Delete staging slot

Answer

Azure CLI: Run az webapp deployment slot swap

Question 6

You have a multi-stage YAML pipeline with stages: Build, Test, and Deploy. The Deploy stage requires approval from a specific user group. You want to ensure that the approval request is sent only after the Test stage completes successfully. Which configuration should you use?

Accepted Answer

Define an environment with required approvers and reference it in the Deploy stage.. Option B is correct because Azure Pipelines environments allow you to define required approvers (user groups) that must approve a deployment before it proceeds. By referencing the environment in the Deploy stage, the approval request is automatically triggered only after the preceding Test stage completes successfully, since stages execute sequentially by default.

Answer

Add a manual validation task in the Deploy stage.

Answer

Use the 'condition' keyword: condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')

Answer

Configure branch policies on the main branch.

Question 7

You are designing a pipeline that must run tasks in a container. The container needs access to Azure resources using a managed identity. Which two configurations are required? (Choose two.)

Accepted Answer

Enable a system-assigned managed identity on the agent VM.. Option A is correct because a system-assigned managed identity on the agent VM allows the container to authenticate to Azure resources without storing credentials. Option D is correct because setting the 'identity' field in the container resource definition explicitly assigns that managed identity to the container, enabling it to request tokens from Azure AD for resource access.

Answer

Use the 'docker login' command in the pipeline.

Answer

Add a service principal connection to the pipeline.

Answer

Use the Azure CLI task with '–identity' flag.

Question 8

You are creating a YAML pipeline that builds a .NET Core application. The pipeline must use a multi-stage build with separate stages for 'Build', 'Test', and 'Deploy'. The 'Deploy' stage should only run if both 'Build' and 'Test' succeed. Which two conditions can you use to achieve this? (Select all that apply.)

Accepted Answer

In the Deploy stage, set 'dependsOn: [Build, Test]'. Option A is correct because setting 'dependsOn: [Build, Test]' in the Deploy stage ensures that the Deploy stage only starts after both the Build and Test stages have completed. By default, a stage runs only if all its dependencies succeed, so this alone meets the requirement without needing an explicit condition. This is the standard way to enforce sequential execution in multi-stage YAML pipelines.

Answer

In the Deploy stage, set 'condition: and(succeeded('Build'), succeeded('Test'))'

Answer

In the Deploy stage, set 'dependsOn: [Build, Test]' and 'condition: stageDependencies.Build.result == 'Succeeded''

Question 9

Your pipeline runs on a Microsoft-hosted agent. You need to securely reference an Azure Key Vault secret in a pipeline variable without exposing the value in logs. Which variable group type should you use and how should you reference the secret?

Accepted Answer

Create a variable group linked to Key Vault, then reference as $(KeyVaultName.SecretName). Option A is correct because linking a variable group to Azure Key Vault allows you to securely reference secrets as pipeline variables without exposing their values in logs. The $(KeyVaultName.SecretName) syntax retrieves the secret value at runtime from Key Vault, and the value is automatically masked in any output.

Answer

Use the 'Azure Key Vault' task to download secrets and assign to variables

Answer

Store the secret as a plain text variable and mark it as 'secret'

Answer

Reference the secret directly as $(SecretName) from a library variable group

Question 10

A team uses a monorepo with multiple projects in one Git repository. They want to enforce that each commit message must reference a work item from Azure Boards. Which branch policy should they configure?

Accepted Answer

Require a work item linking policy in branch policies. The 'Require a work item linking policy' in Azure Repos branch policies enforces that every pull request must be associated with at least one Azure Boards work item before it can be completed. This policy directly meets the requirement to ensure each commit message references a work item, as the linking is validated at merge time.

Answer

Automatically include work items in pull request descriptions

Answer

Configure a minimum number of reviewers policy

Answer

Use a build validation policy to check commit messages