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

Question 1

Which THREE conditions must be met for you to use the 'Approvals' feature in Azure Pipelines to control deployments to a production environment? (Choose three.)

Accepted Answer

The approver must have the 'Approve pipeline permissions' permission for the environment.. The 'Approvals' feature in Azure Pipelines requires an environment to be defined in the pipeline. You must add an approval check to that environment, which can be done in either a classic release pipeline or a YAML pipeline that references the environment as a resource. Additionally, the approver(s) - whether individual users or groups - must have the 'Approve pipeline permissions' permission on that environment. Without an environment resource, the approval check cannot be configured; without the permission, approval requests cannot be validated.

Answer

The approver must be an individual user, not a group.

Answer

The approval must be configured in the release pipeline's pre-deployment conditions.

Question 2

Which TWO are valid strategies for reducing build times in Azure Pipelines? (Choose two.)

Accepted Answer

Implement caching for package dependencies (e.g., npm, NuGet, Maven) to avoid restoring on every build.. Caching package dependencies (e.g., npm, NuGet, Maven) avoids restoring them on every build, reducing download time. Incremental builds (e.g., using 'dotnet build --no-restore' with appropriate flags or MSBuild's incremental building) skip projects that haven't changed, reducing compilation time. Option A is incorrect because reducing parallel jobs and adding steps increases build time. Option B is incorrect because removing unit tests compromises quality and is not a valid strategy. Option E is incorrect because increasing agents without parallelizing jobs or running all jobs on the same agent does not reduce build time.

Answer

Reduce the number of parallel jobs and increase the number of steps in a single job.

Answer

Remove unit tests from the build pipeline and run them only in the release pipeline.

Answer

Increase the number of agents in the pool and run all jobs on the same agent.

Question 3

Your organization uses a monorepo in Azure Repos containing multiple microservices. You need to design a build pipeline that only builds and tests the services that have changed in a given commit, to optimize build times. The pipeline must trigger on any push to any branch, but only the affected services should be built. You also need to ensure that dependent services are rebuilt if their dependencies change. The services are located in subdirectories: /services/serviceA, /services/serviceB, etc. Each service has a Dockerfile and a unit test project. You plan to use a script to determine which services changed. Which approach should you use to implement this pipeline?

Accepted Answer

Use a script step to determine which services changed, then output variables to dynamically create a job matrix or use the 'each' keyword to iterate over changed services.. Use a script to determine which services changed, then output variables to dynamically create a job matrix. This satisfies the requirement to only build affected services and handle dependency rebuilding if the script includes dependency detection. Option B is wrong because it requires a stage for every service upfront and is less dynamic. Option C is wrong because it does not optimize build times. Option D is wrong because it creates all jobs and uses complex conditions to skip unchanged services.

Answer

Create a multi-stage pipeline where each stage represents a service, and use a 'dependsOn' condition to run stages only if the corresponding service changed.

Answer

Create a single job that runs all unit tests for all services on every commit. Use caching to speed up the build.

Answer

Create a job for each service that runs in parallel on every commit. Use conditions to skip jobs if the service has not changed, but the conditions would need to check every service, which is complex.

Question 4

Your team uses Azure Pipelines with GitHub for source control. You need to ensure that whenever a pull request is created against the main branch, a validation build runs automatically. Which YAML trigger should you configure in the pipeline?

Accepted Answer

pr: branches: include: - main. The correct syntax for a pull request trigger in Azure Pipelines YAML. The `pr` trigger requires a `branches` node with `include` or `exclude`, and the verbose form `pr: branches: include: - main` is fully valid. Option B, `pr: main`, is not valid YAML syntax for Azure Pipelines; the shorthand `pr: main` is not recognized and will cause the pipeline to ignore the trigger. Options C and D use the `trigger` keyword, which is for CI builds on push, not for PR validation.

Answer

pr: main

Answer

trigger: branches: exclude: - main

Answer

trigger: main

Question 5

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). You need to implement a strategy that minimizes downtime during updates by gradually shifting traffic to the new version while monitoring for errors. Which deployment strategy should you use?

