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

Question 1

Which TWO of the following are benefits of using deployment slots in Azure App Service? (Select TWO.)

Accepted Answer

Zero-downtime deployments.. Deployment slots enable zero-downtime deployments (C) by allowing you to swap a staging slot with the production slot. The swap operation warms up the target slot's application before routing traffic, ensuring no requests are dropped. This is a core feature of Azure App Service for safe, continuous delivery.

Answer

Automatic rollback on failure.

Answer

Independent scaling of each slot.

Answer

Geographic redundancy.

Question 2

Your team uses Azure Pipelines for CI/CD. You need to enforce that all builds produce a signed artifact. Which approach should you use?

Accepted Answer

Use a Pipeline decorator to inject the signing task into every build pipeline.. Pipeline decorators allow injecting tasks (like signing) into every pipeline globally without modifying individual pipeline definitions. Option A is wrong because YAML templates require each pipeline to explicitly extend them; they do not enforce automatic inclusion. Option B is wrong because branch policies control pull request merge conditions, not build steps. Option C is wrong because manual approval gates are used in release pipelines to control promotion, not to enforce signing during build.

Answer

Add a YAML template that includes the signing task and require all pipelines to extend it.

Answer

Set a branch policy requiring a signed build status.

Answer

Configure a manual approval gate on the build pipeline.

Question 3

During a release pipeline, you notice that the deployment to staging fails intermittently due to a timeout waiting for the health check endpoint to return 200. The health check typically passes within 30 seconds, but occasionally takes up to 2 minutes. You need to make the deployment more reliable without affecting the overall release time. What should you do?

Accepted Answer

Increase the health check timeout in the pipeline task to 3 minutes.. Increasing the health check timeout to 3 minutes accommodates the occasional 2-minute delay without failing the deployment. Since the health check typically passes within 30 seconds but can take up to 2 minutes, a 3-minute timeout ensures the pipeline waits long enough for the endpoint to return HTTP 200, making the deployment more reliable without adding extra retry cycles or changing the overall release time.

Answer

Remove the health check from the pipeline and rely on monitoring.

Answer

Add a retry task that runs the health check again after a failure.

Answer

Reduce the health check timeout to 10 seconds to fail fast and trigger a rollback.

Question 4

Your organization is adopting GitHub Actions for CI/CD. You need to ensure that only approved actions from your enterprise can be used in workflows. What should you configure?

Accepted Answer

Set the enterprise policy to 'Allow only specific actions' and add approved actions.. GitHub Enterprise allows administrators to restrict which actions can be used in workflows by setting the enterprise policy to 'Allow only specific actions' and then explicitly approving a curated list of actions. This ensures that only trusted, pre-approved actions (e.g., from verified publishers or your own organization) can be referenced, preventing the execution of unapproved or malicious actions. This policy is enforced at the enterprise level and applies to all repositories within the enterprise, providing centralized control over CI/CD supply chain security.

Answer

Use a third-party tool to scan workflows for disallowed actions after each commit.

Answer

Set the enterprise policy to 'Allow all actions' and rely on code review.

Answer

Configure repository permissions to restrict actions to only those created by your organization.

Question 5

You have a multi-stage YAML pipeline that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The build stage runs successfully, but the deploy stage fails with an error: 'Error: failed to get credentials: context deadline exceeded'. You verify that the AKS cluster is running and that the service connection is valid. What is the most likely cause?

Accepted Answer

The build agent's IP address is not allowed by the AKS cluster's network policies.. The error 'context deadline exceeded' when running `az aks get-credentials` indicates a network timeout, not an authentication or permission failure. Since the AKS cluster is running and the service connection is valid, the most likely cause is that the build agent's IP address is blocked by AKS network policies (e.g., authorized IP ranges or a firewall), preventing the agent from reaching the cluster's API server within the default timeout.

Answer

The Azure service connection has expired.

Answer

The service principal used by the pipeline does not have RBAC permissions on the cluster.

Answer

The container registry is not accessible from the build agent.

Question 6

You are using Azure Pipelines to deploy a function app. You need to automatically roll back the deployment if the post-deployment smoke tests fail. What should you do?

Accepted Answer

