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

Question 1

Your company uses Azure DevOps for CI/CD. You have a YAML build pipeline that builds a .NET Core application and publishes artifacts. The build runs on a Microsoft-hosted agent. Recently, the build started failing with the error 'The process cannot access the file because it is being used by another process.' This occurs intermittently during the 'dotnet build' step. The pipeline uses multiple jobs that run in parallel. You suspect that one job is interfering with another because they share the same workspace on the agent. You need to ensure that each job runs in its own isolated workspace. What should you do?

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

Accepted Answer

Set 'clean: all' on the checkout step in each job.. Setting 'clean: all' on the checkout step ensures that the workspace is cleaned before each job runs, preventing file conflicts caused by shared workspace on the agent. Option A is wrong because 'demands' are for selecting agents with specific capabilities, not for workspace isolation. Option B is wrong because 'workspace: clean' is not a valid setting at the pipeline root; workspace cleaning is configured per checkout step. Option C is wrong because a multi-job configuration with a matrix is used for parallelizing builds across different configurations, not for isolating workspaces.

Answer

Add a 'demands' section to the job to ensure each job runs on a different agent.

Answer

Set 'workspace: clean' in the pipeline root.

Answer

Use a 'multi-job' configuration with a matrix to run each job in separate folders.

Question 2

Your organization uses Azure DevOps. You have a classic release pipeline that deploys to multiple stages: Dev, QA, and Prod. Each stage has a pre-deployment approval gate. Recently, the QA team complained that they are not receiving approval notifications. You have verified that the approval configuration is correct and the approvers are members of the 'QA Approvers' group. The release pipeline is set to send email notifications to the approvers. However, the QA approvers report they do not receive any emails when a release is pending their approval. What should you check first?

Accepted Answer

Verify that the organization-level notification settings allow email notifications for approvals.. In Azure DevOps, email notifications for approvals are governed by organization-level (and sometimes project-level) notification settings, not just the pipeline's own configuration. If the organization has disabled or restricted the 'Approval pending' notification, approvers will not receive emails even though the pipeline is configured to send them. Verifying organization notification settings is therefore the correct first check.

Answer

Ask the QA team to check their spam folder.

Answer

Add a 'Send email' task in the pipeline before the approval gate.

Answer

Check the 'Release Pipeline' logs for a warning about email delivery failure.

Question 3

Your team uses GitHub Actions to deploy a microservices application to a Kubernetes cluster. The workflow builds Docker images and pushes them to a container registry, then updates the Kubernetes deployment. The deployment often fails due to image pull errors, specifically 'ErrImagePull' and 'ImagePullBackOff'. You investigate and find that the image tag in the Kubernetes manifest is the commit SHA. The workflow uses the 'azure/k8s-deploy@v1' action. You suspect that the image is not being pulled because the registry credentials are not properly configured. You have stored the registry credentials as secrets. What is the most likely cause and solution?

Accepted Answer

The action does not automatically create imagePullSecrets; you need to add a step to create the secret in the cluster and reference it in the deployment.. The 'azure/k8s-deploy@v1' action deploys to Kubernetes but does not automatically create imagePullSecrets for private container registries. Even if the registry credentials are stored as secrets in GitHub, they are not automatically applied to the cluster. You must explicitly create a Kubernetes secret of type docker-registry and add an imagePullSecrets entry to the deployment manifest. Option A is wrong because using 'latest' tag is not a best practice and does not address authentication. Option B is wrong because the image name is likely correct; the issue is pulling due to lack of credentials. Option C is wrong because the action does support private registries when credentials are properly configured.

Answer

The commit SHA tag is not valid; use 'latest' tag instead.

Answer

The image name is incorrect; verify the registry URL.

Answer

The 'azure/k8s-deploy' action does not support private registries; use a different action.

Question 4

You manage a release pipeline for a Java application that is deployed to Azure App Service. The pipeline currently uses manual approval gates. You need to implement automated quality gates to reduce manual intervention. Which THREE conditions can you use in the 'Post-deployment approvals' settings of a release pipeline? (Choose three.)

Accepted Answer

