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

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

$(Build.BuildNumber). The `$(Build.BuildNumber)` variable represents the build number, which is the name of the completed build. It's often customized to include versioning information, and it's the appropriate variable to use when tagging Docker images based on the build number. `$(Build.BuildId)` is a unique numeric ID for the build record, but it is not the build number.

Answer

$(System.JobId)

Answer

$(System.TeamProject)

Answer

$(Build.BuildId)

Question 2

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 container job that runs a custom Docker image with the required Node.js version.. Azure Pipelines supports container jobs on Microsoft-hosted agents with Docker (e.g., ubuntu-latest, windows-2019 with Docker enabled). By using a custom Docker image that includes the required Node.js version, you can run builds in a container while still using a Microsoft-hosted agent. Option C is also correct because you can use a script task at the start of the pipeline to install the specific Node.js version dynamically; Microsoft-hosted agents allow runtime installation of software via scripts. Options B and D are incorrect: B would require a self-hosted agent, violating the Microsoft-hosted agent requirement; D is not practical and not a guaranteed solution.

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 3

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.. Azure Key Vault is the recommended service for securely storing and managing secrets, keys, and certificates. By integrating Key Vault with Azure Pipelines, you can avoid exposing sensitive information in YAML files or pipeline logs. This approach ensures secrets are never hardcoded and are dynamically retrieved at runtime.

Answer

Hardcode secrets in the pipeline YAML for simplicity.

Answer

Store secrets as plain text variables in YAML pipelines.

Question 4

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

Accepted Answer

Push trigger. A is correct because a push trigger in a YAML pipeline automatically starts a pipeline run when a push is made to a specified branch or tag. B is correct because scheduled triggers are also valid in YAML pipelines, allowing you to run a pipeline on a schedule defined using cron syntax. D (PR trigger) is also a valid YAML trigger, but the question asks for exactly two valid types; the intended correct pair is push and scheduled triggers. Options C and E are not standard YAML trigger types in Azure Pipelines; release triggers are used in classic releases, and pipeline triggers are for triggering a pipeline from another pipeline, which is not a direct trigger type defined in the YAML file.

Answer

Release trigger

Answer

PR trigger

Answer

Pipeline trigger

Question 5

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

Create a custom Azure DevOps extension that adds the mandatory tasks to all pipelines using a pre-job hook.. D is correct. A custom Azure DevOps extension with a pre-job hook (pipeline decorator) automatically injects mandatory steps into every pipeline without requiring changes to individual pipelines. It is centrally managed and versioned, and cannot be bypassed by pipeline authors. A is incorrect because it requires adding a template reference to each pipeline and the template inclusion is optional; branch protection only prevents tampering with the template, not its omission. B is invalid because Azure DevOps has no global task list injection. C is invalid because a single pipeline cannot run across all repositories with custom steps.

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.

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.

