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

Question 1

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a policy that requires all pull requests to be built and pass tests before merging. What should you do?

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

Accepted Answer

Add a branch protection rule in the GitHub repository requiring status checks.. GitHub branch protection rules allow you to require status checks to pass before merging a pull request. By configuring a rule that requires the Azure Pipelines build and test status check to succeed, you enforce that all pull requests are validated before they can be merged into the protected branch.

Answer

Set the pipeline trigger to run on pull request.

Answer

Configure pipeline permissions to require approval.

Answer

Add a pre-deployment check on the environment.

Question 2

You are designing a multi-stage YAML pipeline that builds a Docker image and deploys it to Azure Kubernetes Service (AKS). You want to reuse the Docker build steps across multiple stages. What is the best approach?

Accepted Answer

Create a YAML template and reference it from each stage.. YAML templates in Azure Pipelines allow you to define reusable step, job, or stage definitions in a separate file and reference them using the `template` keyword. This approach promotes DRY (Don't Repeat Yourself) principles, simplifies maintenance, and ensures consistency when the same Docker build steps are needed across multiple stages in a multi-stage pipeline.

Answer

Use a stage template.

Answer

Define the steps as variables and reference them.

Answer

Create a separate job and call it from each stage.

Question 3

Your release pipeline includes a 'Deploy to App Service' task for a Linux web app. The deployment fails with 'Error: Failed to deploy web package to App Service'. What should you check first?

Accepted Answer

Review the App Service diagnostic logs.. App Service diagnostic logs provide the most comprehensive and direct source of error details when a deployment fails. The 'Deploy to App Service' task uses Kudu (for Windows) or Oryx (for Linux) to process the deployment; reviewing the diagnostic logs (e.g., via the Azure portal under 'App Service logs' or the 'Log stream') will surface the exact failure reason, such as a missing startup command, incorrect runtime stack, or permission issues.

Answer

Verify that the deployment slot is correctly configured.

Answer

Check the Kudu console for errors.

Answer

Ensure the web.config file is present.

Question 4

Your team uses Azure Pipelines with a YAML-based build pipeline. The pipeline builds a .NET application and runs unit tests. Recently, the unit tests are failing intermittently due to flaky tests. You need to ensure that the pipeline fails only if the same test fails in two consecutive runs. Which feature should you configure?

Accepted Answer

Configure the 'retry failed tests' setting in the pipeline's test tab.. The correct feature is the 'Retry failed tests' setting in the pipeline's test tab. This allows you to configure the number of times a failed test is automatically retried. If the test passes on retry, the pipeline is marked as succeeded with warnings, effectively requiring two consecutive failures for the pipeline to fail. Option A is incorrect because GitHub Actions workflows are not relevant to Azure Pipelines. Option B is for rerunning failed stages, not individual tests. Option C reruns failed jobs, not tests.

Answer

Implement a GitHub Actions workflow with 're-run' trigger.

Answer

Use the 'Re-run failed stages' option in the pipeline run.

Answer

Enable 'Automatically rerun failed jobs' in the pipeline settings.

Question 5

You have an Azure DevOps Pipeline that builds a Node.js application. The pipeline uses template expressions to conditionally run certain jobs based on the branch name. You notice that the condition 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is not evaluating as expected. What is the most likely cause?

Accepted Answer

The variable 'Build.SourceBranch' is not available in the condition context.. The condition 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is used in a template expression, which is evaluated at compile time. However, 'Build.SourceBranch' is a runtime variable that is not available during compile time, causing the condition to fail. Template expressions can only reference parameters or variables defined within the template itself, not runtime pipeline variables. To conditionally run jobs based on the branch, use a runtime condition (e.g., in the 'condition' property of a job or stage) instead of a template expression.

Answer

The variable 'Build.SourceBranch' is misspelled; it should be 'Build.SourceBranchName'.

Answer

The condition syntax is correct but the branch name should not include 'refs/heads/'.

Answer

The condition should be in a template expression instead of a runtime condition.

Question 6

Your organization uses GitHub Actions for CI/CD. You have a workflow that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The workflow uses the 'azure/aks-set-context' action to connect to the AKS cluster. Recently, the workflow started failing with authentication errors. The service principal used has Contributor role on the AKS cluster. What is the most likely cause?

Accepted Answer

The service principal lacks the 'Azure Kubernetes Service Cluster Admin Role' on the AKS cluster.. The 'azure/aks-set-context' action requires the service principal to have the 'Azure Kubernetes Service Cluster Admin Role' (or 'Azure Kubernetes Service Cluster User Role') on the AKS cluster to authenticate and set the kubectl context. The Contributor role on the AKS cluster resource does not grant the necessary Kubernetes RBAC permissions to interact with the cluster's API server. Without the specific AKS role, the action fails with authentication errors.

Answer

The service principal must have 'Owner' role on the resource group containing the AKS cluster.

Answer

The workflow uses an incorrect Kubernetes version.

Answer

The AKS cluster has RBAC disabled, causing authentication failures.

Question 7

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?

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 8

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 9

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 10

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 11

Your team uses Azure Pipelines to deploy a web app to Azure App Service. The deployment uses the 'AzureWebApp@1' task with a deployment slot. You need to ensure that after a successful deployment to the staging slot, the slot swap happens automatically and the staging slot is warmed up before the swap. Which configuration should you use?

Accepted Answer

Set the 'Slot' parameter to 'staging' and enable 'Swap with production' in the task.. The 'AzureWebApp@1' task includes a 'Swap with production' checkbox that, when enabled, automatically performs a slot swap after the deployment to the specified slot (e.g., staging) completes. This ensures the staging slot is warmed up by the deployment process before the swap, as the swap operation respects the warm-up phase of the target slot, preventing downtime and ensuring the production slot receives a fully initialized application.

Answer

Use the 'Azure App Service manage' task to swap slots after deployment.

Answer

Use the 'Azure CLI' task to run 'az webapp deployment slot swap' after deployment.

Answer

Configure the deployment task to deploy to staging and then use a separate task to swap.

Question 12

Which TWO of the following are valid strategies to securely store and use secrets in Azure Pipelines?

Accepted Answer

Link a variable group to Azure Key Vault and reference variables in the pipeline.. Azure Pipelines allows you to link a variable group to Azure Key Vault, enabling secure retrieval of secrets as pipeline variables without exposing them in YAML or logs. This integration uses Azure Key Vault's access policies and managed identities to authenticate, ensuring secrets are never stored in the pipeline definition.

Answer

Use the 'secret' variable type in YAML and hardcode the value.

Answer

Store secrets in a text file in the repository and use a script to read them.

Answer

Use encrypted environment variables in GitHub Actions.

Question 13

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 14

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 15

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.