Accepted Answer

Canary deployment. Canary deployment is the correct choice because it gradually shifts a small percentage of traffic to the new version while monitoring for errors, allowing you to detect issues early and roll back quickly without impacting all users. In AKS, this can be implemented using a service mesh like Istio or a progressive delivery tool like Flagger, which manages traffic splitting via VirtualService and DestinationRule configurations. This minimizes downtime by ensuring the majority of users remain on the stable version until the new version is verified.

Answer

Recreate deployment

Answer

Blue-green deployment

Answer

Rolling update

Question 6

Your build pipeline uses a self-hosted agent that runs on a Windows machine. The pipeline fails with the error: 'The task 'DotNetCoreCLI' is not supported on this agent.' What is the most likely cause?

Accepted Answer

The agent does not have the required capabilities (e.g., .NET Core SDK installed).. The error 'The task 'DotNetCoreCLI' is not supported on this agent' indicates that the agent lacks the required capabilities to execute the task. In Azure Pipelines, self-hosted agents must have the necessary software (e.g., .NET Core SDK) installed and declared as capabilities for the task to be considered supported. Option B correctly identifies this missing capability as the root cause.

Answer

The agent's execution policy is restricted.

Answer

The agent is not authorized to run the pipeline.

Answer

The agent cannot connect to the internet to download the task.

Question 7

You maintain a classic release pipeline that deploys to multiple environments. You need to ensure that a deployment to the Production environment only proceeds after a manual approval from a specific group of users. Which feature should you configure?

Accepted Answer

Pre-deployment approvals on the Production environment. Pre-deployment approvals are configured on an environment to require manual sign-off before a release is deployed to that environment. In a classic release pipeline, this ensures that the deployment to Production only proceeds after a specific group of users has approved it, meeting the requirement for manual approval before deployment.

Answer

Post-deployment approvals on the Production environment

Answer

Deployment queue settings on the Production environment

Answer

Deployment gates on the Production environment

Question 8

Refer to the exhibit. You have a YAML pipeline with the above steps. The pipeline publishes a web app and deploys to Azure App Service. The deployment fails with error: 'Could not find the package in the specified path.' What is the most likely cause?

Accepted Answer

The package path is wrong; the zip file is in $(Build.ArtifactStagingDirectory).. The error 'Could not find the package in the specified path' indicates that the AzureWebApp task is looking for a deployment package (typically a .zip file) at a path that does not exist. In the exhibit, the `dotnet publish` command outputs to `$(Build.ArtifactStagingDirectory)`, but the subsequent AzureWebApp task likely references a different path (e.g., `$(System.DefaultWorkingDirectory)` or a hardcoded path). The correct path should be `$(Build.ArtifactStagingDirectory)/**/*.zip` to match the published artifact. Option A correctly identifies this path mismatch as the root cause.

Answer

The AzureWebApp task input 'appType' is incorrect.

Answer

The dotnet publish command did not generate a zip file.

Answer

The service connection 'MyServiceConnection' is not authorized.

Question 9

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets are securely passed to workflows without being exposed in logs. What should you use?

Accepted Answer

GitHub Secrets. GitHub Secrets (Option A) is the correct choice because GitHub Actions provides a built-in secrets management system that encrypts sensitive values at rest and masks them in all workflow logs. When you reference a secret using ${{ secrets.MY_SECRET }}, GitHub automatically redacts the value from any log output, ensuring it is never exposed during execution.

Answer

Environment variables in the workflow YAML

Answer

Hardcode the secrets in the workflow file

Answer

Azure Key Vault with Azure DevOps encrypted variables

Question 10

You have a multi-stage YAML pipeline that builds and deploys a Java application. The pipeline runs on a Microsoft-hosted agent. The build stage fails intermittently with 'OutOfMemoryError: Java heap space'. What should you do to resolve this issue?

Accepted Answer

