AZ-400 Practice Test 43 — 15 Questions

Question 1

Your team uses Azure Boards to manage work items. They want to automatically update the status of a work item to 'Resolved' when a pull request that contains the work item ID is merged. Which feature should you configure?

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

Accepted Answer

Enable the 'Automatically update work item status' setting in the repository's pull request configuration.. Azure Repos provides a setting in the repository's pull request configuration to automatically update linked work items to a specified state (e.g., 'Resolved') when a pull request is merged. This setting automatically updates work items that are linked via the work item ID in the pull request description. Option B is incorrect because it requires manual effort, which is not automatic. Option C is incorrect because branch policies for linked work items only enforce linking, not automatic status updates. Option D is incorrect because although service hooks can be used to call REST APIs, Azure DevOps already provides a built-in mechanism for this scenario, making it unnecessary to create custom hooks.

Answer

Instruct developers to manually update the work item after merging.

Answer

Set up a branch policy that requires linked work items.

Answer

Create a service hook to call Azure DevOps REST API on pull request merge.

Question 2

Your organization must comply with SOC 2 requirements. You are using Azure DevOps and need to ensure that all pipeline runs are logged and that logs are retained for at least one year. Which configuration should you implement?

Accepted Answer

Enable audit streaming to a Log Analytics workspace and set retention to 365 days.. SOC 2 requires audit logging and retention of pipeline execution history for at least one year. Azure DevOps audit streaming sends all audit events (including pipeline runs) to a Log Analytics workspace, where you can set a retention policy of 365 days. This satisfies both the logging and retention requirements without relying on pipeline-level retention settings that only cover build artifacts and logs, not audit events.

Answer

Increase the retention period of pipeline logs in the Azure DevOps UI.

Answer

Configure diagnostic settings for the Azure DevOps organization.

Answer

Disable the option to delete pipelines.

Question 3

A multinational company uses Azure DevOps with a single project. The project has multiple teams in different time zones. They want to customize the process to reflect different working days for each team. What is the recommended approach?

Accepted Answer

Use the same process and configure working days in the team settings for each team.. Azure DevOps allows each team to have its own working days configured in team settings, independent of the process template. This enables teams in different time zones to define their own non-working days without modifying the shared process, which would affect all teams using that process.

Answer

Create a custom process for each time zone and assign teams accordingly.

Answer

Use the same process but create separate areas for each team, then configure working days per area path.

Answer

Use the same process and configure capacity planning for each team to account for time off.

Question 4

Your team uses a monorepo in Azure Repos. Developers frequently commit directly to the main branch, causing build failures. You need to enforce a policy that requires all changes to go through pull requests with at least one reviewer. What should you configure?

Accepted Answer

Configure a branch policy on the main branch to require a minimum number of reviewers.. Azure Repos allows you to configure branch policies on specific branches (like main) to enforce that all changes must come through pull requests and require a minimum number of reviewers. This directly addresses the need to prevent direct commits to main and ensure code review before merging.

Answer

Configure a repository policy to require a pull request for all branches.

Answer

Create a service hook to reject commits to main that are not from pull requests.

Answer

Enable the 'Require a minimum number of reviewers' setting in the project settings.

Question 5

Your company has multiple teams working on a monorepo in Azure Repos. You need to enforce that changes to the /src/api folder require approval from the API team, while changes to /src/web require approval from the Web team. Which branch policy feature should you use?

Accepted Answer

Path filters in branch policy. Path filters in branch policy allow you to define conditions that trigger specific policy requirements based on the files changed in a pull request. By configuring a path filter for /src/api, you can require approval from the API team only when files in that folder are modified, and a separate path filter for /src/web can require approval from the Web team. This ensures that each team's approval is enforced only for their respective code areas within the monorepo.

Answer

Require a minimum number of reviewers

Answer

Automatically include code reviewers

Answer

Use separate repositories for each team

Question 6

