AZ-400 Practice Test 14 — 15 Questions

Question 1

You are designing a security compliance plan for a GitHub Enterprise environment. Which THREE practices should you implement? (Select THREE.)

Accepted Answer

Configure branch protection rules to require pull request reviews. Branch protection rules with required pull request reviews enforce mandatory code review before merging, Dependabot alerts automatically monitor dependency vulnerabilities, and secret scanning detects accidental credential commits. Together these practices strengthen security compliance in GitHub Enterprise.

Answer

Disable two-factor authentication for automation accounts

Answer

Allow repository admins to bypass branch protection rules

Question 2

Your release pipeline deploys to multiple environments sequentially: Dev, QA, Staging, Production. You need to implement manual approval gates before Staging and Production deployments. Which TWO configurations should you use? (Choose two.)

Accepted Answer

Use the 'Approvals and gates' settings in the release pipeline stage.. The 'Approvals and gates' settings in a release pipeline stage allow you to configure pre-deployment approvals, which require designated users to approve the deployment before it proceeds. This is the standard mechanism in Azure DevOps for implementing manual approval gates. Option E is correct because adding a pre-deployment approval gate specifically to the Staging and Production stages ensures that deployments to these environments are blocked until the required approvals are granted, meeting the requirement for manual approval before Staging and Production.

Answer

Add a post-deployment approval gate to the Dev and QA stages.

Answer

Configure branch policy on the release branch to require approvals.

Answer

Add a 'Manual Validation' task in the YAML pipeline.

Question 3

The pipeline above fails with: 'The deployment job 'DeployToProd' references environment 'Production' which does not exist.' What should you do to resolve this error?

Accepted Answer

Create an environment named 'Production' in Azure DevOps project settings.. The error indicates that the Azure DevOps pipeline references an environment named 'Production' that does not exist in the project. Environments must be explicitly created in Azure DevOps project settings before they can be used in deployment jobs. Option D resolves this by creating the required environment, allowing the deployment job to target it correctly.

Answer

Remove the 'environment' property from the deployment job.

Answer

Change the deployment strategy from 'runOnce' to 'rolling'.

Answer

Add a script step before the deployment job to create the environment.

Question 4

Which TWO are valid strategies for managing secrets in a GitHub Actions workflow?

Accepted Answer

Use OpenID Connect to authenticate to Azure without storing any credentials.. OpenID Connect (OIDC) allows GitHub Actions to exchange a short-lived token directly with Azure without storing any long-lived credentials as secrets. This eliminates the need to manage and rotate client secrets or service principal passwords, reducing the risk of credential leakage. The workflow uses the `azure/login` action with `client-id`, `tenant-id`, and `subscription-id` parameters, and Azure trusts the OIDC token issued by GitHub. Alternatively, storing the secret as an encrypted GitHub secret is also a valid strategy: GitHub encrypts secrets at rest and injects them into the workflow runtime only when referenced via `${{ secrets.SECRET_NAME }}`. This prevents hardcoding secrets in the YAML and keeps them out of logs, though it still requires managing the secret value and rotation.

Answer

Hardcode the secret in the YAML file.

Answer

Set the secret as an environment variable in the runner's shell profile.

Answer

Base64-encode the secret and include it directly in the workflow file.

Question 5

A team is implementing a release pipeline for a Node.js application. They want to run integration tests against a temporary environment that is destroyed after the tests complete. Which strategy should they use?

Accepted Answer

Use a release pipeline that deploys to a new Azure App Service instance, runs tests, and then removes the instance.. It provisions a dedicated, isolated Azure App Service instance for integration testing, runs the tests against the real environment, and then destroys the instance to avoid ongoing costs. This aligns with the ephemeral environment pattern, ensuring tests validate actual deployment behavior without contaminating shared resources.

Answer

Use a separate release pipeline that deploys to a production environment for testing.

Answer

Use a single release pipeline that deploys to a staging slot and runs tests on the slot.

Answer

Run integration tests in the build pipeline using a mock environment.

Question 6

You need to integrate security scanning into your build pipeline to detect vulnerable open-source dependencies. Which Azure DevOps extension should you use?

Accepted Answer

WhiteSource Bolt. WhiteSource Bolt is a free Azure DevOps extension that integrates directly into build pipelines to automatically scan open-source dependencies for known vulnerabilities. It identifies vulnerable components, provides remediation guidance, and enforces security policies without requiring additional configuration or external tools, making it the correct choice for this scenario.

Answer

Azure Policy

Answer

GitHub Advanced Security

Answer

SonarQube

Question 7

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 8

Which THREE of the following are valid deployment strategies that can be implemented using Azure DevOps release pipelines? (Select THREE.)

Accepted Answer

Rolling deployment.. Rolling deployment is a valid strategy in Azure DevOps release pipelines, where instances of the previous version are gradually replaced with the new version, typically by updating a subset of instances (e.g., in a virtual machine scale set or Kubernetes cluster) while the rest continue serving traffic. Blue-green deployment is also valid, maintaining two identical environments and switching all traffic from the blue (old) to the green (new) environment after validation, often implemented using deployment slots or Kubernetes namespaces. Canary deployment is a third valid strategy, where a small percentage of traffic is routed to the new version initially, gradually increasing it while monitoring health, commonly implemented with deployment slots or progressive exposure in Kubernetes. Red-black, while sometimes used as a synonym for blue-green, is not a distinct deployment strategy recognized in Azure DevOps documentation, and linear deployment is not a recognized industry-standard pattern.

