AZ-400 Practice Test 35 — 15 Questions

Question 1

You have a YAML pipeline with multiple jobs that need to run in parallel. However, one job depends on artifacts produced by a previous job. How should you configure the dependency?

Accepted Answer

Set dependsOn on the dependent job and use PublishBuildArtifacts and DownloadBuildArtifacts tasks.. In Azure DevOps YAML pipelines, job dependencies are explicitly declared using the `dependsOn` keyword, and artifacts must be published and downloaded using `PublishBuildArtifacts` and `DownloadBuildArtifacts` tasks (or the `publish` and `download` pipeline decorators). Without explicit artifact sharing, outputs from one job are not automatically available to another job, even if `dependsOn` is set.

Answer

Use the 'dependsOn' keyword only, artifacts are automatically shared.

Answer

Set the 'condition' to 'eq(variables['Agent.JobStatus'], 'Succeeded')' on the dependent job.

Answer

Use the 'pool' keyword to ensure both jobs run on the same agent.

Question 2

Your team uses Azure Boards with a custom process. Which two features allow you to customize the work item types? (Choose two.)

Accepted Answer

Create an inherited process from the default process.. In Azure Boards, customization of work item types is only possible through an inherited process. You must create an inherited process from a default process (e.g., Agile, Scrum, CMMI) to enable any modifications. This ensures the default process remains unaltered and supports upgrade compatibility.

Answer

Configure rules to create new work item types.

Answer

Use team settings to define new work item types.

Answer

Modify the default process directly.

Question 3

Your team uses GitHub Flow and wants to ensure that every pull request is reviewed by at least one team member. Which branch protection rule should you enable?

Accepted Answer

Require a pull request before merging and set required number of reviewers to 1. GitHub Flow relies on pull requests for collaboration, and the 'Require a pull request before merging' rule with a required number of reviewers set to 1 enforces that every PR must be reviewed by at least one team member before it can be merged. This directly satisfies the requirement of ensuring code review for all changes.

Answer

Require signed commits

Answer

Require status checks to pass before merging

Answer

Require conversation resolution before merging

Question 4

You are designing a build pipeline for a Node.js application. The team wants to ensure that the pipeline runs unit tests and publishes test results to Azure DevOps. Which task should you add to the pipeline?

Accepted Answer

Publish Test Results task. The Publish Test Results task (A) is correct because it specifically ingests test result files (e.g., JUnit, NUnit, xUnit, or TRX formats) and publishes them to Azure DevOps, enabling test analytics, trend charts, and pass/fail reporting in the pipeline summary. For a Node.js application, after running unit tests with a framework like Jest or Mocha, the test results are typically output as JUnit XML files, and this task is required to make those results visible in the DevOps portal.

Answer

Copy Files task

Answer

npm test

Answer

Publish Build Artifacts task

Question 5

Your team uses GitHub and wants to automatically link pull requests to work items in Azure Boards. What should you configure?

Accepted Answer

Install the Azure Boards app for GitHub and configure the integration. The Azure Boards app for GitHub is the official integration that synchronizes work items with GitHub commits, branches, and pull requests. Once installed and configured, it automatically links pull requests to Azure Boards work items based on mention patterns (e.g., 'AB#123') in the PR description or commit messages, enabling traceability without custom scripting.

Answer

Add a repository secret with Azure Boards connection string

Answer

Configure branch protection rules to require a linked work item

Answer

Create a GitHub Actions workflow that posts comments to Azure Boards

Question 6

You are setting up a release pipeline that deploys to multiple environments (dev, test, prod) sequentially. Each environment requires approval before deployment. What is the best way to implement this in Azure Pipelines?

Accepted Answer

Define pipeline stages with environment resources and pre-deployment approvals.. Azure Pipelines supports multi-stage YAML pipelines where each stage can reference an environment resource. Pre-deployment approvals are configured on the environment itself, ensuring that before a stage deploys to that environment, the specified approvers must grant approval. This provides a native, auditable, and integrated approval gate without custom scripting or legacy tooling.

Answer

Use environment resources with 'auto' trigger and no approvals.

Answer

Use classic release pipelines with approval gates per environment.

Answer

Use a custom PowerShell script to pause and prompt for approval.

Question 7

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub Actions are not exposed in logs. A developer accidentally logs a secret using 'echo ${{ secrets.API_KEY }}' in a workflow step. What is the default behavior?

Accepted Answer

The secret value is masked with asterisks in the log output. GitHub Actions automatically masks secrets in workflow logs. When a secret is used in a step (e.g., via `${{ secrets.API_KEY }}`), GitHub replaces any occurrence of the secret's value in the log output with `***`. This redaction happens at runtime, so even if a developer accidentally echoes the secret, the log will show asterisks instead of the actual value.

Answer

The secret value is replaced with an empty string in the log

Answer

The workflow run fails with an error about secret exposure

Answer

The secret is redacted before the step runs, and the step fails if it tries to use the secret

Question 8

A development team is designing a build pipeline for a microservices application. They want to ensure that each service is built and tested independently, but they also need to run integration tests that span multiple services. What is the recommended approach?

Accepted Answer

Create individual build pipelines for each service, and a separate release pipeline that deploys all services to an integration environment for testing.. It aligns with microservices best practices: each service has its own build pipeline for independent compilation, unit testing, and artifact generation, while a separate release pipeline orchestrates deployment of all services to a shared integration environment for cross-service testing. This decouples build concerns from deployment concerns, enabling parallel development and faster feedback loops.