Invoke Azure Functions. 'Invoke Azure Functions' is a valid gate type in Azure DevOps release pipelines. It allows you to call an Azure Function as a quality gate, enabling custom automated checks (e.g., validating deployment health or running custom logic) without manual intervention. This directly supports the goal of reducing manual approvals by automating post-deployment validation.

Answer

Azure Policy

Answer

Manual approval

Question 5

Your organization uses GitHub Actions for CI/CD. You need to enforce branch protection rules and ensure that all pull requests to the main branch require a successful status check from a specific workflow. Which TWO actions should you take? (Choose two.)

Accepted Answer

Add a workflow to the repository that runs tests and reports a conclusion status.. A workflow that runs tests and reports a conclusion status provides the status check that branch protection rules can require. Option E is correct because enabling 'Require status checks to pass before merging' under branch protection rules in the repository settings enforces that the specific workflow's status check must succeed before a pull request can be merged into the main branch.

Answer

Configure a GitHub environment with required reviewers.

Answer

Use a repository ruleset to require status checks.

Answer

Set up branch policies in Azure Repos for the main branch.

Question 6

Your company develops a microservices-based application deployed on Azure Kubernetes Service (AKS). The CI/CD pipeline uses Azure Pipelines. The development team has recently adopted a trunk-based development strategy where all feature work is done on short-lived branches that merge to main at least daily. The release pipeline must automatically deploy to a development environment on each commit to main, and to a staging environment after a manual approval. The staging environment is used for integration tests and must remain stable. You need to design the release pipeline strategy to support this workflow. What should you do?

Accepted Answer

Create a single release pipeline with two stages: 'Dev' triggered automatically on successful build, and 'Staging' with a pre-deployment approval gate.. It creates a single release pipeline with two stages: 'Dev' triggered automatically on successful build, and 'Staging' with a pre-deployment approval gate. This meets the requirements: automatic deployment to dev on each commit to main, and manual approval before deploying to staging, keeping staging stable. Option A is wrong because deploying to both environments simultaneously bypasses the manual approval needed for staging. Option C is wrong because separate pipelines add maintenance overhead and don't leverage pipeline stages for approval gates. Option D is wrong because a post-deployment approval gate would deploy to staging first, then require approval, which doesn't prevent deployment without approval. Also disabling continuous deployment trigger for staging would require manual promotion, which is not desired.

Answer

Create a single release pipeline with one stage that deploys to both dev and staging simultaneously, and add a manual intervention task before staging deployment.

Answer

Create two separate release pipelines: one for dev with continuous deployment trigger, and one for staging with a manual trigger.

Answer

Create a single release pipeline with two stages: 'Dev' triggered automatically, and 'Staging' with a post-deployment approval gate and disable continuous deployment trigger.

Question 7

Your team uses Azure DevOps to manage a monolithic .NET Framework application that is deployed to on-premises Windows servers. You plan to modernize the application by containerizing it and moving it to Azure Kubernetes Service (AKS). The existing build pipeline uses the .NET Framework build task and MSBuild. The release pipeline uses WinRM-based deployment to copy files to on-premises servers. You need to design a new CI/CD pipeline that builds a Docker image, pushes it to Azure Container Registry (ACR), and deploys it to AKS. Your solution should minimize changes to the existing codebase and leverage Azure Pipelines. What should you do?

Accepted Answer

Modify the existing build pipeline by adding a 'Docker' task to build and push the image, and modify the release pipeline to use a 'Kubernetes' task for deployment.. The correct approach is to extend the existing Azure Pipelines definitions rather than rebuild them: add a Docker task to the build pipeline to build and push the image to ACR, and swap the WinRM release step for a Kubernetes task that deploys to AKS. This preserves the existing .NET Framework build logic (MSBuild task) so the codebase and build steps remain largely untouched, satisfying the 'minimize changes' requirement. Azure Pipelines natively supports both the Docker task and the Kubernetes task, so no custom scripting or new pipelines are needed.

Answer

Keep the existing build pipeline as is, and add a script to build the Docker image in the release pipeline before deploying.

Answer

Create a new build pipeline from scratch using the 'Docker' template and a new release pipeline with the 'Deploy to Kubernetes' template.

Answer

Use self-hosted agents to build the Docker image and deploy to AKS.

Question 8