Answer

Red-black deployment.

Answer

Linear deployment.

Question 9

Drag and drop the steps to set up a self-hosted Azure DevOps agent on a Windows VM into the correct order.

Accepted Answer

First create a PAT, then download the agent, then run config.cmd to configure and register, then start the agent as a service.. The correct order to set up a self-hosted Azure DevOps agent on a Windows VM is: create a Personal Access Token (PAT) first, then download the agent package, then run config.cmd to configure and register the agent with Azure DevOps, and finally start the agent as a service. Option A reflects this sequence correctly. Other options either place download before PAT creation or start the agent before configuration, which would fail.

Answer

First download the agent, then create a PAT, then run config.cmd, then start the agent as a service.

Answer

First create a PAT, then run config.cmd, then download the agent, then start the agent as a service.

Answer

First create a PAT, then download the agent, then start the agent as a service, then run config.cmd.

Question 10

Which THREE are true about using deployment groups in Azure Pipelines? (Choose 3)

Accepted Answer

Each machine in a deployment group must have the Azure Pipelines agent installed.. Each target machine in a deployment group requires the Azure Pipelines agent (either the Windows or Linux agent) to be installed and configured. The agent is responsible for executing the deployment tasks on that machine, and without it, the deployment group cannot communicate with or deploy to the machine.

Answer

Deployment groups can only be used with Windows-based machines.

Answer

Deployment groups are tied to a specific environment.

Question 11

Your team uses Azure Repos and needs to prevent secrets from being committed to the repository. Which built-in feature should you enable?

Accepted Answer

Enable push protection in Azure Repos. Push protection in Azure Repos is a built-in feature that scans commits for high-confidence secrets (e.g., Azure service connection strings, SSH keys, and other credential patterns) and blocks the push if a secret is detected. This prevents secrets from ever reaching the remote repository, enforcing security at the server side without requiring client-side configuration.

Answer

Enable GitHub secret scanning

Answer

Enable Azure Policy to scan repositories

Answer

Configure a pre-commit hook with a secret scanning tool

Question 12

You are configuring a continuous integration (CI) trigger for your YAML pipeline. The trigger should run the pipeline when changes are pushed to the 'main' branch or any release branch matching 'release/*'. Which TWO trigger configurations are valid? (Choose two.)

Accepted Answer

trigger:
  branches:
    include:
      - main. The `trigger` section with `branches: include: - main` explicitly specifies that the pipeline should run on pushes to the `main` branch. Option E is correct because `trigger: branches: include: - release/*` uses the wildcard pattern `release/*` to include all branches matching that pattern, such as `release/v1.0` or `release/2.0`. Both configurations are valid YAML trigger definitions for Azure Pipelines.

Answer

trigger:
  branches:
    exclude:
      - main

Answer

branches:
  include:
    - main

Answer

trigger:
  branches:
    main

Question 13

Which TWO options are valid ways to communicate build status from Azure Pipelines to external stakeholders?

Accepted Answer

Configure a Service Hook to post to a Slack channel.. Service Hooks in Azure Pipelines allow integration with external services like Slack by triggering HTTP POST requests containing build status payloads. Additionally, Azure Pipelines provides built-in email notifications for specific events, such as build completion or failure, which can be configured to send status updates to stakeholders. Both are standard, officially supported features. Options like using a release pipeline to call Twilio are possible but are not standard built-in methods, so they are not considered 'valid ways' in this context.

Answer

Create a work item in Azure Boards for each build.

Answer

Export pipeline logs to Power BI for reporting.

Answer

Use a release pipeline to send SMS via Twilio.

Question 14

Your release pipeline deploys to multiple Azure regions. You need to ensure that if a deployment to one region fails, the pipeline continues deploying to other regions. Which deployment strategy should you use?

Accepted Answer

Rolling deployment. Rolling deployment updates instances gradually across regions. If a deployment to one region fails, the pipeline can continue deploying to other regions because each region is updated independently. Option A (immutable deployment) replaces all instances at once, so a failure would halt the entire deployment. Option C (blue-green) switches all traffic to a new environment; if that environment fails, the whole deployment fails. Option D (canary) routes a small percentage of traffic to a new version and rolls back if issues occur, but it does not ensure continued deployment to other regions upon failure.

Answer

Immutable deployment

Answer

Blue-green deployment

Answer

Canary deployment

Question 15

You have a multi-stage YAML pipeline with stages: Build, Test, and Deploy. The Deploy stage requires approval from a specific user group. You want to ensure that the approval request is sent only after the Test stage completes successfully. Which configuration should you use?

Accepted Answer

Define an environment with required approvers and reference it in the Deploy stage.. Azure Pipelines environments allow you to define required approvers (user groups) that must approve a deployment before it proceeds. By referencing the environment in the Deploy stage, the approval request is automatically triggered only after the preceding Test stage completes successfully, since stages execute sequentially by default.

Answer

Add a manual validation task in the Deploy stage.

Answer

Use the 'condition' keyword: condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')

Answer

Configure branch policies on the main branch.