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

Question 1

Your team uses GitHub Actions to build and deploy a Node.js application to Azure Functions. You need to implement a CI/CD pipeline that automatically deploys to a staging environment on every push to the main branch, and then promotes to production after a manual approval via GitHub Environments. The pipeline must also run unit tests and linting. You want to use the official Azure actions. What should you do?

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

Accepted Answer

Create a single GitHub Actions workflow with multiple jobs. Use a job for build and test, then a job for deploy to staging, and a job for deploy to production with an environment that requires approval.. Correct answer is C. A single GitHub Actions workflow can have multiple jobs: build and test, deploy to staging, and deploy to production. The production deployment job should use a GitHub Environment configured with required reviewers, enabling manual approval. Option A is incorrect because two separate workflows make it harder to share build artifacts and do not inherently use environment-based approvals for staging vs production. Option B is incorrect because GitHub Issues are not used for manual approvals; approvals are configured via GitHub Environments. Option D is incorrect because it uses Azure Pipelines, not GitHub Actions, which violates the requirement to use official Azure actions in GitHub Actions.

Answer

Create two separate workflows: one for CI (build, test, deploy staging) and one for CD (deploy production) that triggers manually.

Answer

Use a single workflow with a step that deploys to staging and then to production, using a condition to require manual approval via GitHub Issues.

Answer

Use Azure Pipelines with a multi-stage YAML pipeline that includes a stage for staging and a stage for production with pre-deployment approvals.

Question 2

Your organization uses Azure Repos for source control and Azure Pipelines for CI/CD. You need to implement a policy that ensures every commit to the main branch is built and passes all tests before it can be merged. The team uses feature branches for development. What is the most efficient way to enforce this?

Accepted Answer

Configure a branch policy on the main branch that requires a successful build from a pull request trigger.. Configuring a branch policy on the main branch that requires a successful build from a pull request trigger ensures that every commit to main must be built and pass tests before merging. This is the most efficient automated enforcement. Option A is incorrect because relying on manual builds does not enforce the policy automatically. Option B is incorrect because a pre-merge validation that does not block merging fails to prevent unvalidated commits. Option D is incorrect because a CI trigger on main runs after merge, not before, so it does not enforce pre-merge validation.

Answer

Require developers to manually run the pipeline before merging.

Answer

Use a pre-merge validation pipeline that runs on pull requests but does not block merging.

Answer

Set up a CI trigger on the main branch to run the pipeline on every commit.

Question 3

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). Each microservice has its own build pipeline that produces a container image. You need a single release pipeline that can deploy multiple microservices in a coordinated manner, but you want to avoid rebuilding the deployment pipeline for each microservice. The deployment should use Helm charts. What should you do?

Accepted Answer

Create a single release pipeline that consumes multiple build artifacts (one per microservice) and uses a Helm chart per microservice, deploying them in stages.. A single release pipeline can consume multiple build artifacts (one per microservice) and use Helm charts to deploy each microservice in stages. This allows coordinated deployment without duplicating the pipeline logic. Option A is incorrect because creating separate release pipelines for each microservice and triggering them sequentially lacks a single orchestration point and can lead to coordination failures. Option B is incorrect because creating a single build pipeline that produces all container images couples the builds and prevents independent microservice development. Option D is incorrect because a single multi-stage YAML pipeline that builds and deploys all microservices together also couples the build and deploy stages, and does not allow each microservice to have its own independent build pipeline.

Answer

Create a separate release pipeline for each microservice and trigger them in sequence using pipeline completion triggers.

Answer

Create a single build pipeline that produces all container images, then a release pipeline that deploys the single artifact.

Answer

Create a single multi-stage YAML pipeline that builds and deploys all microservices together.

Question 4

Your team is adopting Infrastructure as Code (IaC) using Bicep. You have a multi-stage YAML pipeline that deploys Azure resources to dev, test, and prod environments. You need to ensure that the Bicep files are validated and deployed consistently, and that any changes to the infrastructure are approved for production. You also want to use the latest version of the Azure CLI task. What is the recommended approach?

Accepted Answer

Use the AzureCLI task with inline script to run 'az deployment group validate' and 'az deployment group create'. Add environments with approval gates for production.. It uses the AzureCLI task with the 'az deployment group validate' and 'az deployment group create' commands, which natively support Bicep files. This approach integrates with multi-stage YAML pipelines and allows adding approval gates for production environments. Option A is incorrect because the Azure Resource Manager Template Deployment task requires a compiled ARM JSON file, adding an unnecessary compilation step and not leveraging Bicep's native capabilities. Option B is incorrect because creating separate pipelines for each environment duplicates effort and does not take advantage of the multi-stage YAML pipeline structure with environment approvals. Option D is incorrect because using a PowerShell task with 'New-AzResourceGroupDeployment' cmdlet lacks native Bicep support and may require manual compilation.

