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

Question 1

You are implementing a release pipeline for a containerized application using Azure Kubernetes Service (AKS). The pipeline should use canary deployments to gradually shift traffic from the stable version to the new version. Which strategy should you use to manage the traffic shift?

Accepted Answer

Canary deployment using a service mesh (e.g., Istio). Option C is correct because a virtual node or service mesh like Istio can be used to implement canary deployments with traffic splitting. Option A is wrong because rolling update replaces pods gradually but does not support fine-grained traffic splitting. Option B is wrong because blue-green deployment uses two environments, not gradual traffic shift. Option D is wrong because A/B testing is typically feature-specific, not for traffic shifting at the deployment level.

Answer

Blue-green deployment strategy

Answer

Rolling update strategy

Answer

A/B testing with feature flags

Question 2

Your pipeline uses the DotNetCoreCLI task to build a .NET Core application. You need to ensure that the build produces a self-contained deployment (SCD) for a Linux target. Which argument should you pass to the 'arguments' input of the task?

Accepted Answer

--runtime linux-x64. Option D is correct because the --runtime flag specifies the target runtime for a self-contained deployment. Option A is wrong because --configuration specifies build configuration. Option B is wrong because --output specifies output path. Option C is wrong because --self-contained is a property in the project file, not a CLI argument.

Answer

--configuration Release

Answer

--output $(Build.ArtifactStagingDirectory)

Answer

--self-contained true

Question 3

You have a YAML pipeline that builds a Docker image and pushes it to Azure Container Registry (ACR). You need to dynamically set the image tag based on the build number. Which predefined variable should you use?

Accepted Answer

$(Build.BuildId). Option A is correct because Build.BuildId is a unique identifier for each build run. Option B is wrong because Build.BuildNumber is customizable and may not be numeric. Option C is wrong because System.TeamProject is the project name. Option D is wrong because System.JobId is a job-level ID.

Answer

$(System.JobId)

Answer

$(System.TeamProject)

Answer

$(Build.BuildNumber)

Question 4

You are troubleshooting a release pipeline that deploys an ARM template to Azure. The deployment fails with the error 'The subscription '...' could not be found.' The service connection used has Contributor permissions on the subscription. The pipeline runs successfully from the Azure DevOps portal when triggered manually. What is the likely cause?

Accepted Answer

The service principal used by the service connection is not authorized in the subscription.. Option C is correct because the pipeline might be using a service principal that is not authorized in the subscription when running from a specific context (e.g., a different tenant or using a managed identity). Option A is wrong because manual triggers would also fail if the subscription didn't exist. Option B is wrong because Contributor role is sufficient for ARM deployments. Option D is wrong because the issue is not about resource group location.

Answer

The service connection does not have sufficient permissions.

Answer

The subscription has been deleted.

Answer

The deployment is targeting a resource group in a different region.

Question 5

Your organization uses Azure Pipelines and requires that all builds be run on Microsoft-hosted agents to reduce maintenance overhead. However, you need to ensure that the build agent has a specific version of Node.js installed that is not available on the standard Microsoft-hosted agents. What should you do?

Accepted Answer

Use a script task to install the specific Node.js version at the start of the pipeline.. Option B is correct because you can use a script task to install Node.js using a version manager like nvm or download the required version. Option A is wrong because you cannot install software on a Microsoft-hosted agent permanently. Option C is wrong because self-hosted agents require maintenance. Option D is wrong because container jobs are possible but require the agent to support containers, and you still need to customise the container image.

Answer

Use a container job that runs a custom Docker image with the required Node.js version.

Answer

Deploy a self-hosted agent with the required Node.js version.

Answer

Request Microsoft to add the Node.js version to their hosted agents.

Question 6

Which TWO conditions must be met to use the 'Approvals and gates' feature in a release pipeline? (Choose two.)

Accepted Answer

A post-deployment approval must be configured.. Options A and C are correct. Approvals and gates require a pre-deployment approval and a post-deployment approval. Option B is incorrect because gates can be used without manual approval. Option D is incorrect because variable groups are not required. Option E is incorrect because service connections are not specifically required for approvals.

Answer

A manual intervention task must be added.

Answer

A variable group must be linked to the pipeline.

Answer

The pipeline must use a service connection.

Question 7

Which THREE factors should you consider when designing a strategy for managing secrets in Azure Pipelines? (Choose three.)

Accepted Answer

