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

Question 1

Refer to the exhibit. This multi-stage YAML pipeline has a variable 'publishEnabled' set to false. The team wants the Publish stage to run only when 'publishEnabled' is true. However, the Publish stage never runs, even when the variable is changed to true at queue time. What is the most likely cause?

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

Accepted Answer

The variable 'publishEnabled' is not settable at queue time; it is a compile-time variable.. In Azure DevOps YAML pipelines, variables set at the pipeline level (not in a variable group or at queue time) are evaluated at compile time, not at runtime. When 'publishEnabled' is defined as a simple variable in the YAML file, changing it at queue time does not affect the compiled pipeline stages; the condition is evaluated against the compile-time value (false), so the Publish stage never runs. To make it settable at queue time, the variable must be defined as a runtime parameter, or explicitly defined in the pipeline UI with the 'Let users override this value when running this pipeline' checkbox enabled.

Answer

The condition syntax is wrong; it should use 'eq(variables.publishEnabled, true)'.

Answer

The Publish stage is missing 'dependsOn: Build'.

Answer

The 'dependsOn' syntax is incorrect; it should be 'dependsOn: Build'.

Question 2

You are designing a release pipeline for a critical production application. The pipeline must ensure that changes are deployed to a staging environment first, and if integration tests pass, they are automatically deployed to production. However, if the tests fail, the deployment to production must be blocked. What is the best approach?

Accepted Answer

Create a multi-stage YAML pipeline with a gate on the production stage that evaluates test results from the staging stage.. A multi-stage YAML pipeline with a gate on the production stage allows you to evaluate the results of integration tests run in the staging stage before proceeding to production. The gate can be configured to check for test pass/fail status from the staging stage, blocking the production deployment if tests fail. This approach provides a clear, automated approval flow within a single pipeline definition, aligning with the requirement for conditional promotion based on test results.

Answer

Create a single stage in the pipeline with conditional tasks to deploy to staging and then to production based on test results.

Answer

Create two separate pipelines: one for staging and one for production. Use a pipeline trigger to run the production pipeline after staging completes.

Answer

Use a classic release pipeline with pre-deployment approvals on the production stage.

Question 3

Which TWO features in Azure Pipelines allow you to enforce separation of duties between development and operations teams? (Choose two.)

Accepted Answer

Approvals and checks on environments. Approvals and checks on environments (B) enforce separation of duties by requiring designated approvers (e.g., operations team members) to approve a deployment before it proceeds, ensuring that development cannot directly push to production. Environment security roles (D) allow you to define who can create, view, or manage environments, restricting developers from modifying production environments without operations oversight.

Answer

Pipeline decorators

Answer

Service connections with different scopes

Answer

Branch policies on the main branch

Question 4

Your build pipeline includes a task that runs unit tests. You want to ensure that if any test fails, the pipeline stops immediately and does not proceed to the next tasks. What should you configure in the pipeline?

Accepted Answer

Set the 'Continue on error' option to false for the test task.. To stop the pipeline immediately when a test task fails, you must ensure that the task's 'Continue on error' option is false (unchecked). This is the task control option that determines whether a task failure is ignored. When 'Continue on error' is false, a failed task causes the pipeline to stop and subsequent tasks with the default run condition ('Only when all previous tasks have succeeded') will not run. Setting 'Run this task' to 'Only when all previous tasks have succeeded' is the default and only controls whether the test task runs based on prior task results; it does not directly affect what happens after the test task fails. Therefore, option A is the correct configuration.

Answer

Add a custom condition to the test task to only run if previous tasks succeeded.

Answer

Set the 'Always run' option for the test task.

Answer

Ensure the task control option 'Run this task' is set to 'Only when all previous tasks have succeeded'.

Question 5

Refer to the exhibit. The YAML pipeline triggers on commits to main and develop branches, and pull requests targeting develop. A developer pushes a commit directly to main. What will happen?

Accepted Answer

The pipeline runs once for the CI trigger.. The pipeline is configured with a CI trigger for both main and develop branches, and a PR trigger only for pull requests targeting develop. When a developer pushes a commit directly to main, the CI trigger fires because the push matches the main branch, causing the pipeline to run once. The PR trigger does not activate because there is no pull request involved.

Answer

The pipeline does not run because the PR trigger requires a pull request.

Answer

The pipeline runs twice: once for the CI trigger and once for the PR trigger.

Answer

The pipeline runs once for the PR trigger only.

Question 6

Which THREE are valid approaches to securely store secrets used in Azure Pipelines? (Choose three.)

Accepted Answer

Secret variables defined in the pipeline UI. Secret variables defined in the pipeline UI (B) are encrypted at rest and masked in logs, preventing exposure in source control. The Azure Key Vault task (C) retrieves secrets from Azure Key Vault at runtime, avoiding storage in Azure DevOps. Variable groups linked to Azure Key Vault (D) allow you to reference Key Vault secrets directly as pipeline variables, keeping them out of YAML and providing centralized access control. All three approaches ensure secrets are not stored in plaintext in repositories or pipeline definitions.

Answer

Inline secret variables defined in the YAML file

Answer

Environment variables set on the build agent

Question 7

Refer to the exhibit. This is a deployment job definition in a multi-stage YAML pipeline. The deployment fails because the Kubernetes service connection 'aks-prod' cannot be found. What is the most likely cause?

Accepted Answer

The service connection 'aks-prod' does not exist in the Azure DevOps project.. The error message explicitly states that the Kubernetes service connection 'aks-prod' cannot be found. In Azure DevOps, a service connection is a stored credential set that must exist in the project before it can be referenced in a YAML pipeline. If the connection name is misspelled, deleted, or never created, the pipeline will fail at the deployment job stage regardless of other configurations.

