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

Question 1

Which TWO conditions must be met for a self-hosted agent to be used in an Azure Pipelines agent pool? (Choose two.)

Accepted Answer

The agent must have network access to Azure Pipelines.. A self-hosted agent must have outbound network connectivity to Azure Pipelines (specifically to the Azure DevOps service endpoints) in order to receive job assignments, download tasks, and report status. Without this network access, the agent cannot communicate with the orchestration layer and will remain offline. This is a fundamental requirement for any agent, whether hosted or self-hosted.

Answer

The agent must be in the Default pool.

Answer

The agent must run on Windows Server.

Answer

The agent must be installed on a virtual machine.

Question 2

Which THREE factors should you consider when designing a release pipeline for a critical production application? (Choose three.)

Accepted Answer

Rollback strategy. A release pipeline for a critical production application must include a rollback strategy (e.g., deployment slots or redeploying a previous artifact) to recover quickly from failed releases, deployment health monitoring (e.g., Application Insights, Azure Monitor) to detect issues early and trigger rollbacks or alerts, and approval gates before production deployment to ensure manual or automated checks are passed. These three factors together minimize downtime and ensure controlled, safe releases.

Answer

Use of service principal with least privilege

Answer

Single environment deployment

Question 3

You have the YAML pipeline shown in the exhibit. What will be the output of the script in the Deploy stage?

Accepted Answer

Deploying to prod. The YAML pipeline defines a variable `environment` at the stage level with the value `prod`. The script in the Deploy stage references `$(environment)`, which resolves to `prod`, so the output is `Deploying to prod`. Stage-level variables override any pipeline-level or default variables for that stage.

Answer

The Deploy stage will be skipped

Answer

Deploying to dev

Answer

The script will fail because variable is not defined

Question 4

You need to run unit tests in your build pipeline and publish the test results to Azure Pipelines. Which task should you use?

Accepted Answer

Visual Studio Test task. To run unit tests and publish the results in Azure Pipelines, use the Visual Studio Test task. It executes the tests and automatically publishes the test results to the pipeline, providing rich reporting and pass/fail analysis. The Publish Test Results task is only used when you already have test result files (e.g., JUnit, TRX) from a previous step and need to import them; it does not run any tests itself. The DotNetCoreCLI test command can also run and publish results, but the Visual Studio Test task is the standard framework-agnostic choice.

Answer

DotNetCoreCLI task with test command

Answer

Npm task

Answer

Publish Test Results task

Question 5

Your team uses a multi-stage YAML pipeline in Azure Pipelines. The pipeline includes a stage that runs integration tests against a test environment. You want to ensure that the integration tests are not affected by other pipelines that deploy to the same environment concurrently. What should you implement?

Accepted Answer

Set the environment's 'Exclusive lock' check to enabled.. The 'Exclusive lock' check on an environment ensures that only one pipeline deployment can use that environment at a time. When enabled, Azure Pipelines will queue any other pipeline runs that target the same environment, preventing concurrent deployments that could interfere with integration tests. This directly addresses the requirement to avoid conflicts from parallel deployments.

Answer

Set the pipeline's 'Maximum number of parallel deployments' to 1.

Answer

Configure a required template check on the environment.

Answer

Add a manual approval check on the environment.

Question 6

You are designing a release pipeline for a critical application that requires zero-downtime deployments. The application runs on Azure Kubernetes Service (AKS) with multiple replicas. You are using Azure Pipelines with a canary deployment strategy. What is the best approach to gradually shift traffic to the new version while monitoring for errors?

Accepted Answer

Use a service mesh like Istio to route a percentage of traffic to the new version.. A service mesh like Istio provides fine-grained traffic splitting at the network layer, allowing a precise percentage of traffic (e.g., 5%, then 10%, then 50%) to be routed to the canary version while the rest goes to the stable version. Istio's telemetry (via Envoy sidecars) enables real-time error-rate and latency monitoring, so you can automatically or manually roll back if anomalies appear. This is the most controlled, observable approach for canary deployments on AKS.

Answer

Use Azure Application Gateway as an ingress controller with weighted backend pools.

Answer

Use the AKS rolling update strategy with max surge.

Answer

Deploy to a staging environment, then swap VIPs with production.

Question 7

Your development team uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub repository secrets are not exposed in build logs. What is the best practice?

Accepted Answer

Store secrets in GitHub repository secrets and reference them in workflows using ${{ secrets.SECRET_NAME }}. GitHub automatically masks secrets in logs.. GitHub automatically masks secrets referenced via the ${{ secrets.SECRET_NAME }} syntax in workflow logs. When a secret is used in a workflow, GitHub Actions scans the log output and replaces any occurrence of the secret value with '***', preventing exposure. This built-in mechanism is the recommended best practice as it requires no additional configuration and works across all steps and actions.

Answer

Use a custom action to manually mask secrets in the logs.

Answer

Define secrets as environment variables directly in the workflow YAML.

Answer

After the workflow runs, delete the logs from GitHub.

Question 8

You are managing a pipeline that deploys a microservices application to multiple Azure Kubernetes Service (AKS) clusters in different regions. You want to implement a progressive exposure strategy where the deployment first goes to a small cluster (canary), then to a medium cluster, and finally to all clusters. The deployment should be automated but with the ability to halt if errors occur. What should you use?

Accepted Answer

