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

Question 1

Your team uses Azure Pipelines for CI/CD. You need to ensure that only approved branches can trigger production deployments. Which feature should you use?

Accepted Answer

Branch control for environments. Branch control for environments in Azure Pipelines allows you to restrict which branches can trigger deployments to specific environments, such as production. By configuring branch filters on an environment, you ensure that only approved branches (e.g., main or release branches) can initiate a production deployment, providing a security and governance boundary.

Answer

YAML template expressions

Answer

Deployment gates

Answer

Pipeline decorators

Question 2

You are designing a release pipeline for a microservices application. Each service must be deployed independently with zero downtime. Which deployment strategy should you recommend?

Accepted Answer

Blue-green deployment. Blue-green deployment is the correct strategy because it maintains two identical environments (blue and green) and allows instant traffic switch to the new version while keeping the old version running, enabling zero-downtime deployment and immediate rollback if issues arise. This aligns with the requirement of independent deployment for each microservice. Option A (rolling update) is incorrect because it replaces instances gradually, which can cause version skew and does not provide instant rollback. Option B (feature flags) is a technique for feature toggling, not a deployment strategy; it does not handle traffic shifting or environment isolation. Option C (canary release) is incorrect because it routes a small subset of users to the new version, which does not guarantee immediate full zero-downtime deployment and requires gradual rollout and monitoring.

Answer

Rolling update

Answer

Feature flags

Answer

Canary release

Question 3

Your team needs to automatically run a pipeline whenever a pull request is created in GitHub. Which trigger should you configure in Azure Pipelines?

Accepted Answer

Pull request trigger. Azure Pipelines provides a dedicated pull request trigger that automatically starts a pipeline when a pull request is created or updated in GitHub. This trigger validates proposed changes before merging, ensuring code quality and preventing broken builds from entering the main branch.

Answer

Pipeline completion trigger

Answer

Scheduled trigger

Answer

Continuous integration trigger

Question 4

You have a multi-stage YAML pipeline that deploys to Azure App Service. The deployment to the production stage should only proceed if a manual approval is granted. How should you configure this?

Accepted Answer

Add an approval check on the production environment. Azure Pipelines supports approval checks on environments, which allow you to require manual approval before a deployment proceeds to a specific stage. By adding an approval check on the production environment, the pipeline will pause at that stage until an authorized user grants approval, meeting the requirement for manual sign-off before production deployment.

Answer

Use deployment gates with Azure Monitor metrics

Answer

Configure branch policies on the main branch

Answer

Add a pipeline decorator to require sign-off

Question 5

You are designing a build pipeline that must run on Microsoft-hosted agents. The pipeline has a dependency on a native library that is not pre-installed. You want to minimize pipeline duration. Which approach should you use?

Accepted Answer

Use a container job with a custom Docker image that includes the library. Using a container job with a custom Docker image that includes the native library allows the pipeline to run on Microsoft-hosted agents while eliminating installation overhead, thus minimizing pipeline duration. This approach meets the requirement of using Microsoft-hosted agents and avoids the time cost of installing the library in each run.

Answer

Use a self-hosted agent with the library pre-installed

Answer

Add a script step to install the library using a package manager

Answer

Download the library from Azure Blob Storage in each build

Question 6

Your organization uses Azure DevOps and GitHub. You need to ensure that secrets such as API keys are not exposed in pipeline logs. What should you do?

Accepted Answer

Store the API key in Azure Key Vault and use a variable group linked to the vault. Both secret variables and variable groups linked to Azure Key Vault are masked in pipeline logs. Azure Pipelines automatically masks secret variables, and variables from Key Vault variable groups are also treated as secrets. Therefore, both B and C prevent exposure. The question asks 'what should you do?' without requiring a single best method, so both B and C should be considered correct.

Answer

Store the API key in a plain text variable and reference it as $(apiKey)

Answer

Use the Logging Command to suppress output