A development team is using Git for source control. They have a main branch that should always be deployable. Developers work on feature branches and create pull requests to merge into main. Recently, a feature branch with incomplete work was accidentally merged into main, causing build failures. What is the best Git branch strategy to prevent this in the future while maintaining fast feedback?

Accepted Answer

Configure branch protection on main to require status checks (CI build and tests) to pass before merging.. Configuring branch protection on main to require status checks (CI build and tests) to pass before merging directly prevents incomplete or broken code from being merged. This enforces that every pull request must pass automated validation, ensuring main remains deployable while still allowing fast feedback through the CI pipeline.

Answer

Require at least one code reviewer approval for all pull requests into main.

Answer

Adopt a GitFlow-like branching model with a separate release branch for stable code.

Answer

Disable direct pushes to main and enforce all merges through pull requests.

Answer

Require a linear history on main by enabling 'Rebase and merge' for all pull requests.

Question 7

You are configuring a release pipeline that deploys to multiple environments (dev, test, prod). You want to ensure that the same build artifact is deployed to each environment without rebuilding. Which type of trigger should you use for the release pipeline?

Accepted Answer

Build completion trigger. A build completion trigger ensures that the release pipeline is initiated only after a specific build pipeline completes, allowing the same build artifact to be deployed across multiple environments without rebuilding. This trigger is ideal for multi-environment release pipelines where consistency of the artifact is critical, as it decouples the build from the release and promotes the identical binary through dev, test, and prod.

Answer

Pull request trigger

Answer

Continuous integration (CI) trigger

Answer

Scheduled trigger

Question 8

Your team uses Azure DevOps and wants to automate the creation of work items when a build pipeline fails. The work item should be assigned to the last person who committed a change in the failed build. Which approach should you use?

Accepted Answer

Add the 'Create work item on failure' task to the build pipeline.. The 'Create work item on failure' task in Azure DevOps build pipelines automatically creates a bug work item and assigns it to the last committer of the failed build. Option A is incorrect because release pipelines are meant for deployment, not build-time tasks. Option C is incorrect because while Service Hooks can trigger on build failure, they require additional custom logic to assign the work item to the last committer, making it less straightforward. Option D is incorrect because using a PowerShell script to call the REST API is more complex and error-prone compared to the built-in task.

Answer

Create a release pipeline that triggers on build failure and creates a work item.

Answer

Configure a Service Hook to create a work item on build failure.

Answer

Use a PowerShell script in the pipeline to call Azure DevOps REST API.

Question 9

Which TWO of the following are valid ways to trigger a release pipeline in Azure DevOps? (Select TWO.)

Accepted Answer

Continuous deployment trigger after a build completes.. Azure DevOps release pipelines can be triggered in multiple ways. A continuous deployment trigger (A) automatically creates a release whenever a build artifact is successfully produced. A scheduled release trigger (E) creates a release at a defined time (e.g., nightly). Manual release creation via the 'Create release' button (C) is a manual action, not an automated configured trigger. Pull request triggers (D) are valid only for build pipelines, not release pipelines. 'Source version trigger' (B) is not a standard release trigger type. Therefore, the two valid trigger types are A and E.

Answer

Source version trigger.

Answer

Manual trigger via the 'Create release' button.

Answer

Pull request trigger.

Question 10

You have an Azure DevOps pipeline that deploys a web app to Azure App Service. You want to capture deployment frequency and change failure rate as metrics in Application Insights. Which built-in analytics view should you use?

Accepted Answer

Application Dashboard. The Application Dashboard in Application Insights is a built-in analytics view that provides a customizable overview of your application's metrics. While it does not natively display deployment frequency or change failure rate, you can configure it with metric tiles to show these values if telemetry is properly instrumented. Option A is incorrect because 'Deployment Frequency' is a report in Azure DevOps Analytics, not a built-in view in Application Insights.

Answer

Deployment Frequency

Answer

Time to Restore Service

Answer

Azure DevOps Pipeline Telemetry

