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

Question 1

Your team uses Azure Pipelines to build a Java application. The build must produce a JAR file and publish it as a pipeline artifact. Which THREE steps should be included in the build pipeline?

Accepted Answer

Use a Maven or Gradle task to compile and package the application.. A Maven or Gradle task is the standard way to compile and package a Java application into a JAR file. These tasks invoke the build tool's lifecycle (e.g., `mvn package` or `gradle build`) to produce the artifact, which is a prerequisite for publishing.

Answer

Use the DotNetCoreCLI task to build the application.

Answer

Use the NuGetCommand task to pack the JAR.

Question 2

You are implementing a release pipeline for a web application deployed to multiple Azure App Service instances across different regions (West US, East US, and North Europe). The deployment must follow a phased rollout: first West US, then East US, then North Europe, with a manual approval gate between each region. Each region should have its own slot for staging and production. You need to design the pipeline to minimize duplication of stages and tasks. What should you do?

Accepted Answer

Use a multi-stage YAML pipeline with environment per region and a manual approval on each environment.. A multi-stage YAML pipeline with one environment per region and a manual approval check on each environment provides the phased rollout with approval gates while keeping stage definitions DRY through templates or repeated environment references. Environments in Azure DevOps natively support approval checks, so no duplicated approval logic is needed. This satisfies the minimize-duplication requirement.

Answer

Create three separate stages (one per region) and duplicate the deployment tasks in each.

Answer

Use a single stage with parallel deployment to all regions and add manual approvals before each region's deployment.

Answer

Use a single stage with a deployment group job that targets agents tagged with region names, and use deployment group tags to control phased rollout.

Question 3

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?

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.. The correct approach is to create a single GitHub Actions workflow with multiple jobs: one for build and test, one for deploy to staging, and one for deploy to production that uses a GitHub Environment with required reviewers. This allows automatic deployment to staging on push to main, and manual approval for production. The official Azure actions (e.g., azure/functions-action) can be used. Option C is the only one that meets all requirements.

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 4

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.. Azure Repos branch policies on main can require a build validation that runs on pull requests and blocks completion until the build succeeds. This enforces that every PR is built and tested before merge, which is exactly the requirement. Manual runs, non-blocking pipelines, and post-merge CI triggers do not prevent merging of failing code.

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 5

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 deploy each with its own Helm chart, using stages to coordinate the rollout. This avoids rebuilding the pipeline for each microservice while still allowing coordinated deployment. Azure Pipelines supports multiple artifact sources in a single release definition, and Helm tasks can be parameterized per stage.

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 6

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 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. In Azure Pipelines, when a variable is defined in the pipeline YAML and the 'Settable at queue time' option is not enabled, the queue-time value is ignored and the pipeline definition's default value is used. Since the default is 'Debug' and overrides are not allowed, the build runs with BuildConfiguration=Debug (A). The developer's attempt to set 'Release' at queue time has no effect.

Answer

Release

Answer

null

Answer

The build fails with an error

Question 13

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 error 'The template parameters 'adminPassword' is not a valid input' occurs when the ARM template does not declare a parameter named 'adminPassword' in its parameters section. Even if the parameter is referenced elsewhere, it must be explicitly defined in the parameters block to be accepted. Therefore, the most likely cause is that the parameter is missing from the template's parameters definition.

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 14

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 pipeline did not trigger on a commit to the 'develop' branch. The most likely reason is that the YAML pipeline's trigger is configured to only include the 'main' branch, so commits to 'develop' are ignored. Azure Pipelines CI triggers default to all branches unless specified, but if the trigger explicitly includes only 'main', then 'develop' commits won't trigger. Other options are less likely: manual trigger would require explicit run, but the question implies automatic trigger expected; CI trigger disabled would prevent any automatic trigger, but the question specifies 'develop' branch, suggesting other branches might work; pool availability would cause failure after trigger, not prevent trigger.

Answer

The pipeline requires a manual trigger.

Answer

The pipeline has a CI trigger disabled.

Answer

The pool 'ubuntu-latest' is not available.

Question 15

Refer to the exhibit. A build pipeline fails at the 'Publish Artifact' step. The pipeline has two jobs: 'Build' and 'Test'. Both jobs have a 'PublishBuildArtifacts' task with artifact name 'drop'. What is the most likely cause?

Accepted Answer

Two jobs are publishing artifacts with the same name.. In Azure Pipelines, artifact names must be unique within a pipeline run. When two jobs (Build and Test) each run a PublishBuildArtifacts task with the same artifact name 'drop', the second publish conflicts with the first, causing the 'Publish Artifact' step to fail. The fix is to use distinct artifact names per job or use a single job to publish.

Answer

The artifact name 'drop' contains invalid characters.

Answer

The artifact is too large to publish.

Answer

The pipeline does not have permission to publish artifacts.