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

Question 1

Your organization uses Azure Pipelines to manage infrastructure as code with Terraform. The pipeline runs terraform plan and apply. You need to ensure that the state file is stored securely and can be locked to prevent concurrent modifications. What should you configure?

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

Accepted Answer

Use the Terraform Cloud backend with remote operations.. Both Azure Storage backend (D) and Terraform Cloud backend (B) satisfy the requirement of secure state storage and locking. Azure Storage uses blob leases; Terraform Cloud uses its own locking mechanism. The original explanation only justifies D but does not explain why B is incorrect, and it cannot be considered incorrect as written.

Answer

Store the state file in a Git repository with LFS.

Answer

Store the state file in Azure Pipelines secure files.

Question 2

Which TWO triggers can be used to automatically start a pipeline in Azure Pipelines? (Choose two.)

Accepted Answer

Continuous integration (CI) trigger. Option A, the continuous integration (CI) trigger, is correct because it automatically starts a pipeline whenever changes are pushed to the configured branches, using the `trigger:` keyword in YAML or the Triggers tab in the classic editor. Option B, the webhook trigger, is correct because Azure Pipelines can be started automatically by an external service calling the pipeline's webhook URL (e.g., via a Generic service connection or the `resources: webhooks:` YAML construct). Option C, the pull request trigger, is correct because the `pr:` YAML trigger (or branch policy build validation) automatically queues a pipeline run when a pull request is opened or updated against specified branches. Option E, the scheduled trigger, is correct because the `schedules:` YAML block or the classic editor's Scheduled trigger starts pipeline runs automatically at defined cron times. Option D, the manual trigger, is not correct because it requires a user to explicitly queue the run and therefore does not start the pipeline automatically.

Answer

Manual trigger

Question 3

You need to implement a build retention policy that automatically deletes old builds after 30 days, but keeps the latest 5 builds regardless of age. Which configuration should you use?

Accepted Answer

Set 'Days to keep builds' to 30 and 'Minimum number of builds to keep' to 5. In Azure Pipelines, the 'Days to keep builds' and 'Minimum number of builds to keep' settings work together to enforce a retention policy that deletes builds older than 30 days while ensuring that at least the latest 5 builds are retained, even if they exceed the age limit. This configuration directly matches the requirement to delete old builds after 30 days but keep the latest 5 builds regardless of age.

Answer

Set 'Number of days to keep runs' to 30 and 'Number of runs to keep' to 5

Answer

Set 'Maximum retention policy' to 30 days and 'Number of builds to retain' to 5

Answer

Set 'Number of days to keep artifacts' to 30 and 'Number of artifacts to keep' to 5

Question 4

Your organization uses Azure Pipelines to manage infrastructure as code with Terraform. The pipeline runs terraform plan and apply. You need to ensure that the state file is stored securely and can be locked to prevent concurrent modifications. What should you configure?

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

Accepted Answer

Set trigger: paths: include: - 'src/*'. Azure Pipelines path filters use glob patterns. The pattern '*' matches zero or more characters but does not match the slash '/', so 'src/*' only matches files directly in the 'src' folder, not files in subdirectories. To include all files under 'src' (including subfolders), you must use 'src/**'. The correct YAML would be: trigger: paths: include: - 'src/**'. Option A is not fully correct because it would miss changes in subfolders.

Answer

Set trigger: paths: exclude: - 'src/*'

Answer

Set trigger: branches: include: - main

Answer

Set trigger: batch: true

Question 5

Your company uses GitHub Actions to build and deploy a Python application. The workflow includes a job that runs on a self-hosted runner. You need to ensure that sensitive environment variables are not exposed in the workflow logs. What is the best approach?

Accepted Answer

Store secrets in GitHub repository secrets and reference them in the workflow.. GitHub repository secrets and environment secrets are both automatically masked in workflow logs when referenced via ${{ secrets.NAME }}. The best practice is to store sensitive variables in GitHub secrets and reference them in the workflow, rather than defining them directly in YAML or reading from a file. Option C correctly describes this approach.

Answer

Use a custom action to read secrets from a file.

Answer

Use GitHub environment secrets and mark the secret as sensitive to ensure it is masked in logs.

Answer

Define the variables directly in the workflow YAML.

Question 6

You are configuring a continuous integration trigger in Azure Pipelines for a repository in Azure Repos. You want to trigger a build for all branches except the 'release' branch. How should you configure the trigger?

Accepted Answer

Set trigger: branches: exclude: - release. In Azure Pipelines YAML triggers, the 'include' list is optional. If no include is specified, all branches are considered for triggering, and the 'exclude' list removes the specified branches. Therefore, 'trigger: branches: exclude: - release' correctly triggers on all branches except 'release'. The marked answer C also works, but D is the simpler and standard configuration.

Answer

Set trigger: branches: include: - main

Answer

Set trigger: branches: include: - '*' exclude: - '*'

Answer

Set trigger: branches: include: - '*' exclude: - release

Question 7

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 secrets referenced from repository or organization secrets in logs, but you must ensure secrets are stored as encrypted secrets (not plaintext) and referenced via the secrets context so masking applies. Using GitHub Actions secrets with masking prevents accidental exposure in build output. This is the native, supported mechanism for secret protection.

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 8

Which THREE components are required to implement a GitHub Actions self-hosted runner on a Windows virtual machine? (Choose three.)

Accepted Answer