Answer

Use the Azure Resource Manager Template Deployment task with the 'templateLocation' parameter pointing to the compiled ARM JSON.

Answer

Create three separate pipelines for each environment, each using the ARM Template Deployment task.

Answer

Use a PowerShell task with the 'New-AzResourceGroupDeployment' cmdlet.

Question 5

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a pipeline that automatically builds and tests a Python application on every pull request to the main branch, but only if the pull request is from a fork. The pipeline must also publish test results as a build artifact. What should you do?

Accepted Answer

Configure a branch protection rule on main that requires status checks from Azure Pipelines. Set the pipeline trigger to 'Pull request validation' and include a condition to run only if the pull request is from a fork.. It configures a branch protection rule on the main branch that requires status checks from Azure Pipelines. By setting the pipeline trigger to 'Pull request validation' and including a condition to run only if the pull request is from a fork, the pipeline automatically builds and tests the Python application on every pull request from a fork to main. The pipeline can also publish test results as a build artifact. Option A is incorrect because GitHub Actions is not Azure Pipelines; the requirement specifies using Azure Pipelines for CI/CD. Option B is incorrect because a scheduled trigger polling for PRs is inefficient and not the proper way to handle PR events. Option C is incorrect because a pipeline completion trigger runs after a merge, not on pull requests.

Answer

Use GitHub Actions to build and test the application on PRs, and then trigger Azure Pipelines for deployment.

Answer

Use a scheduled trigger to run the pipeline every hour and check for new PRs from forks.

Answer

Set up a pipeline completion trigger on the main branch that runs the pipeline after every merge.

Question 6

You are designing a release pipeline for a critical business application that must adhere to strict compliance requirements. The pipeline must deploy to multiple environments (dev, test, staging, prod) with manual approvals required for staging and prod. Additionally, the pipeline must automatically run integration tests after deployment to dev and test, and only proceed to the next environment if tests pass. You need to implement this using Azure Pipelines YAML. What should you do?

Accepted Answer

Use a single multi-stage YAML pipeline with a stage per environment. Add a job after deployment to dev that runs integration tests, and use a condition on the next stage to run only if tests passed. Add approvals on staging and prod stages.. It uses a single multi-stage YAML pipeline with a stage per environment, adds a job after deployment to dev that runs integration tests, uses a condition on the next stage to run only if tests passed, and adds approvals on staging and prod stages. This satisfies all requirements: sequential deployment, conditional test execution, and manual approvals. Option A is incorrect because it lacks the conditional test execution; after deployment to dev, the pipeline would proceed to test regardless of test results. Option B is incorrect because separate pipelines with completion triggers cannot enforce the required conditions (run tests and only proceed if passed) and cannot easily add approvals per environment. Option C is incorrect because it describes a classic release pipeline, which does not support YAML-based definitions and cannot easily integrate conditional test execution with stage dependencies.

Answer

Use a single multi-stage YAML pipeline with a stage per environment. Add approvals on staging and prod stages. Ensure stages run sequentially by default.

Answer

Create separate YAML pipelines for each environment and use pipeline completion triggers to chain them together.

Answer

Use a classic release pipeline with environments and pre-deployment approvals on staging and prod. Add a post-deployment task to run integration tests in dev and test environments.

Question 7

Refer to the exhibit. A developer queues a build manually but notices the build status remains 'notStarted' for an extended period. The pipeline has no demands and priority is normal. Which is the most likely cause?

Accepted Answer

All agents in the pool are currently busy.. When a build remains in 'notStarted' status for an extended period, it typically means the pipeline is waiting for an available agent. Since the pipeline has no demands and priority is normal, the most likely cause is that all agents in the specified agent pool are currently busy executing other jobs, so the build is queued until an agent becomes free.

Answer

The variable 'BuildConfiguration' is misspelled.

Answer

The branch 'main' does not exist.

Answer

The pipeline definition ID is incorrect.

Question 8

Refer to the exhibit. A developer creates a pipeline with this YAML. When a commit is pushed to the 'main' branch of the repository 'MyProject/MyRepo', the pipeline does NOT trigger. Which is the most likely cause?

Accepted Answer