Add a stage that runs only when the previous stage fails, executing a rollback script.. Azure Pipelines supports conditional stage execution using expressions like `eq(variables['Build.Reason'], 'IndividualCI')` or `failed()`. By adding a stage that runs only when the previous deployment stage fails (e.g., `condition: failed()`), you can execute a rollback script that reverts the function app to its previous stable version. This ensures automatic rollback upon smoke test failure without manual intervention.

Answer

Configure the pipeline to retry the deployment on failure.

Answer

Use a pre-deployment approval gate to validate the build before deployment.

Answer

Set up a manual validation gate that requires operations to initiate a rollback.

Question 7

Your team uses GitFlow with Azure Repos. You need to ensure that every commit to the 'main' branch is built and deployed to production automatically. Which trigger should you configure in your YAML pipeline?

Accepted Answer

trigger:
  branches:
    include:
    - main. A branch-specific trigger defined with `trigger: branches: include: - main` will automatically run the pipeline on every commit to the 'main' branch. Option A is wrong because `trigger: none` disables CI triggers entirely, so the pipeline will not start on any commits. Option C is wrong because a scheduled trigger (`schedules:`) runs the pipeline at specific times, not in response to commits. Option D is wrong because a PR trigger (`pr:`) runs the pipeline when a pull request is created or updated, not on direct commits to 'main'.

Answer

Trigger: none

Answer

schedules:
- cron: "0 0 * * *"
  branches:
    include:
    - main

Answer

pr:
  branches:
    include:
    - main

Question 8

You have a YAML pipeline that uses a self-hosted agent. The agent runs on a VM in Azure. The pipeline fails intermittently with the error: '##[error]The job running on agent MyAgent has been cancelled because the agent was idle for more than the maximum idle time.' You need to resolve this issue. What should you do?

Accepted Answer

Configure the agent's idle timeout setting to a higher value or disable it.. The error indicates that the self-hosted agent was idle for longer than the configured maximum idle time, causing Azure Pipelines to cancel the job. Option A is correct because increasing or disabling the idle timeout setting on the agent (via the agent's configuration file or environment variable) directly addresses this issue by allowing longer periods of inactivity before cancellation.

Answer

Add more agents to the agent pool.

Answer

Increase the job's timeout in minutes.

Answer

Reduce the number of parallel jobs to avoid overloading the agent.

Question 9

You are designing a release pipeline that deploys to multiple environments (dev, test, prod) with approval gates between each. You need to ensure that the same build artifact is deployed to all environments. Which strategy should you use?

Accepted Answer

Use a single build pipeline and promote the same build artifact through each environment.. Promoting the same build artifact through each environment ensures consistency and traceability. In Azure Pipelines, a single build produces one immutable artifact; deploying that same artifact across dev, test, and prod eliminates the risk of environment-specific build variations. Approval gates between stages control the promotion, while the artifact remains unchanged.

Answer

Use a multi-stage YAML pipeline with a separate artifact for each stage.

Answer

Create a separate build pipeline for each environment to ensure environment-specific configurations.

Answer

Use a single build pipeline but trigger a new build for each environment.

Question 10

Refer to the exhibit. You have a YAML pipeline definition that builds a .NET application. You notice that the revision number is always 0. What is the most likely cause?

Accepted Answer

The counter expression uses a variable that is not defined as a counter, causing it to reset.. The counter expression in Azure DevOps YAML pipelines requires a named counter variable to persist its value across pipeline runs. If the variable used as the first parameter of the `counter` function (e.g., `minorVersion`) is not defined as a counter variable, the counter resets to the seed value (0) on each run. Option B correctly identifies that the variable is not defined as a counter, causing the revision number to always be 0.

Answer

The 'DotNetCoreCLI@2' task does not support the counter expression.

Answer

The counter expression resets every time the pipeline runs because of the 'minorVersion' variable.

Answer

The counter expression is evaluated after the build steps, so it always returns 0.

Question 11

Refer to the exhibit. You have a YAML pipeline that deploys an ARM template. The pipeline runs successfully on the first commit to main, but subsequent commits fail with 'The resource group myResourceGroup already exists'. How should you modify the pipeline to avoid this error?

Accepted Answer