Use Azure Key Vault to store secrets.. Options A, C, and E are correct. Secrets should be stored in Azure Key Vault, retrieved using library variable groups linked to Key Vault, and referenced as secret variables. Option B is incorrect because variables in YAML are visible in logs. Option D is incorrect because hardcoding secrets is insecure.

Answer

Hardcode secrets in the pipeline YAML for simplicity.

Answer

Store secrets as plain text variables in YAML pipelines.

Question 8

Which TWO are valid types of triggers for a YAML pipeline in Azure Pipelines? (Choose two.)

Accepted Answer

Push trigger. Options A and B are correct. CI triggers (push) and PR triggers are valid YAML triggers. Option C is incorrect because scheduled triggers are defined outside YAML. Option D is incorrect because release triggers are for release pipelines, not YAML. Option E is incorrect because pipeline triggers are for triggering other pipelines, not directly in YAML.

Answer

Scheduled trigger

Answer

Release trigger

Answer

Pipeline trigger

Question 9

You are the DevOps lead for a large enterprise that uses GitHub for source control and Azure Pipelines for CI/CD. The organization has hundreds of repositories, each with its own pipeline. Recently, the security team mandated that all pipelines must use a centralized set of tasks for secret scanning and compliance checks before any deployment. You need to design a solution that enforces these mandatory tasks across all pipelines without modifying each pipeline individually. The solution should allow pipeline authors to add their own custom steps after the mandatory steps. The mandatory steps must be versioned and updated centrally. You also need to ensure that the mandatory steps are not bypassed by pipeline authors. What should you do?

Accepted Answer

Store the mandatory tasks as a YAML template in a central repository. In each pipeline, use the 'template' reference to include the mandatory steps. Use branch protection rules on the central repository to require approval for changes to the template.. Option C is correct because using a template repository with required templates and branch protection rules enforces the use of the mandatory steps. Option A is wrong because extensions can be disabled. Option B is wrong because a single pipeline cannot serve all repositories. Option D is wrong because the YAML template repository approach with enforcement through branch policies is the recommended way.

Answer

Use a global list of tasks in the Azure DevOps organization settings that automatically get injected into every pipeline.

Answer

Create a single pipeline that runs across all repositories and include the mandatory tasks in that pipeline.

Answer

Create a custom Azure DevOps extension that adds the mandatory tasks to all pipelines using a pre-job hook.

Question 10

Your team uses Azure Pipelines to build a .NET Core application. The build runs successfully on Windows agents, but you need to also run the build on Linux agents to validate cross-platform compatibility. The pipeline currently has a single `windows-latest` agent pool. What is the most efficient way to run the build on both platforms without duplicating the entire pipeline?

Accepted Answer

Add a `strategy` with a `matrix` that specifies `vmImage: ['windows-latest', 'ubuntu-latest']` in the job.. Option B is correct because a strategy with a matrix allows running the same job on multiple agent pools in parallel. Option A is wrong because it duplicates the pipeline. Option C is wrong because it would create two separate jobs that are not easily managed. Option D is wrong because multi-stage runs stages sequentially, not in parallel for this purpose.

Answer

Create two separate pipelines, one for each platform.

Answer

Use a multi-job pipeline with two jobs, each specifying a different pool.

Answer

Use a multi-stage pipeline with a stage for each platform.

Question 11

You are designing a release pipeline for a mission-critical application that must achieve zero-downtime deployments to Azure App Service (Web App for Containers). The application uses Azure SQL Database with schema migrations. The current deployment slot strategy uses staging and production slots. You need to ensure that during a swap, the staging slot is warmed up and the database schema is rolled back if the swap fails. Which combination of deployment slots and pre/post-swap actions should you implement?

Accepted Answer

Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new to staging, warm up staging, then swap staging to production. On failure, swap staging back to production.. Option C is correct because adding a third slot (e.g., 'test') allows you to apply schema changes in a non-production slot, swap test to staging to warm, then swap staging to production. If the final swap fails, you can swap back because the production slot still has the old code and old schema. Option A is wrong because swapping staging to production applies schema changes to production before the swap is complete, risking data loss on failure. Option B is wrong because swapping staging for a new slot without schema changes doesn't address database rollback. Option D is wrong because swapping staging to production uses automatic swap with no rollback handling.

Answer

Use two slots (staging and production) with auto-swap enabled. The auto-swap handles warm-up automatically. If the swap fails, Azure automatically rolls back.