Your organization uses GitHub Flow for source control with a monorepo containing multiple microservices. Each microservice has its own build and test workflow. You need to design a CI/CD strategy that builds and tests only the services affected by a pull request to reduce build times and resource usage. You also need to ensure that all pull requests to the main branch pass required checks before merging. What should you implement?

Accepted Answer

Use separate workflows for each microservice with path filters (on: pull_request paths:) so that only workflows with changed files are triggered.. Path filters on the `on: pull_request` trigger allow each microservice workflow to run only when files under its directory change, which is the standard GitHub Actions pattern for monorepo selective CI. This directly reduces build time and resource consumption while still satisfying required status checks configured on the main branch. Separate workflows also give per-service check granularity, so branch protection rules can require only the relevant checks.

Answer

Use a single workflow that builds and tests all microservices on every push to any branch.

Answer

Set up a webhook that triggers builds manually per service based on pull request comments.

Answer

Create a single workflow that uses a matrix strategy to build and test each microservice, and run it on every pull request.

Question 9

Your team is using Azure Pipelines to deploy a web application to Azure App Service. The application uses a configuration file (appsettings.json) that contains environment-specific settings. You need to manage these settings across development, staging, and production environments without exposing secrets in the source code. The pipeline should automatically replace the settings during deployment. What should you configure?

Accepted Answer

Use the 'File Transform' task in the release pipeline to replace tokens in the configuration file with variables defined in pipeline variable groups.. The File Transform task in Azure Pipelines can perform token replacement in configuration files like appsettings.json using variables defined in pipeline variable groups. This allows environment-specific settings to be injected during deployment without hardcoding secrets in source control. Variable groups can be linked to Azure Key Vault for secure secret management.

Answer

Create separate build configurations for each environment and use the 'Transform Web.config' task.

Answer

Use the 'Azure App Service Deploy' task with the 'Use Web Deploy' option and configure parameterization.

Answer

Set environment variables in the Azure App Service and read them in the application code.

Question 10

Your organization uses GitHub Actions for CI/CD. You have a workflow that deploys to Azure App Service. The deployment uses a publish profile secret stored as a GitHub secret. You want to improve security by using OpenID Connect (OIDC) to authenticate to Azure without storing secrets. What should you do?

Accepted Answer

Configure the GitHub workflow to use the 'azure/login' action with OIDC, and set up a federated identity credential in Microsoft Entra ID for the GitHub environment.. Using the 'azure/login' action with OIDC and configuring a federated identity credential in Microsoft Entra ID allows GitHub Actions to authenticate to Azure without storing any secrets. The federated credential establishes a trust relationship between GitHub's OIDC provider and an Microsoft Entra ID app registration, so the workflow can obtain a short-lived token. This eliminates the need for a publish profile secret, improving security by removing long-lived credentials.

Answer

Remove the secret and use Azure AD Managed Identity directly from the GitHub runner.

Answer

Replace the publish profile secret with an Azure service principal secret stored as a GitHub secret.

Answer

Use the 'Azure App Service Deploy' task with the 'Publish Profile' parameter set to an empty string.

Question 11

Your organization uses Azure Pipelines and wants to implement a continuous feedback loop by collecting user analytics from the production environment and automatically creating work items in Azure Boards for critical issues. You need to design a solution that integrates monitoring data with the pipeline. What should you do?

Accepted Answer

Set up Azure Monitor alerts based on Application Insights data, and configure the alerts to invoke a webhook that calls the Azure Boards REST API to create a work item.. Azure Monitor alerts based on Application Insights data can trigger a webhook that calls the Azure Boards REST API to automatically create a work item. This integrates monitoring data with the pipeline to establish a continuous feedback loop. Option A is incorrect because Power BI visualization and email alerts do not automate work item creation. Option C is incorrect because release pipeline logs are not for collecting user analytics; Application Insights is needed. Option D is incorrect because manually reviewing dashboards is not automated.

Answer

Use Power BI to visualize Application Insights data and set up data-driven alerts that send emails to the team.

Answer

Configure the release pipeline to output logs to Azure Monitor and use Log Analytics to create work items.

Answer

Use Azure Application Insights to collect user analytics, and manually review dashboards to create work items.

Question 12