Answer

Use a single release pipeline that triggers manual deployment for each service.

Answer

Create a single build pipeline that builds all services together to ensure consistency.

Answer

Build each service separately, but skip integration tests to avoid complexity.

Question 9

You have a classic release pipeline that deploys to Azure App Service. You need to implement a canary deployment strategy where 10% of traffic is routed to the new version for 30 minutes before full rollout. What should you use?

Accepted Answer

Deploy to a staging slot and then use Azure CLI to update routing rules after deployment.. Canary deployment on Azure App Service is achieved by deploying to a deployment slot and then configuring routing rules to send a percentage of traffic to that slot. In a classic release pipeline, you can use the Azure App Service deploy task to deploy to a slot, followed by an Azure CLI task to set the traffic percentage (e.g., az webapp traffic-routing set). The 'Swap with preview' feature is for multi-phase swap validation, not for setting traffic percentages.

Answer

Configure multiple deployment slots and use Traffic Manager to distribute traffic.

Answer

Use the 'Azure App Service deploy' task with the 'Deploy to Slot' option, then manually adjust routing rules.

Answer

Use slot swap with 'Swap with preview' and set traffic percentage in the swap settings.

Question 10

Your team uses Azure Repos and wants to enforce that all commits to the release branch must be signed using GPG. Which branch policy should you enable?

Accepted Answer

Require signed commits. Azure Repos branch policies include a 'Require signed commits' setting that enforces GPG signature verification on all commits pushed to the branch. When enabled, any commit without a valid GPG signature is rejected, ensuring the integrity and authenticity of the commit author.

Answer

Limit merge types

Answer

Check for linked work items

Answer

Require a minimum number of reviewers

Question 11

Your team is migrating from TFVC to Git in Azure Repos. They want to preserve the history of all branches. Which migration tool should you use?

Accepted Answer

git-tfs tool. The git-tfs tool is specifically designed to migrate TFVC repositories to Git while preserving full branch history, including changesets, branch relationships, and merge history. It bridges the gap between TFVC and Git by converting TFVC changesets into Git commits and mapping TFVC branches to Git branches, making it the correct choice for this migration scenario.

Answer

GitHub Importer

Answer

Azure DevOps Migration Tools

Answer

git-svn

Question 12

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

Accepted Answer

Schedule trigger. A is correct because Azure Pipelines supports scheduled triggers via the `schedules` block in YAML (or the Triggers UI), which runs the pipeline on a cron-based timetable. B is correct because PR triggers (`pr:` in YAML) cause the pipeline to run when a pull request is opened or updated against specified branches, typically for validation builds. C is correct because CI triggers (`trigger:` in YAML) run the pipeline automatically whenever code is pushed to the included branches, which is the standard continuous integration mechanism. D is not a valid Azure Pipelines trigger; `on: push` is GitHub Actions syntax, not Azure Pipelines YAML. E is not a valid trigger type in Azure Pipelines; commits are picked up through CI triggers, not a separate 'commit trigger' construct.

Answer

'on: push' trigger in YAML

Answer

Commit trigger

Question 13

You need to trigger a pipeline whenever changes are pushed to the 'main' branch of a GitHub repository. Which trigger should you configure in the YAML pipeline?

Accepted Answer

trigger:
  branches:
    include:
    - main. The `trigger` keyword at the root of a YAML pipeline defines the CI trigger that automatically starts a pipeline run when changes are pushed to the specified branch. By including `main` under `branches.include`, the pipeline will trigger on any push to the `main` branch of the GitHub repository, which is the standard way to set up a CI trigger for a single branch.

Answer

pr:
  branches:
    include:
    - main

Answer

resources:
  repositories:
  - repository: self
    trigger:
      branches:
        include:
        - main

Answer

schedules:
- cron: "0 0 * * *"
  branches:
    include:
    - main

Question 14

Which TWO branch policies can be configured in Azure Repos to enforce code quality?

Accepted Answer

Status check. Status check (A) is correct because Azure Repos allows you to require that a status check passes before a pull request can be completed. This enforces code quality by integrating with external or built-in services (e.g., Azure Pipelines, SonarQube) that run automated tests, linting, or security scans. Build validation (C) is correct because it triggers a build pipeline automatically when a pull request is created, ensuring the code compiles and passes defined quality gates before merging.

Answer

Comment requirements

Answer

Work item linking

Answer

Merge strategy

Question 15

Your organization uses Azure DevOps and Microsoft Entra ID. The compliance team needs to ensure that access to Azure DevOps projects is governed by conditional access policies. Which Azure DevOps integration should you use?

Accepted Answer

Link the Azure DevOps organization to the Microsoft Entra ID tenant and configure conditional access policies in Microsoft Entra ID.. To govern access to Azure DevOps projects with conditional access policies, you must link the Azure DevOps organization to the Microsoft Entra ID tenant. This integration makes Azure DevOps a registered application within the tenant, allowing conditional access policies (e.g., MFA, device compliance, location-based access) to be evaluated during authentication. Only then can the compliance team enforce organization-wide access rules via Microsoft Entra ID.

Answer

Configure service hooks to enforce conditional access.

Answer

Assign managed identities to users for conditional access.

Answer

Use OAuth tokens to authenticate users.