Use deployment gates with evaluation of health metrics (e.g., error rate) before proceeding to the next stage.. Deployment gates in Azure Pipelines allow you to automatically evaluate health metrics (such as error rate, CPU usage, or custom metrics from Application Insights) before promoting a release to the next stage. This enables a progressive exposure strategy (canary → medium → all clusters) with automated rollback or halt if the metrics breach thresholds, without requiring manual intervention.

Answer

Use manual approval gates between stages.

Answer

Configure a rolling deployment strategy on each cluster.

Answer

Use a manual validation step in the pipeline.

Question 9

Your team uses Azure Pipelines for CI/CD. The pipeline builds a Docker image and pushes it to Azure Container Registry (ACR). You need to ensure that only the main branch triggers a build of the Docker image. What should you configure in the pipeline YAML?

Accepted Answer

Set 'trigger: branches: include: - main'. Setting `trigger: branches: include: - main` in the pipeline YAML configures a CI trigger that only starts a new pipeline run when changes are pushed to the `main` branch. This ensures that the Docker image build and push to ACR occurs exclusively for the main branch, meeting the requirement.

Answer

Set 'pr: branches: include: - main'

Answer

Add a condition: 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' to the job.

Answer

Set 'trigger: branches: include: - *'

Question 10

You are designing a release pipeline for a Node.js application that deploys to Azure App Service. The pipeline must run integration tests against the deployed application. You want to use deployment slots to minimize downtime. What is the recommended approach?

Accepted Answer

Deploy to a staging slot, run tests against the staging slot, then swap to production.. Deploying to a staging slot first allows you to validate the application by running integration tests against the staging slot without impacting production traffic. After successful testing, swapping the staging slot with the production slot ensures zero-downtime deployment, as Azure App Service swaps the underlying virtual directories and configuration settings instantly.

Answer

Deploy to the production slot directly and run tests after deployment.

Answer

Deploy to a staging slot, swap, then run tests.

Answer

Deploy to a staging slot, run tests, then delete the staging slot.

Question 11

Which TWO actions should you take to implement a gated deployment strategy in Azure Pipelines?

Accepted Answer

Use deployment gates to evaluate metrics like error rate before allowing the next stage.. Option A is correct because deployment gates in Azure Pipelines are precisely the mechanism that queries external sources—such as Azure Monitor alerts, REST APIs, or work items—to evaluate metrics like error rate and automatically decide whether the stage may proceed, which is the core of a gated deployment. Option E is correct because manual approval checks (approvals and checks configured on an environment or service connection) pause the pipeline before production deployment so a human can verify readiness, which is a standard gating control in a gated release strategy. Option B is not correct because a dashboard is a monitoring and visualization tool; it reports health but does not itself gate or block a pipeline stage. Option C is not correct because a multi-stage YAML pipeline is just the structural definition of stages and does not by itself implement gating logic. Option D is not correct because a rollback strategy is a recovery measure after a failed deployment, not a gate that controls whether deployment proceeds.

Answer

Configure a dashboard to monitor application health.

Answer

Use a multi-stage YAML pipeline.

Answer

Configure a rollback strategy if deployment fails.

Question 12

Which THREE options are valid strategies for implementing progressive exposure in Azure Pipelines?

Accepted Answer

Ring-based deployment.. Ring-based deployment, canary deployment, and blue-green deployment are all valid strategies for progressive exposure. Ring-based deployment gradually rolls out to increasing groups of users (rings), often using deployment gates and percentage-based rollout. Canary deployment routes a small percentage of traffic to the new version before increasing it, allowing monitoring and rollback. Blue-green deployment runs two identical environments (blue and green) and switches traffic from the old to the new version, enabling immediate rollback. These strategies all provide controlled, incremental exposure to validate changes before full rollout.

Answer

Rolling update.

Answer

Immutable infrastructure.

Question 13

Which TWO tools can be used to manage feature flags in Azure DevOps pipelines?

Accepted Answer

LaunchDarkly.. LaunchDarkly is a third-party feature management platform that integrates with Azure DevOps pipelines to control feature flag rollouts, targeting, and experimentation. It allows teams to toggle features on/off without redeploying code, making it a valid tool for managing feature flags in pipeline-driven deployments.

Answer

Azure Policy.

Answer

Azure Monitor.

Answer

Azure Key Vault.

Question 14

You have an Azure DevOps pipeline that deploys to multiple environments. You need to ensure that approvals are required before production deployment. Which pipeline configuration should you use?

Accepted Answer

Define an environment with required approvers for the production stage. Azure DevOps environments allow you to define required approvers for a specific stage (e.g., production). When a pipeline deploys to that environment, it pauses and waits for manual approval before proceeding, ensuring that production deployments are gated by authorized personnel.

Answer

Set the pipeline trigger to 'Manual' only

Answer

Add a 'Manual Intervention' task in the pipeline

Answer

Configure branch policies on the main branch

Question 15

You are designing a multi-stage YAML pipeline in Azure DevOps that builds, tests, and deploys a .NET Core application. The pipeline must use a self-hosted agent pool for compliance. You need to minimize agent idle time while ensuring that the agent is always available for builds. What should you do?

Accepted Answer

Deploy a scale set agent pool with autoscaling enabled. A scale set agent pool with autoscaling enabled dynamically provisions and deprovisions Azure virtual machines based on the pipeline's demand, minimizing idle time while ensuring agents are available when builds are triggered. This approach aligns with the requirement for a self-hosted agent pool for compliance and optimizes cost by scaling down when no jobs are pending.

Answer

Provision a virtual machine scale set with a fixed number of agents

Answer

Install multiple agents on a single VM to maximize utilization

Answer

Use a single persistent agent and queue builds when idle