You are designing a build pipeline for a .NET Core application. The pipeline must run on a self-hosted agent in a private network without internet access. Which TWO actions are required to ensure the build can download NuGet packages?

Accepted Answer

Install the NuGet tool on the self-hosted agent machine.. Option B is correct because a self-hosted agent in an isolated network must have the NuGet client tooling installed locally, since the pipeline's NuGet restore tasks (e.g., NuGetCommand@2 or DotNetCoreCLI restore) rely on a NuGet executable or the .NET SDK's built-in restore capability being present on the agent machine to resolve and download packages. Option D is correct because with no internet access, the agent cannot reach nuget.org, so the pipeline must point NuGet at a reachable package source such as Azure Artifacts or an internal NuGet feed configured via NuGet.config or a service connection, allowing packages to be downloaded from inside the private network. Option A is wrong because disabling NuGet restore would prevent package download entirely, defeating the build's dependency resolution. Option C is wrong because switching to a Microsoft-hosted agent contradicts the requirement to run on a self-hosted agent in a private network and would not have access to internal feeds. Option E is wrong because NuGet Authenticate only supplies credentials for Azure Artifacts; authentication alone does not provide network reachability or a configured internal feed, so it is not sufficient (and not required) to enable package download in an offline network.

Answer

Disable the NuGet restore step in the pipeline.

Answer

Use a Microsoft-hosted agent instead.

Answer

Use the NuGet Authenticate task to authenticate with Azure Artifacts.

Question 13

Your team uses GitHub Actions to build a multi-container application. The build must produce container images that are scanned for vulnerabilities and signed. Which THREE actions are required in the workflow?

Accepted Answer

Add a step to run a container scan tool like Trivy.. Option B is correct because the requirement explicitly states the images must be scanned for vulnerabilities, and adding a step that runs a scanning tool such as Trivy (e.g., aquasecurity/trivy-action) performs that vulnerability scan against the built image. Option C is correct because the requirement also states the images must be signed, and cosign (sigstore/cosign) is the standard tool for signing container images, producing a signature that can be verified against the image digest. Option E is correct because a multi-container application must actually be built and pushed to a registry before it can be scanned or signed, and docker/build-push-action is the canonical GitHub Actions step that builds and pushes the images. Option A is not required because authenticating to Docker Hub is only necessary if pushing to Docker Hub specifically; the scenario does not mandate that registry, and authentication could be handled differently or target another registry. Option D is not required for the stated goals because checking out the code is a general prerequisite for many workflows but is not one of the three actions specifically needed to scan and sign the produced images.

Answer

Use the docker/login-action to authenticate with Docker Hub.

Answer

Use the actions/checkout action to checkout the code.

Question 14

You are configuring a YAML pipeline in Azure Pipelines. The pipeline must trigger only when changes are pushed to the main branch. Which setting should you configure?

Accepted Answer

Set the trigger to include the main branch.. In Azure Pipelines YAML, the `trigger` section controls which branches cause a CI pipeline to run. By setting `trigger.branches.include` to `main`, only pushes to `main` will trigger the pipeline. All other branches are automatically excluded. There is no separate setting required to disable triggers for other branches; the include list is authoritative.

Answer

Set the PR trigger to include main.

Answer

Set the pipeline to run on every push regardless of branch.

Answer

Use a schedule trigger with cron expression.

Answer

Set the trigger to none for other branches.

Question 15

You are designing a multi-stage YAML pipeline for an application that requires approval for production deployment. The pipeline must run automatically for non-production stages. Which TWO configurations should you use?

Accepted Answer

Set the pipeline trigger to include branches used for non-production stages.. Options A and B are correct. Option A: Setting the pipeline trigger to include branches used for non-production stages enables automatic CI triggers for those branches, so non-production stages run automatically. Option B: Adding an 'approvals' block to the production stage enforces manual approval before deployment to production. Options C, D, and E are incorrect: C suggests using a release pipeline which is unnecessary; D would require manual approval for every stage, not just production; E describes a single-stage pipeline, which doesn't fit the multi-stage requirement.

Answer

Use a release pipeline instead of a YAML pipeline.

Answer

Set the pipeline to require manual approval for every stage.

Answer

Use a single-stage pipeline with conditional approval.