Question 7

Your team is adopting Infrastructure as Code (IaC) using Bicep. You need to validate the Bicep file syntax and run pre-deployment checks as part of the build pipeline. Which task should you use?

Accepted Answer

Azure CLI task with 'az bicep build'. The `az bicep build` command compiles a Bicep file into an ARM template and performs syntax validation, making it the correct choice for validating Bicep syntax and running pre-deployment checks in a build pipeline. This task ensures that the Bicep code is syntactically correct before any deployment attempt, aligning with Infrastructure as Code (IaC) best practices.

Answer

Azure Resource Group Deployment task

Answer

Terraform task

Answer

PowerShell task with Invoke-RestMethod

Question 8

You manage a release pipeline that deploys to multiple environments. The pipeline uses variables that differ per environment. You want to avoid duplicating variable definitions. Which strategy should you use?

Accepted Answer

Use variable groups linked to environments. Variable groups linked to environments allow you to define variables once and have different values per environment without duplication. Option A is correct because variable groups can be scoped to specific environments, allowing you to reuse the same variable names with different values across environments. Option B is incorrect because using conditions in the 'variables' section still requires you to define each variable for each condition, leading to duplication. Option C is incorrect because defining variables in each stage duplicates the variable definitions across stages. Option D is incorrect because while Azure Key Vault is useful for secrets, it is not designed for all types of variables, and you still need to reference the secrets per environment, which does not avoid duplication of variable references.

Answer

Use the 'variables' section in the pipeline YAML with conditions

Answer

Define variables in each stage of the YAML pipeline

Answer

Store all variables in Azure Key Vault and reference them in the pipeline

Question 9

Which TWO features can you use to enforce quality gates before a production deployment in Azure Pipelines?

Accepted Answer

Approval checks on environments. Approval checks on environments allow you to require manual sign-off before a release proceeds to a production stage. This enforces a quality gate by ensuring that a designated approver reviews and authorizes the deployment. Option E is correct because deployment gates evaluate health metrics (e.g., from Azure Monitor or Application Insights) automatically, blocking or allowing the deployment based on predefined conditions such as error rates or performance thresholds.

Answer

Scheduled triggers

Answer

Branch policies on repositories

Answer

Pipeline decorators

Question 10

Which THREE steps should you take to implement a secure CI/CD pipeline that uses secrets from Azure Key Vault?

Accepted Answer

Use the Azure Key Vault task to download secrets as variables. The Azure Key Vault task in Azure Pipelines can download secrets as pipeline variables at runtime, allowing the pipeline to securely reference them without exposing the secret values in logs or configuration. This task authenticates to Key Vault using a service connection or managed identity, ensuring secrets are never stored in the pipeline definition.

Answer

Store secrets as plain text variables in the pipeline library

Answer

Hardcode secrets in the YAML file and use variables to mask them

Question 11

Which TWO practices help you manage build artifacts efficiently in Azure Pipelines?

Accepted Answer

Set retention policies to automatically delete old artifacts. Setting retention policies (A) helps automate cleanup of old artifacts, reducing storage waste. Using the Publish Build Artifacts task (D) is the standard way to store artifacts from builds efficiently. Option B (copying to each agent) is wasteful because it duplicates artifacts unnecessarily. Option C (manual download) is inefficient because it requires human intervention and does not scale. Option E (large single files) makes downloads and incremental updates difficult.

Answer

Copy artifacts to each agent's local storage

Answer

Download all artifacts manually after each build

Answer

Store artifacts as large single files to reduce number of files

Question 12

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You have a monorepo with multiple projects. You need to design a pipeline that only builds and tests the projects that have changed in each commit. You want to minimize build time and avoid unnecessary runs. The pipeline should also handle dependencies between projects. Which approach should you use?

Accepted Answer

