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

Question 1

Your release pipeline uses Azure Kubernetes Service (AKS) and Helm charts. You need to roll back to a previous release quickly if the new release fails health checks. What is the BEST approach?

Accepted Answer

Use Helm rollback command.. Helm provides a built-in `helm rollback ` command that reverts a release to a previous revision in a single, atomic operation. This is the fastest and most reliable method for rolling back a failed Helm-based deployment on AKS, as it directly restores the exact Kubernetes manifests and configuration from the specified revision without manual intervention.

Answer

Manually redeploy the previous Helm chart version.

Answer

Use a canary deployment strategy.

Answer

Use a Kubernetes Deployment rollout undo.

Question 2

You are configuring a build pipeline for a JavaScript application. You want to run linting, unit tests, and build steps only when changes are pushed to the 'develop' branch. Which trigger should you configure?

Accepted Answer

Enable CI trigger with a branch filter for 'develop'.. Enabling a CI trigger with a branch filter for 'develop' ensures that the pipeline automatically runs linting, unit tests, and build steps only when changes are pushed to the 'develop' branch. This matches the requirement precisely, as CI triggers respond to push events, and the branch filter restricts execution to the specified branch.

Answer

Enable pull request trigger.

Answer

Enable scheduled trigger.

Answer

Enable continuous integration (CI) trigger without branch filters.

Question 3

Your build pipeline uses a YAML template to define steps. You want to pass a parameter to the template to conditionally run a task. What syntax should you use in the template?

Accepted Answer

parameters:. The 'parameters' key in a YAML template is used to define parameters that can be passed to the template, allowing conditional execution based on the parameter value. Option B is incorrect: 'arguments' is not a standard YAML key for passing parameters to templates; it is used for specifying script arguments. Option C is incorrect: 'inputs' is used for task inputs within a step, not for template parameters. Option D is incorrect: 'variables' are used to define pipeline variables, not for passing parameters to templates.

Answer

arguments:

Answer

inputs:

Answer

variables:

Question 4

You are designing a release pipeline that deploys to multiple environments (dev, test, prod) sequentially. You need to require manual approval before deploying to prod. The approver should be able to review the changes and approve or reject. Which feature should you use?

Accepted Answer

Pre-deployment conditions.. In Azure DevOps release pipelines, to require manual approval before deploying to a specific stage, you configure the pre-deployment conditions of that stage, specifically assigning pre-deployment approvers. These approvers can review the changes and then approve or reject the deployment. This satisfies the requirement directly.

Answer

Environment checks.

Answer

Approval gates.

Answer

Manual intervention task.

Question 5

Your team uses GitHub Actions for CI/CD. You want to securely store a database connection string used in a workflow. Where should you store it?

Accepted Answer

GitHub Secrets.. GitHub Secrets is the correct choice because it provides encrypted storage for sensitive data like database connection strings. When you store a value in GitHub Secrets, it is encrypted via libsodium before being stored, and it is only exposed to GitHub Actions workflows as an environment variable or input when explicitly referenced. This prevents the secret from being logged or leaked in the workflow output, unlike other storage methods that risk exposure.

Answer

Workflow environment variables.

Answer

Directly in the workflow YAML.

Answer

In a configuration file committed to repo.

Question 6

Which THREE of the following are valid steps to implement a trunk-based development workflow in Azure Repos? (Select THREE.)

Accepted Answer

Run CI builds on the main branch.. Trunk-based development requires developers to integrate into the main branch frequently. In Azure Repos, you set a CI trigger on main so every commit is built and validated (A). Developers use short-lived feature branches that are merged into main within a day (D) to keep integration conflicts small. Feature flags and pair programming are supporting practices that allow work to be integrated even before a feature is complete, avoiding long-running branches (B). Merging to main only once per week (C) contradicts the continuous-integration principle, and creating a release branch for every production release (E) is characteristic of GitFlow/release-flow, not trunk-based development.

Answer

Merge to main only once per week.

Answer

Create release branches for each production release.

Question 7

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 8

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 9

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 10

You are designing a release pipeline that deploys a web app to Azure App Service. You need to ensure that configuration secrets (e.g., database connection strings) are not stored in the pipeline YAML file. Which approach should you use?

Accepted Answer

Use an Azure Key Vault variable group linked to the pipeline.. Azure Key Vault variable groups allow you to securely reference secrets stored in Azure Key Vault from within a pipeline without exposing them in the YAML file. The pipeline retrieves the secrets at runtime via a linked service connection, ensuring they never appear in source control or pipeline logs.

Answer

Define the secrets as agent-scoped variables in the release pipeline.

Answer

Hardcode the secrets in the App Service configuration and reference them in the pipeline.

Answer

Store the secrets as pipeline variables and mark them as 'Secret'.

Question 11

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 12

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 13

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 14

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. To automatically build and deploy on every commit to the 'main' branch, you need a CI trigger that includes the 'main' branch. The YAML snippet 'trigger: branches: include: - main' does exactly that. It tells Azure Pipelines to trigger a run whenever a commit is pushed to 'main'. Other options either disable triggers, schedule runs, or trigger on pull requests, none of which meet the requirement of automatic build on commit.

Answer

Trigger: none

Answer

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

Answer

pr:
  branches:
    include:
    - main

Question 15

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.