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

Question 1

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub repository secrets are not exposed in build logs. Which security practice should you implement?

Accepted Answer

Use GitHub Actions secrets and ensure they are marked as masked. GitHub Actions automatically masks secret values in build logs when referenced via the secrets context, such as ${{ secrets.SECRET_NAME }}. Option B is wrong because storing secrets in a repository YAML file exposes them to anyone with repo access. Option C is wrong not because environment variables are unsecurely logged, but because it is not the recommended practice; secrets should be referenced directly through the secrets context to avoid risk of unintended exposure (e.g., if the value is modified or used outside GitHub's masking). Option D, while a valid security practice, does not directly address preventing log exposure unless the fetched secrets are also masked.

Answer

Store secrets in a YAML file within the repository

Answer

Pass secrets as environment variables in the workflow

Answer

Use a third-party secret management service and fetch secrets at runtime

Question 2

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 3

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

Question 4

You have a pipeline that uses Azure Repos Git. You need to enforce that all commits to the main branch are associated with a work item. Which branch policy should you enable?

Accepted Answer

Require linked work items. Require linked work items. This branch policy enforces that pull requests or commits to the main branch have at least one associated work item, ensuring traceability. Option B, Limit merge types, restricts which merge strategies can be used (e.g., squash, rebase), but does not enforce work item linking. Option C, Require a minimum number of reviewers, ensures code review but not work item association. Option D, Check for comment resolution, requires that all comments on pull requests are resolved before merging, which is unrelated to work items.

Answer

Limit merge types

Answer

Require a minimum number of reviewers

Answer

Check for comment resolution

Question 5

Your release pipeline uses deployment groups to deploy to Windows servers. You need to securely pass credentials to a script that runs on target machines. What is the recommended approach?

Accepted Answer

Use Azure Key Vault task to fetch secrets during deployment. The Azure Key Vault task securely retrieves secrets (e.g., passwords) from an Azure Key Vault during deployment, avoiding hardcoded or exposed credentials. This integrates with Azure Pipelines to pass secrets to scripts without storing them in the pipeline or on target machines, adhering to least-privilege and secure secret management practices.

Answer

Hardcode credentials in the script and encrypt the script file

Answer

Store credentials as pipeline variables and reference them

Answer

Use environment variables on the target machines

Question 6

You need to configure a build pipeline that triggers only when changes are pushed to the 'release/*' branch. Which trigger configuration should you use?

Accepted Answer

Set 'trigger: branches: include: - release/*'. The YAML trigger configuration 'trigger: branches: include: - release/*' explicitly specifies that the pipeline should run only when changes are pushed to any branch matching the 'release/*' wildcard pattern. This is the standard way to define branch-based triggers in Azure Pipelines YAML, ensuring that only pushes to release branches initiate the build.

Answer

Set 'trigger: none' in YAML

Answer

Set 'trigger: branches: include: - main'

Answer

Set 'trigger: tags: include: - v*'

Question 7

Your organization uses GitHub Actions. You need to create a reusable workflow that builds and tests a Node.js application. Which approach should you use to define the workflow?

Accepted Answer

Define a reusable workflow with 'on: workflow_call'. Reusable workflows are defined in a separate file with workflow_call trigger. Option A is wrong because it defines a workflow that cannot be reused. Option B is wrong because actions are different from workflows. Option C is wrong because composite actions are for multiple steps, not entire workflows.

Answer

Define a standard workflow in .github/workflows/build.yml

Answer

Use a composite action to encapsulate the build steps

Answer

Create a custom action and reference it in multiple workflows

Question 8

You are deploying a multi-container application to Azure Kubernetes Service (AKS) using Azure Pipelines. You need to ensure that the deployment rollback automatically if the health checks fail. Which strategy should you implement?

Accepted Answer

Configure a rolling update with readiness and liveness probes. A rolling update with readiness and liveness probes is the correct strategy because Kubernetes automatically monitors pod health via these probes. If a new pod fails its readiness probe, the rolling update pauses; if the liveness probe fails, the pod is restarted. Azure Pipelines can be configured to detect probe failures and trigger a rollback to the previous stable ReplicaSet, ensuring automated recovery without manual intervention.

Answer

Use a blue-green deployment strategy

Answer

Use Helm charts with pre-upgrade hooks

Answer

Implement a canary deployment with manual verification

Question 9

You have a pipeline that builds a Docker image and pushes it to Azure Container Registry. You need to ensure that only the latest successful build image is tagged as 'latest'. Which tagging strategy should you use?

Accepted Answer

Use a conditional step that runs only when the build succeeds to tag the image as 'latest'. It ensures the 'latest' tag is applied only after a successful build, preventing broken or incomplete images from being tagged as 'latest'. In Azure Pipelines, you can use a condition like `condition: succeeded()` on a script or Docker task that runs `docker tag` and `docker push` to update the 'latest' tag only when the preceding build steps succeed. This maintains a reliable 'latest' pointer to the most recent stable image.

Answer

Use the build ID as the tag and manually update 'latest'

Answer

Use the Git commit hash as the tag and push 'latest' separately

Answer

Always tag the image as 'latest' regardless of build status

Question 10

Which TWO practices should you adopt to improve the security of your Azure DevOps pipeline? (Choose two.)

Accepted Answer

Grant the least privilege to service connections. Granting the least privilege to service connections (Option A) is a core security principle that limits the permissions of automated processes to only what is strictly necessary, reducing the blast radius of a compromised connection. Using Azure Key Vault to store secrets and fetch them at runtime (Option B) ensures that sensitive values like API keys and passwords are never exposed in pipeline definitions or logs, and are securely retrieved via managed identities or service principals at execution time.

Answer

Use the default hosted agent for all builds

Answer

Store secrets as plain text in pipeline variables

Answer

Allow contributors to bypass the required reviewer policy

Question 11

Which TWO features of Azure Pipelines help you manage build artifacts across stages? (Choose two.)

Accepted Answer

Download Pipeline Artifact task. The Publish Pipeline Artifact task (option E) makes files available to subsequent stages by uploading them to Azure Pipelines, while the Download Pipeline Artifact task (option D) retrieves those artifacts in later stages. Together, they form the primary mechanism for passing build outputs across stages in a pipeline.

Answer

Pipeline variables

Answer

Release gates

Answer

Build tags

Question 12

The pipeline fails with the error 'The resource with name 'myregistry' could not be found'. What is the most likely cause?

Accepted Answer

The Azure Container Registry name is incorrect. The error 'The resource with name 'myregistry' could not be found' indicates that the Azure Container Registry name specified in the pipeline is incorrect or does not exist in the subscription. Option A is correct because the most likely cause is a misspelled or wrong registry name. Option B is incorrect because the build ID variable is unrelated to finding a registry resource. Option C is incorrect because permission issues typically result in authorization errors, not 'not found'. Option D is incorrect because Azure CLI availability does not affect resource lookup, and the error is about resource existence, not CLI installation.

Answer

The build ID variable is not defined

Answer

The service connection does not have permission to access the registry

Answer

The Azure CLI is not installed on the agent

Question 13

The pipeline fails because the artifact is empty. What is the most likely cause?

Accepted Answer

The build output is not copied to the staging directory. The most common reason for an empty artifact in Azure Pipelines is that the build output files were not copied to the staging directory (typically $(Build.ArtifactStagingDirectory)) before the PublishBuildArtifacts task runs. The PublishBuildArtifacts task publishes whatever is in the staging directory; if no files are copied there, the artifact will be empty. This is a standard pattern where a Copy Files task or similar step must explicitly place the build outputs into the staging directory.

Answer

The projects pattern '**/*.csproj' does not match any files

Answer

The task 'PublishBuildArtifacts@1' is misspelled

Answer

The artifact name 'drop' is invalid

Question 14

Your team is using YAML pipelines in Azure DevOps and wants to ensure that a specific stage runs only for changes to the 'main' branch. Which condition should you add to the stage?

Accepted Answer

condition: eq(variables['Build.SourceBranch'], 'refs/heads/main'). The `eq(variables['Build.SourceBranch'], 'refs/heads/main')` condition evaluates to true only when the pipeline is triggered by a change to the 'main' branch. In YAML pipelines, conditions are evaluated as expressions, and this simple equality check ensures the stage runs exclusively for that branch. The other options either invert the logic, use a partial match that could include other branches, or unnecessarily combine conditions.

Answer

condition: ne(variables['Build.SourceBranch'], 'refs/heads/main')

Answer

condition: contains(variables['Build.SourceBranch'], 'main')

Answer

condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

Question 15

Your organization uses GitHub Actions for CI/CD. You need to implement a deployment strategy where a new version of the application is gradually shifted from the stable environment to a canary environment, and if health checks pass, the traffic is fully shifted to the canary. Which GitHub Actions deployment strategy should you use?

Accepted Answer

Canary deployment. A canary deployment gradually shifts traffic from the stable environment to a new canary environment, using health checks to validate the new version before fully routing all traffic to it. This matches the requirement of a gradual shift with health-check gating. GitHub Actions supports this via deployment strategies like `canary` in environments or custom workflows with traffic-splitting tools.

Answer

Recreate deployment

Answer

Blue-green deployment

Answer

Rolling deployment