Question 11

You need to deploy a web app to Azure App Service using Azure Pipelines. The deployment slot should be 'staging' first, and after smoke tests, swap to production. Which deployment strategy should you use?

Accepted Answer

Blue-green deployment. Blue-green deployment is a release strategy that uses two identical environments (blue and green). The new version is deployed to the staging slot (green), smoke tests are run, and traffic is switched to the staging slot by swapping it with the production slot (blue). Slot swap is the Azure App Service mechanism used to implement blue-green deployment, but the strategy itself is blue-green.

Answer

Slot swap

Answer

Canary deployment

Answer

Rolling update

Question 12

Your build pipeline runs on a self-hosted agent pool. You need to ensure that only authorized pipelines can use these agents. Which security measure should you implement?

Accepted Answer

Set permissions on the agent pool. Agent pool permissions allow restricting which pipelines can use the agents, ensuring only authorized pipelines can access the self-hosted agents. Option B (agent tokens) is for registering agents, not for authorizing pipelines. Option C (variable groups) is for storing variables and secrets, not for agent access control. Option D (agent queues) is a legacy concept that does not provide granular pipeline-level permissions.

Answer

Use agent tokens

Answer

Use variable groups

Answer

Configure agent queues

Question 13

You are building a comprehensive instrumentation strategy for a large-scale Azure DevOps environment. You need to ensure that all pipeline events (build, release, test) are automatically tracked and correlated with application performance data. Which THREE components should you include?

Accepted Answer

A shared Correlation ID that flows from pipeline to application.. Options A, C, and E are correct. A shared Correlation ID (A) flows from pipeline to application, enabling end-to-end trace correlation. Custom pipeline tasks (C) send telemetry (e.g., build/release events) to Application Insights. The OpenTelemetry SDK (E) emits trace context from the application, which can include the correlation ID. Option B is wrong because Azure Monitor Workbooks are visualization tools, not data collection components. Option D is wrong because Azure Boards is for work item tracking, not pipeline event capture.

Answer

Azure Monitor Workbooks to visualize pipeline data.

Answer

Azure Boards to track pipeline run metadata.

Question 14

Your organization uses Azure Pipelines with multiple release stages. You need to instrument the pipeline to capture the duration of each stage and the number of failed tasks. Which TWO approaches should you use?

Accepted Answer

Use the Azure DevOps REST API to retrieve pipeline run statistics after each run.. Options D and E are correct. The goal is to capture stage duration and failed task counts. Option D uses the Azure DevOps REST API to programmatically retrieve pipeline run statistics, which includes stage-level durations and failure information. Option E adds a script task at the end of each stage that logs the stage's duration and task results to a custom log file, providing direct instrumentation. Option A is incorrect because pipeline notifications only alert on failures, they don't capture or log durations. Option B is incorrect because 'runOnce' is a deployment strategy that ensures sequential stages, not an instrumentation method. Option C is incorrect because the 'Summary' tab in the pipeline run provides a high-level overview, not detailed per-stage duration data that can be programmatically captured.

Answer

Configure pipeline notifications for failed tasks.

Answer

Implement a 'runOnce' deployment strategy to ensure sequential stages.

Answer

Enable the 'Summary' tab in the pipeline run to view stage durations.

Question 15

Your team is adopting Infrastructure as Code (IaC) using Bicep. You need to validate the Bicep file syntax and run pre-deployment checks as part of the build pipeline. Which task should you use?

Accepted Answer

Azure CLI task with 'az bicep build'. The `az bicep build` command compiles a Bicep file into an ARM template and performs syntax validation, making it the correct choice for validating Bicep syntax and running pre-deployment checks in a build pipeline. This task ensures that the Bicep code is syntactically correct before any deployment attempt, aligning with Infrastructure as Code (IaC) best practices.

Answer

Azure Resource Group Deployment task

Answer

Terraform task

Answer

PowerShell task with Invoke-RestMethod