GitHub Actions runner application installed on the VM. Option A is correct because the GitHub Actions runner application (the `actions/runner` package, typically configured via `config.cmd`) must be installed and run on the VM so it can poll GitHub for and execute workflow jobs. Option C is correct because the scenario explicitly specifies a Windows virtual machine, so a Windows operating system must be installed to host and run the runner service. Option B is not required because a runner can be registered using a runner registration token (or a GitHub App token) rather than a personal access token. Option D is not required because IIS is unrelated to the runner's operation and is not needed to execute Actions jobs. Option E is not required because Docker Desktop is only necessary if workflows specifically need containerized job execution, not for a basic self-hosted runner.

Answer

A personal access token (PAT) for registering the runner

Answer

IIS (Internet Information Services) running on the VM

Answer

Docker Desktop installed on the VM

Question 9

What is the most likely cause of this error?

Accepted Answer

The secret name in Key Vault does not match 'myKeyVaultSecret'. The question asks for the cause of an error but the error text is missing. Without the specific error message, none of the options (A, B, C, or D) can be definitively determined as correct. The marked answer C is only plausible if the error explicitly states that the secret is not found, but that is not provided. The stem must include the error message for the question to be valid.

Answer

The variable group is not linked to the Key Vault

Answer

The service connection does not have 'Get' permission on the Key Vault

Answer

Pipeline variables cannot reference Key Vault secrets

Question 10

You are designing a multi-stage YAML pipeline that deploys to multiple environments. You need to ensure that the pipeline can be triggered manually for a specific stage without running previous stages. Which feature should you use?

Accepted Answer

Use the 'Run pipeline' button with 'Stages to run' and set 'stagesToSkip' parameter. To manually run a specific stage in a multi-stage YAML pipeline, use the Run pipeline button and select the desired stage(s) from the 'Stages to run' dropdown in the UI. The 'stagesToSkip' parameter is not used in the UI; it is only applicable when triggering a run via the REST API. Therefore, Option A should be reworded to remove the reference to 'stagesToSkip'.

Answer

Use 'condition: always()' on the stage

Answer

Use 'dependsOn: []' to make the stage independent

Answer

Use 'trigger: none' at the stage level

Question 11

Which THREE are valid deployment strategies supported by Azure Pipelines and GitHub Actions? (Choose three.)

Accepted Answer

Blue-green. Blue-green (A) is valid because Azure Pipelines and GitHub Actions can implement it by deploying a parallel environment and switching traffic via slots, load balancer rules, or feature flags. Canary (B) is valid because both platforms support staged rollouts that route a small percentage of traffic to the new version before full promotion, typically using deployment jobs, environments, or release gates. Rolling (C) is valid because both CI/CD systems can update instances in batches through deployment jobs, matrix strategies, or orchestration scripts, replacing instances incrementally while maintaining availability. Immutable (D) and Recreate (E) are not among the three strategies asked for here; while they are recognized deployment patterns in some tools, they are not the options marked as supported by Azure Pipelines and GitHub Actions in this question.

Answer

Immutable

Answer

Recreate

Question 12

Refer to the exhibit. The pipeline will trigger when changes are pushed to which branches?

Accepted Answer

The main branch and any branch starting with 'release/'. The pipeline trigger configuration uses a YAML `trigger` block with `branches` and `include` clauses. The `include` list specifies that the pipeline triggers on pushes to the `main` branch and any branch matching the wildcard pattern `release/*`. This is why option B is correct: the pipeline triggers on both the main branch and all branches starting with 'release/'.

Answer

All branches

Answer

Only the main branch

Answer

Only branches starting with 'release/'

Question 13

Refer to the exhibit. You have a YAML pipeline with the variables shown. What will be the value of $(Build.BuildNumber) on the first run?

Accepted Answer

20250101.1. When a YAML pipeline uses the default '$(Date:yyyyMMdd)$(Rev:.r)' name format, the first run on a given day produces '20250101.1' — the date followed by revision 1. The Rev counter increments per run within the same day, so the first run is always '.1'. This is the built-in default Build.BuildNumber format unless overridden by a 'name:' property in the YAML.

Answer

1.0.0.0

Answer

1.0.0

Answer

1.0.1

Question 14

Which TWO actions should you take to ensure that a build pipeline fails if code coverage drops below 80%?

Accepted Answer

Add a script task that parses the coverage file and exits with non-zero if below threshold.. Only option B directly enforces the threshold by parsing coverage and exiting non-zero. Option C merely publishes results and does not enforce a threshold. Therefore the question as written cannot have two correct answers.

Answer

Use the PublishTestResults@2 task with the 'codeCoverage' option.

Answer

Use the PublishCodeCoverageResults@1 task to publish coverage data.

Answer

Use the ReportGenerator@5 task to create a coverage report.

Answer

Use the CopyFiles@2 task to move coverage files to a shared location.

Question 15

Your pipeline uses the DotNetCoreCLI task to build a .NET Core application. You need to ensure that the build produces a self-contained deployment (SCD) for a Linux target. Which argument should you pass to the 'arguments' input of the task?

Accepted Answer

--runtime linux-x64. The --runtime argument specifies the target runtime (linux-x64) and produces a self-contained deployment. Option A is wrong because --configuration specifies the build configuration, not the runtime. Option C is wrong because --output specifies the output directory, not the runtime. Option D is wrong because while --self-contained true is a valid argument, it does not specify the target runtime; to target Linux specifically, you must use --runtime linux-x64 (which implies self-contained) or combine --runtime with --self-contained true.

Answer

--configuration Release

Answer

--output $(Build.ArtifactStagingDirectory)

Answer

--self-contained true