The 'internal' repository trigger requires a pipeline trigger to be enabled in the UI.. When using the 'internal' repository type in Azure Pipelines YAML, the pipeline must have a 'Pipeline trigger' explicitly enabled in the UI settings. The YAML 'trigger' branch specification alone is insufficient for 'internal' repositories; the UI trigger acts as a required gate. Without this UI setting, commits to 'main' will not initiate the pipeline.

Answer

The 'checkout: internal' step should use a different syntax.

Answer

The 'ref' property should be set to a commit SHA, not a branch name.

Answer

The branch specification 'main' is case-sensitive and should be 'Main'.

Question 9

Refer to the exhibit. A build pipeline produces the above logs. Which change would resolve the build failure?

Accepted Answer

Add a definition for 'MyMethod' in the 'MyClass' class.. The build failure is caused by a missing method definition. The logs indicate that the test step is attempting to invoke 'MyMethod' on an instance of 'MyClass', but the compiler cannot find it. Adding the missing method to the class resolves the compilation error, which is the root cause of the pipeline failure.

Answer

Change the build configuration from Release to Debug.

Answer

Remove the '--no-build' flag from the test step.

Answer

Add the '--no-restore' flag to the build step.

Question 10

Refer to the exhibit. A release is created with the above command. The Dev environment starts deploying, but the Prod environment does not. Which is the most likely reason?

Accepted Answer

The Prod environment has a pre-deployment condition that waits for the Dev environment to succeed.. The exhibit shows a release pipeline with a sequential deployment strategy where the Prod environment has a pre-deployment condition configured to wait for the Dev environment to succeed. In Azure DevOps, pre-deployment conditions can be set to trigger only after a specific environment (like Dev) completes successfully. Since the Dev environment is still deploying, the Prod environment remains in a waiting state and does not start.

Answer

The Prod environment requires manual approval before deployment.

Answer

The release definition ID 5 is incorrect.

Answer

The build artifact with ID 123 is not accessible.

Question 11

Refer to the exhibit. A build pipeline uses this trigger configuration. A developer pushes a commit to the 'main' branch that modifies files in '/src/app/' and '/src/tests/'. How many builds will be triggered?

Accepted Answer

1 build, because batchChanges is true.. The trigger configuration has `batchChanges` set to `true`. When `batchChanges` is enabled, Azure Pipelines groups all commits that arrive while a build is in progress into a single build, rather than triggering a separate build for each commit. In this scenario, the developer pushes a single commit that modifies files in both `/src/app/` and `/src/tests/`. Since `batchChanges` is true, only one build is triggered for that commit, regardless of the number of modified folders.

Answer

0 builds, because the excluded path takes precedence.

Answer

3 builds, because maxConcurrentBuildsPerBranch is 1 but batchChanges overrides.

Answer

2 builds, one for each modified folder.

Question 12

Refer to the exhibit. A developer queues a build with a variable 'BuildConfiguration' set to 'Release'. The pipeline definition has a default variable 'BuildConfiguration' set to 'Debug' and does not allow overrides at queue time. What will be the value of 'BuildConfiguration' during the build?

Accepted Answer

Debug. The pipeline definition does not allow overrides at queue time, so the variable value passed in the queue command is ignored; the default value 'Debug' is used.

Answer

Release

Answer

null

Answer

The build fails with an error

Question 13

Refer to the exhibit. A build pipeline fails with this error. What is the most likely cause?

Accepted Answer

The build agent does not have the 'ASP.NET and web development' workload installed.. The error indicates that the MSBuild targets file for Web Applications is missing. This typically occurs when the build agent does not have the required Visual Studio workload installed, specifically the Web development build tools.

Answer

The build agent is out of disk space.

Answer

The pipeline is using the wrong version of MSBuild.

Answer

The solution file is corrupted.

Question 14

Refer to the exhibit. A release pipeline deploys this ARM template. The deployment fails with error: 'The template parameters 'adminPassword' is not a valid input.' What is the most likely cause?

Accepted Answer

The parameter 'adminPassword' is not defined in the parameters section of the template.. The template references a parameter 'adminPassword' that is not defined in the parameters section. It must be declared as a parameter to be provided during deployment.

Answer

The VM size is not available in the specified location.

Answer

The resource group location is invalid.

Answer

The parameter 'adminPassword' is misspelled in the template.

Question 15

Refer to the exhibit. A developer commits code to the 'develop' branch. The pipeline does not trigger. What is the most likely reason?

Accepted Answer

The trigger is configured to only run on the 'main' branch.. The trigger is set to 'main' branch only. Commits to 'develop' will not trigger the pipeline.

Answer

The pipeline requires a manual trigger.

Answer

The pipeline has a CI trigger disabled.

Answer

The pool 'ubuntu-latest' is not available.