Answer

The approval for production environment is blocking the deployment.

Answer

The agent pool does not have access to the AKS cluster.

Answer

The namespace 'prod' does not exist in the AKS cluster.

Question 8

You have a multi-stage pipeline that deploys to multiple regions. You want to ensure that if the deployment to one region fails, the pipeline does not proceed to the next region. What is the best way to implement this?

Accepted Answer

Define stage dependencies with 'dependsOn' and set 'condition' to 'succeeded()'.. Azure Pipelines allows you to define stage dependencies using 'dependsOn' and control execution flow with 'condition'. By setting each region deployment as a separate stage that depends on the previous region's stage succeeding (condition: 'succeeded()'), the pipeline will automatically halt if any region deployment fails, preventing progression to subsequent regions.

Answer

Use pipeline decorators to inject error handling steps.

Answer

Add a manual approval between regions.

Answer

Configure each region deployment as a separate stage with no dependencies.

Question 9

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets are not exposed in build logs. What should you use?

Accepted Answer

GitHub Secrets. GitHub Secrets (Option C) is the correct choice because GitHub Actions provides a built-in encrypted secrets store that automatically masks secret values in build logs. When you reference a secret using `${{ secrets.MY_SECRET }}`, GitHub ensures the value is never printed or exposed in workflow output, unlike plaintext or environment variables that can be inadvertently logged.

Answer

Hardcoded values in the workflow YAML

Answer

Environment variables in the workflow

Answer

Artifact storage

Question 10

Refer to the exhibit. An Azure CLI command outputs the configuration of an Azure Web App. Your pipeline deploys to this Web App using the 'AzureWebApp@1' task. The deployment fails with an error indicating that the runtime stack is not supported. What is the most likely cause?

Accepted Answer

The runtime stack (DOTNETCORE|6.0) is not compatible with the deployed application.. The error 'runtime stack is not supported' indicates that the Azure Web App's configured runtime stack (DOTNETCORE|6.0) does not match the application being deployed. The AzureWebApp@1 task uses the Web App's stack setting to determine how to deploy and run the code; if the deployed app requires a different runtime (e.g., .NET 8.0 or a non-.NET framework), the deployment fails. Option C correctly identifies this mismatch as the root cause.

Answer

The Web App is not a Linux app.

Answer

The ASPNETCORE_ENVIRONMENT setting is incorrect.

Answer

The resource group name is incorrect.

Question 11

Which THREE are valid ways to trigger a pipeline in Azure Pipelines using GitHub integration? (Choose three.)

Accepted Answer

GitHub App webhooks. GitHub App webhooks are the primary integration mechanism for Azure Pipelines with GitHub. When you configure a GitHub App connection in Azure Pipelines, it registers webhooks that listen for specific GitHub events (like push and pull request) and automatically triggers pipeline runs in real-time without polling.

Answer

Polling GitHub on a schedule

Answer

Azure Pipelines schedule trigger

Question 12

You need to automatically run a pipeline when a new tag is pushed to the repository. Which trigger configuration should you use?

Accepted Answer

Tags trigger. Tags trigger allows running pipelines when a tag is pushed or updated. Option B (Schedule trigger) is incorrect because it runs on a predefined schedule, not on tag events. Option C (PR trigger) is incorrect because it triggers on pull request actions, not on tags. Option D (CI trigger with branch filters) is incorrect because CI trigger monitors branches, not tags; even with branch filters it does not respond to tags.

Answer

Schedule trigger

Answer

PR trigger

Answer

CI trigger with branch filters

Question 13

Refer to the exhibit. The pipeline YAML includes an Azure CLI script that sets an app setting on a Web App. The pipeline fails with an authentication error. What is the most likely cause?

Accepted Answer

The pipeline does not have an Azure service connection configured for authentication.. The Azure CLI script in the pipeline attempts to run `az webapp config appsettings set`, which requires authentication to Azure. Without an Azure service connection configured in the pipeline, there is no authenticated session or service principal to authorize the command, resulting in an authentication error. The service connection provides the necessary credentials (e.g., via Azure AD) for the pipeline to interact with Azure resources.

Answer

The resource group name is incorrect.

Answer

The DEPLOYMENT_SLOT setting name is invalid.

Answer

The script syntax is invalid.

Question 14

Which THREE are valid security best practices for Azure Pipelines? (Choose three.)

Accepted Answer

Restrict agent pool permissions to only necessary users. Restricting agent pool permissions to only necessary users follows the principle of least privilege, reducing the attack surface by ensuring only authorized personnel can register, manage, or use build agents. This prevents unauthorized access that could lead to code injection or credential theft.

Answer

Store secrets as plain text in YAML files

Answer

Run build agents on domain controllers

Question 15

Your team uses GitHub Actions for CI/CD. You need to enforce that all pull requests to the main branch pass a required status check that runs a security scan. The security scan is a GitHub Action that runs on pull_request events. However, the status check is not appearing as required in the branch protection rules. What should you do?

Accepted Answer

Ensure the workflow has a name that matches the status check name in the branch protection rule.. GitHub branch protection rules require the status check name to exactly match the workflow name (or the job name within the workflow) as it appears in the GitHub Actions UI. If the names do not match, the check will not appear as an option in the required status checks list. The security scan action runs on pull_request events, so the status check is generated, but the mismatch prevents it from being selectable as a required check.

Answer

Add 'types: [opened, synchronize]' to the pull_request trigger.

Answer

Change the trigger from 'pull_request' to 'pull_request_target'.

Answer

Use a GitHub App instead of the default GITHUB_TOKEN for the action.