Question 6

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.. Using a `strategy` with a `matrix` allows the same job to run on multiple agent pools in parallel, enabling cross-platform validation without duplicating the pipeline. Option A duplicates the entire pipeline, which is inefficient. Option B would require separate jobs, but not as concise as the matrix strategy. Option C uses stages, which run 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 7

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.. It uses three slots to isolate schema changes in a new slot, then swaps to staging for warm-up, and finally swaps to production. If the swap fails, rolling back staging to production reverses the schema changes, ensuring zero-downtime. This approach aligns with Azure App Service slot-swap best practices for mission-critical applications requiring database rollback capability.

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 8

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)`.. The recommended approach is to 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). Secret variables are encrypted at rest and never exposed in logs or to other tasks. Option A is incorrect because plain variables are visible in logs and YAML. Option B is incorrect because hardcoding secrets in scripts is insecure and violates best practices. Option D, while secure, is overkill for a simple secret and requires additional configuration and permissions, making it less recommended for this scenario.

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 9

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"]'.. In Azure Pipelines YAML, setting `triggers: ['none']` explicitly disables CI triggers, and `pr: ['none']` disables PR triggers. To enable automatic builds on every push to main and on pull requests targeting main, you must replace these with `triggers: ['main']` and `pr: ['main']`, which configures both CI and PR triggers for the main branch.

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 10

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.. It directly implements the required behavior: using `kubectl apply` for a rolling update (which inherently supports zero-downtime by gradually replacing pods), followed by a post-deployment step that checks the rollout status. If the rollout fails (e.g., due to health check failures), the pipeline runs `kubectl rollout undo` to automatically revert to the previous version, ensuring rollback on failure.

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 11

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. A build completion trigger ensures that the release pipeline is initiated only after a specific build pipeline completes, allowing the same build artifact to be deployed across multiple environments without rebuilding. This trigger is ideal for multi-environment release pipelines where consistency of the artifact is critical, as it decouples the build from the release and promotes the identical binary through dev, test, and prod.

Answer

Pull request trigger

Answer

Continuous integration (CI) trigger

Answer

Scheduled trigger

Question 12

Your build pipeline uses a self-hosted agent in your on-premises network. The agent pool is configured to use the 'latest' agent version. Recently, a new version of the Azure Pipelines agent was released, and your builds started failing because the new agent requires .NET 6.0, which is not installed on the agent machine. What is the best way to prevent this issue in the future?

Accepted Answer

Configure the agent pool to use a specific agent version (e.g., '2.210.0') and test new versions in a separate pool before updating.. It decouples your production pipeline from automatic agent updates. By pinning the agent pool to a known-working version (e.g., '2.210.0'), you can validate new agent releases in a separate test pool before rolling them out. This prevents breaking changes—like a new .NET dependency—from impacting your builds without prior testing.

Answer

Switch to using Microsoft-hosted agents instead of self-hosted.

Answer

Disable automatic agent updates on the self-hosted agents.

Answer

Install .NET 6.0 on the agent machine to meet the new requirement.

Question 13

You are designing a release pipeline for a multi-tenant SaaS application that is deployed to Azure App Service. Each tenant has its own App Service instance. The pipeline must deploy a new version of the application to a staging slot for each tenant, run smoke tests, and then swap the staging slot to production. You need to ensure that if the smoke tests fail for any tenant, the swap is not performed for that tenant, while other tenants continue. Which release pipeline configuration should you use?

Accepted Answer

Create a release with multiple jobs (one per tenant) in the same stage, each deploying to a tenant's staging slot, running tests, and conditionally swapping. Set the 'Run this job' condition to 'Only when all previous jobs have succeeded' or use custom conditions to skip swap on failure.. It uses separate jobs per tenant within a single stage, each with its own deployment, smoke test, and conditional swap. By setting the 'Run this job' condition to 'Only when all previous jobs have succeeded' or a custom condition, you ensure that a failed smoke test for one tenant blocks only that tenant's swap, while other tenants' jobs proceed independently. This design aligns with Azure Pipelines' job-level isolation, where each job runs on its own agent and can have independent success/failure conditions.

Answer

Create a single stage with a 'foreach' loop over tenants, and if smoke tests fail, skip the swap using a condition.

Answer

Create a single job with parallel tasks for each tenant, and configure failure conditions to skip the swap.

Answer

Create a single stage with multiple deployment tasks, one per tenant, and use a 'continue on error' option on each task.

Question 14

Your team uses GitHub Actions for CI/CD. You want to automatically deploy to Azure App Service whenever a pull request is merged to the main branch. Which event trigger should you use in the GitHub Actions workflow?

Accepted Answer

push: branches: [main]. In GitHub Actions, merging a pull request into `main` results in a `push` event to `main`. The `push` trigger with `branches: [main]` therefore correctly fires whenever a PR is merged. `pull_request: types: [closed]` fires on any PR closure, whether merged or not, so it would deploy even when a PR is closed without merging. To use `pull_request` for merges, you would need an additional `if: github.event.pull_request.merged == true` check, but the question asks for the event trigger alone.

Answer

pull_request: branches: [main]

Answer

pull_request: types: [closed] branches: [main]

Answer

release: types: [published]

Question 15

Which TWO actions should you take to protect sensitive information (e.g., API keys, passwords) in Azure Pipelines? (Choose two.)

Accepted Answer

Define secrets as pipeline secret variables and reference them as $(secretName).. Azure Pipelines allows you to define secret variables in the pipeline UI or YAML, which are encrypted at rest and never exposed in logs. Referencing them as $(secretName) ensures they are securely injected at runtime without being stored in plaintext. Option E is correct because Azure Key Vault provides a centralized, audited, and encrypted store for secrets, and variable groups linked to Key Vault allow pipelines to fetch secrets dynamically without embedding them in pipeline definitions.

Answer

Store secrets in environment variables on the agent machine.

Answer

Store secrets in a YAML file and include the file in the repository.

Answer

Use plain text variables in the pipeline and mask them using the 'Logging Command' feature.