Set the environment variable 'MAVEN_OPTS' to '-Xmx2048m'.. The 'OutOfMemoryError: Java heap space' in a Maven build indicates that the JVM running Maven needs more heap memory. Setting the environment variable 'MAVEN_OPTS' to '-Xmx2048m' increases the maximum heap size for the Maven JVM process to 2048 MB, which resolves the memory issue. This is the standard and correct approach for Maven-based builds.

Answer

Use a self-hosted agent with more memory.

Answer

Set the environment variable 'GRADLE_OPTS' to '-Xmx2048m'.

Answer

Use the 'Maven@3' task with the 'jdkVersion' option set to 'jdk11'.

Question 11

You are designing a release strategy for a critical application that must maintain high availability. You decide to use Azure Traffic Manager to route traffic between deployments in two Azure regions. Your release pipeline deploys the application to the secondary region first, then switches Traffic Manager priority to route traffic to the secondary region while the primary region is updated. This strategy is known as:

Accepted Answer

Blue-green deployment. This strategy is a blue-green deployment because it uses two complete environments (primary and secondary regions). The new version is deployed to the secondary (green) environment first, then Traffic Manager priority routing switches all traffic from the primary (blue) to the secondary (green). The primary is then updated while idle. This is the classic blue-green pattern applied across regions, not a rolling deployment.

Answer

Canary deployment

Answer

Red/Black deployment

Answer

Rolling deployment across regions

Question 12

Your team uses Azure Pipelines for CI/CD. You want to enforce that every build produces a versioned artifact that includes the Git commit ID. Which predefined variable should you use to get the commit ID in a YAML pipeline?

Accepted Answer

Build.SourceVersion. The `Build.SourceVersion` predefined variable in Azure Pipelines resolves to the commit ID (full SHA) of the commit that triggered the pipeline. This makes it the correct choice for embedding the Git commit ID into a versioned artifact. Other variables like `Build.BuildId` or `Build.SourceBranch` do not provide the commit hash.

Answer

Build.Repository.Name

Answer

Build.BuildId

Answer

Build.SourceBranch

Question 13

Refer to the exhibit. You are creating an ARM template to deploy an App Service and its Application Insights configuration. The template fails to deploy with error: 'The resource 'Microsoft.Insights/components/...' is not defined in the template.' What is the most likely cause?

Accepted Answer

The Application Insights component is not defined as a resource in the template.. The error 'The resource 'Microsoft.Insights/components/...' is not defined in the template' indicates that the ARM template references an Application Insights component (e.g., via the `reference()` function or a `dependsOn` property) that is not declared as a resource within the template's `resources` array. In ARM templates, every resource you reference must be explicitly defined; otherwise, the deployment engine cannot resolve it, causing this validation error.

Answer

The reference function cannot be used in a properties object.

Answer

The reference function syntax is incorrect.

Answer

The apiVersion for the config resource is outdated.

Question 14

Your team is adopting Azure Pipelines for a new project. You need to ensure that only authorized users can approve releases to production. Which two methods can you use to implement approval checks?

Accepted Answer

Configure pre-deployment approvals on the Production environment.. Pre-deployment approvals on the Production environment (Option A) allow you to require one or more users or groups to approve a release before it is deployed to that environment. Similarly, setting the 'Required approvers' field on the environment (Option C) specifies the users or groups that must approve the deployment, which is another native Azure Pipelines approval mechanism. Both enforce authorization at the environment level, ensuring only designated approvers can promote a release to production.

Answer

Use Deployment Gates with a manual approval gate.

Answer

Add a Manual Intervention task in the release pipeline.

Answer

Add an Approval Check to the agent pool.

Question 15

You are designing a YAML pipeline that builds a .NET application and publishes it as a NuGet package to Azure Artifacts. Which three tasks should you include in the build stage?

Accepted Answer

DotNetCoreCLI@2 with command 'build'. The DotNetCoreCLI@2 task with the 'build' command compiles the .NET application source code into intermediate language (IL) assemblies. This is a mandatory step after restoring dependencies and before packing the project into a NuGet package. Without a successful build, the subsequent pack and push operations would fail.

Answer

NuGetCommand@2 with command 'install'

Answer

DotNetCoreCLI@2 with command 'push'