Configure path filters in the pipeline trigger, and use a custom script to detect dependencies and build only affected projects plus their dependents. It uses path filters in the pipeline trigger to only run when files in the changed projects are modified, and a custom script detects dependencies between projects to also build any dependent projects. This minimizes build time while ensuring all affected projects are built. Option A builds all projects on every commit, which is inefficient. Option C only builds changed projects but ignores dependency chains, potentially breaking the build. Option D requires manual triggers, which is not automated and defeats the purpose of CI/CD.

Answer

Create a single pipeline that builds all projects on every commit

Answer

Use a single pipeline with a condition that checks which files changed and runs only the corresponding job

Answer

Create separate pipelines for each project and trigger them manually

Question 13

Your team deploys a web application to Azure App Service using Azure Pipelines. The application requires a configuration file that contains connection strings and app settings. You need to ensure that the configuration is environment-specific and that sensitive values are not exposed in the pipeline logs. The configuration file is stored in a Git repository with different branches for each environment. You also need to support local development with the same configuration approach. Which strategy should you use?

Accepted Answer

Store environment-specific settings in Azure App Service configuration, and use variable groups in Azure Pipelines for secrets. Use token replacement in the config file during deployment.. The recommended approach is to store environment-specific settings (non-secret) in Azure App Service configuration settings, and store secrets in Azure Pipelines variable groups. During deployment, use token replacement in the config file to replace placeholders with actual values. This ensures secrets are not exposed in logs or stored in the repository, and supports local development by using config transforms. Option A exposes secrets by storing them in the repository. Option B uses a single config file and sticky settings, which does not address environment-specific configurations and can be insecure. Option D relies on branch-based pipeline variables, which may not support local development and can lead to secrets exposure in logs if not properly handled.

Answer

Store all settings, including secrets, in the config file in each branch. Use a script to replace tokens.

Answer

Use Azure App Service slots with sticky settings and store all settings in a single config file committed to the repository.

Answer

Use the same config file for all environments and override settings using pipeline variables based on branch name.

Question 14

You are responsible for a release pipeline that deploys a containerized application to Azure Kubernetes Service (AKS). The pipeline currently builds and pushes a Docker image to Azure Container Registry (ACR) and then updates the Kubernetes manifest. You need to implement a rollback strategy in case the deployment fails. The rollback should revert to the previous known good version of the application. Which approach should you use?

Accepted Answer

Use the Kubernetes task with the 'rollback' option, which runs 'kubectl rollout undo' on the deployment.. 'kubectl rollout undo' is a native Kubernetes feature that automatically reverts the deployment to the previous ReplicaSet, providing a simple and reliable rollback without manual intervention or additional tools. Option A is manual and not automated. Option B re-runs the entire pipeline, which may build a new image and not truly revert to the previous version. Option D uses Helm, which adds complexity when native rollback is sufficient.

Answer

Keep the previous Docker image tag in ACR and update the manifest to point to it manually.

Answer

Rerun the previous successful pipeline run.

Answer

Use Helm to manage releases and rollback using 'helm rollback' command.

Question 15

Your team uses Azure DevOps for CI/CD. You want to ensure that only code from the main branch is deployed to production. The release pipeline has a pre-deployment condition that requires approval. However, you notice that a release created from a feature branch was approved and deployed. What is the most likely cause?

Accepted Answer

The pre-deployment condition did not include a branch filter on the artifact.. The pre-deployment condition in Azure DevOps release pipelines can include a branch filter on the artifact to restrict which branches trigger a release. If this filter is not configured, any release—regardless of the source branch—can proceed through the approval gate. Since the feature branch release was approved and deployed, the most likely cause is that the pre-deployment condition lacked a branch filter to enforce that only artifacts from the main branch are eligible.

Answer

The deployment queue settings were set to 'Deploy all in parallel'.

Answer

The artifact was published from a build pipeline that allowed any branch.

Answer

The pre-deployment condition was set to 'After release' instead of 'Before deployment'.