Add a condition to check if the resource group exists before creating it.. Adding a condition to check if the resource group exists before creating it avoids the error when the resource group already exists from a previous deployment. Options A, C, and D are incorrect: changing the location (A) does not prevent the existence error, using a different service connection (C) does not address resource group existence, and renaming the pipeline (D) triggers a new pipeline but does not affect resource group existence.

Answer

Change the location to a different region.

Answer

Use a different service connection for each deployment.

Answer

Rename the pipeline to trigger a clean build.

Question 12

Which TWO actions should you take to implement a secure CI/CD pipeline that uses Azure Pipelines and prevents unauthorized access to production? (Choose two.)

Accepted Answer

Configure deployment approvals and checks on the production stage.. Deployment approvals and checks in Azure Pipelines require manual sign-off or automated policy validation before a release proceeds to production, preventing unauthorized or unverified changes. Option D is correct because using a service connection with a managed identity eliminates the need to store static credentials, reducing the risk of credential exposure and unauthorized access to Azure resources during deployment.

Answer

Store production secrets as pipeline variables marked as 'Secret'.

Answer

Enable PR triggers for the production stage to validate changes.

Answer

Use self-hosted agents running on-premises for all pipelines.

Question 13

Which TWO practices help improve the security of container images in a CI/CD pipeline? (Choose two.)

Accepted Answer

Sign container images to verify their integrity.. Signing container images (Option C) ensures their integrity and authenticity by allowing the CI/CD pipeline to verify that the image has not been tampered with since it was signed, typically using tools like Docker Content Trust (DCT) or Notary. Scanning container images for vulnerabilities (Option E) during the build identifies known security issues in the image layers and dependencies, allowing teams to remediate before deployment. Both practices are essential for supply chain security. The other options are incorrect: running as root increases risk, public registries expose images, and 'latest' tags cause unpredictable updates.

Answer

Run containers with root privileges to avoid permission issues.

Answer

Store container images in a public registry for easy access.

Answer

Use the 'latest' tag for base images to always get the newest patches.

Question 14

Your team uses Azure DevOps to deploy a Node.js web app to Azure App Service on Linux. The build pipeline runs `npm install` and `npm run build`, then publishes the `dist` folder. The release pipeline uses the 'Azure App Service deploy' task. Recently, deployments fail intermittently with 'ERR_MODULE_NOT_FOUND' for a custom module. The module is listed in `package.json` and is present in the `node_modules` folder on the build agent. What is the most likely cause?

Accepted Answer

The build artifact does not include node_modules; the app requires them at runtime.. The most likely cause is that the build artifact does not include the `node_modules` folder. The build pipeline runs `npm install` and `npm run build`, which installs dependencies on the build agent, but only the `dist` folder is published as the artifact. At deployment time, the Azure App Service on Linux expects the `node_modules` folder to be present in the deployed artifact because it does not automatically run `npm install` for Node.js apps on Linux (unlike Windows-based App Services). Without `node_modules`, the app cannot resolve custom modules at runtime, leading to the `ERR_MODULE_NOT_FOUND` error.

Answer

The 'Azure App Service deploy' task modifies package.json during deployment.

Answer

The 'Azure App Service deploy' task runs npm install on the target, but it fails due to network restrictions.

Answer

The deployment slot's Kudu service fails to sync the dist folder.

Question 15

You are designing a multi-stage YAML pipeline for a .NET Core application. The pipeline must build, test, and deploy to a staging environment. You want to ensure that the deployment stage only runs if the build and test stages succeed, and that the staging deployment uses the exact same bits that were built. Which strategy should you use?

Accepted Answer

Create separate stages for build, test, and deploy. Use the 'dependsOn' keyword and publish artifact in build stage, download in deploy stage.. Using separate stages with 'dependsOn' ensures the deployment stage only runs after successful build and test stages. Publishing the build artifact in the build stage and downloading it in the deploy stage guarantees that the exact same compiled bits are used for deployment, maintaining consistency across environments.

Answer

Set up a release pipeline that uses the same build artifact and requires manual approval.

Answer

Use a build trigger on the staging branch to deploy after each commit, ignoring test results.

Answer

Define the pipeline with a single stage and use a condition to skip test on failure.