Answer

Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new slot to staging, then staging to production. On failure, swap staging back to production.

Answer

Use two slots (staging and production). Apply schema changes in staging before swap. If swap fails, manually redeploy the old version to production.

Question 12

Your build pipeline uses a hosted agent. You need to securely pass a connection string to a deployment task. The connection string contains a password. What is the recommended approach to store and use this secret in Azure Pipelines?

Accepted Answer

Define the connection string as a secret variable in the pipeline's variable group or in the pipeline settings UI, and reference it as `$(connectionString)`.. Option B is correct because Azure Pipelines secret variables are encrypted and not exposed in logs. Option A is wrong because storing secrets in YAML variables directly exposes them. Option C is wrong because Azure Key Vault is more complex for simple secrets and requires additional permissions. Option D is wrong because environment variables in the agent are visible to other processes.

Answer

Define the connection string as a plain variable in the YAML pipeline.

Answer

Hardcode the connection string in the deployment script and set the file as read-only.

Answer

Store the connection string in Azure Key Vault and use the 'Azure Key Vault' task to retrieve it at runtime.

Question 13

Refer to the exhibit. You have this Azure Pipelines YAML definition. The pipeline runs manually, but you want it to automatically trigger on every push to the main branch and also build pull requests targeting main. Which change should you make?

Accepted Answer

Replace 'triggers: ["none"]' with 'triggers: ["main"]' and 'pr: ["none"]' with 'pr: ["main"]'.. Option C is correct because removing the explicit 'triggers: none' and 'pr: none' enables the default triggers: CI on push to any branch and PR triggers on PRs to any branch. To limit to main branch, you need to specify triggers and pr properly. Option A is wrong because 'none' disables triggers. Option B is wrong because setting both to 'none' disables triggers. Option D is wrong because setting triggers: none still disables CI, and pr: none disables PR triggers.

Answer

Remove the 'triggers' and 'pr' sections entirely.

Answer

Set 'triggers' to '["main"]' and 'pr' to '["none"]'.

Answer

Set 'triggers' to 'none' and 'pr' to 'none'.

Question 14

Your team uses Azure Pipelines to deploy a microservices application to Azure Kubernetes Service (AKS). Each microservice has its own pipeline that builds a Docker image and deploys it to a shared AKS cluster. The deployment must support rolling updates with zero downtime. You need to ensure that if a deployment fails (e.g., health check fails), the pipeline automatically rolls back to the previous version. Which deployment strategy should you implement in the pipeline?

Accepted Answer

Use a rolling update strategy with the 'kubectl apply' command, and include a post-deployment step that checks the rollout status. If the rollout fails, run 'kubectl rollout undo' to roll back.. Option D is correct because Kubernetes supports rolling updates natively, and with proper readiness probes, it can automatically roll back if the update fails. Combined with a pipeline task that monitors the rollout and triggers rollback on failure, this meets the requirement. Option A is wrong because canary deployments require manual or automated traffic shifting and do not automatically roll back the entire deployment. Option B is wrong because blue-green deployments require an additional AKS cluster or namespace and manual rollback steps. Option C is wrong because the KubernetesManifest task with rollout status does not automatically roll back; it only monitors.

Answer

Use a canary deployment strategy with a pipeline task that gradually shifts traffic to the new version and monitors error rates. If errors exceed a threshold, the task stops the canary.

Answer

Use the 'KubernetesManifest' task with the 'rollout status' option, which automatically rolls back if the rollout status indicates failure.

Answer

Use a blue-green deployment strategy with two separate AKS clusters. Deploy the new version to the green cluster, run health checks, and then update the load balancer to point to green. If health checks fail, keep pointing to blue.

Question 15

You are configuring a release pipeline that deploys to multiple environments (dev, test, prod). You want to ensure that the same build artifact is deployed to each environment without rebuilding. Which type of trigger should you use for the release pipeline?

Accepted Answer

Build completion trigger. Option B is correct because a build completion trigger starts the release pipeline when a build artifact is available, ensuring the same artifact is used across environments. Option A is wrong because a CI trigger starts a new build, not a release. Option C is wrong because a scheduled trigger runs at specific times, not tied to a build. Option D is wrong because a pull request trigger starts builds for PRs, not releases.

Answer

Pull request trigger

Answer

Continuous integration (CI) trigger

Answer

Scheduled trigger