Courseiva

CCNA Configure processes and communications Questions

75 of 95 questions · Page 1/2 · Configure processes and communications · Answers revealed

Practice these questionsDomain overviewAll questions
1
Multi-Selectmedium

Which TWO actions should you take to ensure that your Azure DevOps pipeline securely manages secrets?

Select 2 answers
A.Use Azure Key Vault variable groups
B.Enable 'Allow scripts to access the system token' and print secrets in logs for debugging
C.Store secrets directly in the YAML pipeline file
D.Use secret variables set in the pipeline UI or variable groups
E.Store secrets as plain text in the repository
AnswersA, D

Azure Key Vault variable groups securely store secrets in Azure Key Vault and link them to pipelines via variable group metadata, enabling pipelines to fetch secrets at runtime without writing them into YAML or repository files; access is governed by Azure RBAC and Key Vault access policies.

Why this answer

Option A is correct because linking an Azure Key Vault to a variable group lets the pipeline fetch secrets at runtime from Key Vault, so the secret values are never stored in the pipeline definition and access is governed by Key Vault access policies or RBAC. Option D is correct because secret variables defined in the pipeline UI or in variable groups are encrypted at rest by Azure DevOps, masked in logs, and not exposed in the YAML source, which is the supported way to hold secrets the pipeline needs directly. Option B is wrong because enabling scripts to access the system token and printing secrets to logs deliberately exposes credentials, defeating masking and enabling token theft.

Option C is wrong because secrets committed in the YAML pipeline file are stored in source control in plain text and visible to anyone with repo access. Option E is wrong because storing secrets as plain text in the repository exposes them to all readers of the repo and to its history, with no encryption or masking.

Exam trap

AZ-400 often tests the temptation to 'debug' by printing secrets or storing them in YAML — candidates must recognize that only Key Vault variable groups and UI-defined secret variables are secure.

Practice this question →
2
MCQmedium

Your company uses GitHub Enterprise for source control and GitHub Actions for CI/CD. The development team is distributed across three time zones. You are designing a process to improve communication and collaboration for code reviews. The team currently uses email notifications for pull request reviews, which often get missed. You want to implement a more efficient system that integrates with Microsoft Teams and provides real-time updates. Additionally, you need to ensure that critical pull requests (e.g., those affecting production) are escalated if not reviewed within 4 hours. You also want to automatically assign reviewers based on the files changed. Which combination of actions should you take?

A.Use a GitHub App (e.g., Pull Request Assigner) to automatically assign reviewers based on file patterns. Create a GitHub Action that sends a message to Microsoft Teams via webhook when a pull request is opened. Set up a second GitHub Action that runs every hour and checks pull request age, sending an escalation to Teams if older than 4 hours.
B.Use GitHub's built-in code owners feature to automatically request reviews based on file patterns. Create a GitHub Action that posts a notification to Microsoft Teams via webhook when a pull request is opened. For escalation, create a scheduled workflow (e.g., using cron) that runs every 30 minutes to identify pull requests older than 4 hours and sends an alert to Teams.
C.Configure GitHub branch protection rules to require pull request reviews. Create a Microsoft Teams webhook connector and add it to the repository to post notifications. Instruct team leads to manually tag reviewers based on file changes.
D.Use a third-party service like PullRequest.com to manage code reviews. Configure GitHub Actions to send notifications to Teams. For escalation, use a GitHub Action that triggers on pull request review request and uses conditional logic to escalate after 4 hours.
AnswerB

This is the correct approach because CODEOWNERS natively assigns reviewers automatically based on file patterns (e.g., requiring the frontend team for .tsx changes), which is reliable and free. A GitHub Action triggered on pull_request opened sends an immediate webhook notification to Microsoft Teams, giving the team instant visibility. For escalation, a scheduled workflow using cron (e.g., every 30 minutes) queries open pull requests and alerts Teams for any PR older than 4 hours, providing timely detection without constant polling or wasted CI minutes. This combination leverages built-in GitHub features, avoids external services, and ensures stale reviews are automatically escalated.

Why this answer

It uses GitHub's built-in code owners feature for automatic reviewer assignment based on file patterns, which is native and requires no third-party app. It then uses a GitHub Action with a webhook to post real-time notifications to Microsoft Teams when a pull request is opened. For escalation, a scheduled workflow (cron) running every 30 minutes checks pull request age and sends an alert to Teams if older than 4 hours, meeting the real-time and escalation requirements without manual intervention.

Exam trap

The trap here is that candidates may choose Option A because it seems comprehensive, but they overlook that GitHub's built-in code owners feature is the recommended and simpler approach for automatic reviewer assignment, and that a scheduled workflow (cron) is necessary for time-based escalation rather than relying on event-driven triggers.

How to eliminate wrong answers

Option A is wrong because it relies on a third-party GitHub App (Pull Request Assigner) instead of GitHub's native code owners feature, which is simpler and more maintainable; also, checking pull request age every hour may miss the 4-hour escalation window if the check runs at the wrong interval. Option C is wrong because it requires manual tagging of reviewers based on file changes, which is inefficient and error-prone for a distributed team; it also lacks automated escalation for critical pull requests. Option D is wrong because it uses a third-party service (PullRequest.com) for code reviews, which adds unnecessary complexity and cost; the escalation approach using a GitHub Action triggered on review request with conditional logic is not reliable for time-based escalation because it only fires on events, not on a schedule, and cannot detect pull requests that have not been reviewed after 4 hours.

Practice this question →
3
Multi-Selecteasy

Your organization uses GitHub and wants to automatically assign pull request reviewers based on the files changed. Which three steps should you take?

Select 3 answers
A.Configure 'Code owner review requirement' in branch protection.
B.Create a CODEOWNERS file in the repository defining teams for file patterns.
C.Enable 'Require pull request reviews before merging' branch protection rule.
D.Enable 'Protected branches' for the main branch.
E.Configure team synchronization for the organization.
AnswersA, B, C

Enabling 'Code owner review requirement' under branch protection mandates that any pull request modifying files with designated code owners must receive an approving review from at least one of those owners before merging. This setting enforces the approval from the exact responsible party, making it the correct automatic review-assignment mechanism.

Why this answer

Configuring 'Code owner review requirement' in branch protection enforces that pull requests affecting files with defined code owners must be approved by those owners before merging. This ensures that changes to specific file patterns automatically require review from the designated teams or individuals, aligning with the goal of automatic assignment based on files changed.

Exam trap

The trap here is that candidates may confuse 'Require pull request reviews before merging' (which only requires any reviewer approval) with 'Code owner review requirement' (which specifically requires approval from the code owner defined in CODEOWNERS), leading them to think option C alone is sufficient without the CODEOWNERS file and the code owner enforcement.

Practice this question →
4
Multi-Selecthard

Which THREE practices improve the efficiency of code review processes in GitHub?

Select 3 answers
A.Allow direct pushes to main for urgent fixes.
B.Enable required status checks to pass before merging.
C.Use pull request templates with checklists.
D.Require at least 5 reviewers for every PR.
E.Keep pull requests small and focused.
AnswersB, C, E

Required status checks gate merging on automated build, test, and validation results, so reviewers avoid manually verifying code that CI already proves sound. This reduces review cycles and prevents broken code entering protected branches, directly improving code review efficiency.

Why this answer

Option B is correct because enabling required status checks (branch protection rules that block merging until CI checks pass) ensures automated tests, linting, and builds succeed before human review, reducing review cycles spent on broken or untested code. Option C is correct because pull request templates with checklists standardize what authors provide (e.g., description, testing steps, linked issues), so reviewers spend less time requesting missing context and more time on substantive feedback. Option E is correct because small, focused pull requests are easier and faster to review, produce more precise comments, and reduce merge conflicts and review fatigue, directly improving review efficiency.

Option A is not appropriate because allowing direct pushes to main bypasses review entirely and undermines branch protection, increasing risk rather than improving the review process. Option D is not appropriate because requiring at least 5 reviewers for every PR creates bottlenecks, slows merge times, and adds redundant approvals without proportional quality gains.

Exam trap

The trap here is that candidates may confuse 'efficiency' with 'speed' and choose Option A (direct pushes) to bypass review, but the question asks for practices that improve efficiency of the review process itself, not shortcuts that undermine it.

Practice this question →
5
MCQmedium

A development team wants to ensure that all code changes are reviewed by at least two senior developers before merging into the main branch. They use Azure Repos. What should they configure?

A.Enable the build validation policy on the branch.
B.Set up a release pipeline with gated deployments.
C.Configure a branch policy requiring a minimum number of reviewers.
D.Add a status check policy using Azure Functions.
AnswerC

Branch policies in Azure Repos can enforce a minimum number of reviewers on pull requests, blocking completion until the required number of approved reviews is met; this directly ensures that every code change receives the mandated human review before merging.

Why this answer

Azure Repos branch policies allow you to enforce a minimum number of reviewers on pull requests. By setting the 'Minimum number of reviewers' policy to 2, the team ensures that at least two senior developers must approve any code change before it can be merged into the main branch. This directly meets the requirement without involving build validation, release pipelines, or external function calls.

Exam trap

The trap here is that candidates often confuse build validation policies (which ensure code compiles) with reviewer policies (which ensure human oversight), leading them to select option A instead of C.

How to eliminate wrong answers

Option A is wrong because enabling the build validation policy ensures that a build succeeds before merging, but it does not enforce any requirement for human code reviews or a minimum number of reviewers. Option B is wrong because a release pipeline with gated deployments controls when artifacts are deployed to environments, not when code is merged into a branch; it does not enforce pre-merge review requirements. Option D is wrong because a status check policy using Azure Functions can call external services to report a status, but it does not natively enforce a minimum number of reviewers; it would require custom logic and does not replace the built-in reviewer policy.

Practice this question →
6
MCQeasy

Your organization uses Azure DevOps and has a project with multiple teams. The 'AlphaTeam' wants a branch policy on their feature branch 'feature/alpha' that requires a successful build from the CI pipeline and approval from at least one member of 'AlphaTeam'. However, the 'BetaTeam' should be able to push directly to 'feature/alpha' without a pull request. You need to configure the branch policy accordingly. What should you do?

A.Create a new repository for AlphaTeam and apply the policy there.
B.Set a branch policy at the repository level that applies to all branches, then grant BetaTeam bypass permission.
C.Configure the branch policy on 'feature/alpha' to require build and approval, and set 'Allow direct pushes' to 'Everyone'.
D.Configure the branch policy on 'feature/alpha' to require build and approval from AlphaTeam, and set 'Allow direct pushes' to 'Selected users' and add BetaTeam.
AnswerD

Configuring the 'feature/alpha' branch policy to require build and approval from AlphaTeam while setting 'Allow direct pushes' to 'Selected users' and adding BetaTeam grants BetaTeam a scoped bypass only for direct pushes to that specific branch. AlphaTeam and other non-selected users still must submit a pull request and satisfy the build and approval requirements. This balances the need for BetaTeam to push directly with the need to keep the feature branch protected, and it does not affect any other branches.

Why this answer

Azure DevOps branch policies allow you to configure 'Allow direct pushes' to specific users or groups while still enforcing PR requirements for others. By setting the policy on 'feature/alpha' to require a successful build and approval from at least one AlphaTeam member, and then selecting 'Selected users' for direct pushes with BetaTeam added, BetaTeam can push directly without a PR, while AlphaTeam must follow the PR policy.

Exam trap

The trap here is that candidates often confuse 'Allow direct pushes' with a global bypass permission, not realizing it can be scoped to specific users while still enforcing policies for others.

How to eliminate wrong answers

Option A is wrong because creating a separate repository is unnecessary and does not solve the requirement for a single repository with differentiated access; it would also break the existing project structure. Option B is wrong because setting a branch policy at the repository level applies to all branches, which would force PRs on BetaTeam's branches as well, and granting bypass permission would remove all policy enforcement, including the build requirement. Option C is wrong because setting 'Allow direct pushes' to 'Everyone' would allow anyone, including AlphaTeam, to bypass the PR requirement, which contradicts the need for AlphaTeam to use pull requests.

Practice this question →
7
MCQhard

You are the Azure DevOps administrator for a large enterprise with multiple projects using the Scrum process. The organization has recently adopted a new compliance policy requiring that all work items of type 'Epic' must be approved by a compliance officer before they can be moved to the 'Committed' state. The compliance officers are external to the development teams and should not have direct access to modify work items. You need to implement this requirement with minimal administrative overhead. The current process has the following states for Epics: New, Proposed, Committed, In Progress, Done. The desired flow is: from 'Proposed' to 'Committed', a compliance officer must approve the transition. Compliance officers are part of a security group named 'Compliance Officers'. They should be able to approve the transition without having to edit the work item directly. What should you do?

A.In the process template for Epic, add a work item rule on the transition from 'Proposed' to 'Committed' that requires approval from a member of the 'Compliance Officers' group.
B.Use a service hook to send an email to the compliance officers when an Epic is moved to 'Proposed', and rely on them to manually approve the transition.
C.Modify the Epic work item type to add a field 'Compliance Approval' and set the compliance officer as a required reviewer in the field settings.
D.Configure a branch policy on the main branch that requires approval from the 'Compliance Officers' group for pull requests.
AnswerA

This is the correct solution because Azure DevOps process template rules for work item types can enforce approvals on specific state transitions. Adding a rule to the Epic workflow that requires approval from the 'Compliance Officers' group when moving from 'Proposed' to 'Committed' ensures the transition cannot be completed without that group's authorization, directly enforcing the compliance gate at the work item level.

Why this answer

Azure DevOps process templates allow you to add work item rules on state transitions. By adding a rule on the 'Proposed' to 'Committed' transition for the Epic work item type that requires approval from a member of the 'Compliance Officers' group, you enforce the compliance policy without granting those officers direct edit permissions. This leverages built-in approval gates within the work item tracking system, minimizing administrative overhead.

Exam trap

The trap here is that candidates may confuse work item rules with branch policies or service hooks, mistakenly thinking that notification-based or code-review mechanisms can enforce work item state transitions.

How to eliminate wrong answers

Option B is wrong because a service hook only sends a notification; it does not enforce an approval gate or prevent the transition from occurring without approval, so the compliance policy would not be technically enforced. Option C is wrong because adding a custom field and setting a required reviewer does not create an approval workflow on the state transition; it merely adds a field that can be filled without blocking the transition, and compliance officers would still need direct edit access to modify the field. Option D is wrong because branch policies apply to pull requests on code repositories, not to work item state transitions, and are unrelated to the Scrum process or Epic work items.

Practice this question →
8
MCQmedium

You are an Azure DevOps administrator for a team that wants to automatically link work items to pull requests in Azure Repos. The team uses a single Git repository and requires that every pull request has at least one linked work item before it can be completed. You need to configure the repository settings to enforce this requirement. What should you do?

A.Add a required template to the pull request description that includes a work item ID field.
B.Configure a branch policy that requires a minimum number of reviewers.
C.Enable the 'Check for linked work items' setting in the repository's policies.
D.Create a work item query that lists all pull requests without linked work items.
AnswerC

This setting, found under Repos > Policies, enforces that every pull request must have at least one linked work item before it can be completed. It directly satisfies the requirement to automatically link work items and prevent completion without them. Enabling this policy ensures compliance with the team's process without manual intervention.

Why this answer

Enabling the 'Check for linked work items' policy in Azure Repos ensures that every pull request must have at least one linked work item before completion. This directly enforces the team's requirement, unlike reviewer policies, queries, or templates, which do not prevent completion without a link. The policy is configured per repository and is the standard method for this enforcement.

Exam trap

The trap here is confusing code review policies with work item linking policies, assuming that any branch policy can enforce work item association.

Practice this question →
9
MCQhard

Your team manages a large-scale microservices application deployed on Azure Kubernetes Service (AKS). The code is hosted in Azure Repos, and you use Azure Pipelines for CI/CD. You have recently adopted GitHub Copilot for code suggestions. Your compliance team requires that all pipeline runs include a security scan using Microsoft Defender for Cloud. Additionally, all pull requests must have at least two reviewers from separate teams before merging. The current pipeline completes in 45 minutes, and you want to minimize overhead. You need to design a process that enforces these requirements without degrading developer productivity. Which approach should you recommend?

A.Configure a branch policy on the main branch that requires a successful build and security scan before merging, and use a single pipeline that includes the scan.
B.Integrate the security scan as a step early in the CI pipeline, and configure branch policies on the main branch to require two reviewers from different teams and a successful CI build including the scan. Document the process and use Copilot to generate commit messages that reference work items.
C.Create a separate security scan pipeline triggered on pull request creation, and require its successful completion via branch policy. Then set up a separate PR policy requiring two reviewers.
D.Add a manual approval gate in the release pipeline that requires the security officer to approve after the scan completes.
AnswerB

This is the optimal solution because it embeds the security scan as an early CI step, ensuring vulnerabilities are detected immediately after code is pushed, and branch policies explicitly require two reviewers from different teams plus a successful pipeline run. Configuring the scan as part of the CI build avoids extra pipeline overhead and eliminates parallel wait times, while branch policies for reviewers are applied automatically on every pull request. Using Copilot to generate commit messages that reference work items enhances traceability without additional manual effort, ensuring that every change can be linked to a work item. This approach efficiently enforces both the scan and the review policy with minimal complexity.

Why this answer

It integrates the security scan early in the CI pipeline, ensuring it runs on every build without adding a separate pipeline overhead. Branch policies enforce both the required two reviewers from different teams and the successful CI build (including the scan) before merging, which minimizes additional pipeline complexity and maintains developer productivity.

Exam trap

The trap here is that candidates may think a separate security scan pipeline (Option C) is necessary for compliance, but Azure Pipelines allows integrating the scan into the existing CI pipeline, which is more efficient and still meets the requirement of running on every pull request.

How to eliminate wrong answers

Option A is wrong because it only requires a successful build and security scan before merging but does not enforce the mandatory two-reviewer requirement from separate teams, which is a compliance necessity. Option C is wrong because creating a separate security scan pipeline triggered on pull request creation adds unnecessary overhead and complexity, degrading developer productivity compared to integrating the scan into the existing CI pipeline. Option D is wrong because a manual approval gate in the release pipeline occurs after the build and scan, which does not enforce the scan requirement on every pull request before merging, and it introduces a bottleneck that reduces productivity.

Practice this question →
10
Multi-Selectmedium

Which THREE practices help ensure that work item tracking is effective in Azure Boards?

Select 3 answers
A.Avoid customizing work item types to maintain consistency.
B.Link work items to code changes and pull requests.
C.Keep work items small and granular.
D.Regularly update work item fields (e.g., Remaining Work).
E.Create large work items that cover multiple features.
AnswersB, C, D

Linking work items to commits and pull requests creates traceability between planned work and delivered code, satisfying the requirement for effective tracking. Azure Boards then surfaces development links on the work item, so reviewers and auditors can verify which changes implemented each requirement without manual cross-referencing.

Why this answer

Linking work items to code changes and pull requests creates a traceable path from requirements to implementation, enabling teams to understand the context of changes and automatically update work item status (e.g., via GitHub integration or Azure Repos). Keeping work items small and granular allows for accurate estimation, faster delivery, and meaningful progress tracking; large items hide complexity and make it difficult to measure velocity. Regularly updating fields such as Remaining Work ensures that burndown charts and sprint reports reflect reality, supporting accurate forecasting and early detection of issues.

Exam trap

The trap here is that candidates may think customizing work item types is always harmful (Option A) or that large work items simplify tracking (Option E), but Azure Boards is designed to be flexible and granularity is key for effective Agile metrics like velocity and burndown.

Practice this question →
11
MCQhard

Your organization uses GitHub Flow with branch protections. Developers must link every pull request to an issue using a closing keyword (e.g., 'Fixes #123'). You need to enforce this linking automatically. What should you do?

A.Create a GitHub Actions workflow that validates the PR description contains a closing keyword.
B.Configure an issue template with a closing keyword prompt.
C.Add a branch protection rule requiring a linked issue.
D.Use a required status check from a third-party app.
AnswerA

A GitHub Actions workflow can be triggered on the pull_request event and inspect the PR description for a closing keyword such as 'closes', 'fixes', or 'resolves' followed by an issue number. The workflow can use a regex or a simple string check to validate the pattern, and then be configured as a required status check in branch protection, making it a reliable first-party enforcement mechanism.

Why this answer

A GitHub Actions workflow can be configured to run on pull request events and parse the PR description for a closing keyword pattern (e.g., regex matching 'Fixes #\d+'). If the keyword is missing, the workflow can fail the check, blocking the merge via branch protection rules that require status checks to pass. This directly enforces the linking requirement without relying on human compliance or third-party tools.

Exam trap

The trap here is that candidates often confuse the 'Require a linked issue' branch protection rule (which only enforces a UI-based link) with the need to validate the PR description text for a closing keyword, leading them to incorrectly select option C.

How to eliminate wrong answers

Option B is wrong because an issue template only provides a prompt for creating new issues; it does not enforce that existing pull requests reference an issue via a closing keyword. Option C is wrong because GitHub's branch protection rule for 'Require a linked issue' only checks that a PR has an issue linked via the GitHub UI (the sidebar), not that the PR description contains a closing keyword like 'Fixes #123'. Option D is wrong because a required status check from a third-party app would still need to be implemented to validate the closing keyword; the option is too vague and does not specify a concrete enforcement mechanism, whereas a GitHub Actions workflow is the direct, built-in solution.

Practice this question →
12
Multi-Selecthard

Which THREE practices are recommended for managing technical debt in a DevOps environment?

Select 3 answers
A.Allocate time for refactoring in each iteration
B.Defer unit tests until after deployment
C.Automate unit and integration tests
D.Integrate static code analysis into the CI pipeline
E.Ignore low-priority code smells
AnswersA, C, D

Incrementally dedicating a fixed amount of time to refactoring within each sprint or iteration—often called the 'boy scout rule'—prevents technical debt from accumulating and keeps the codebase maintainable. This continuous small-scale design improvement reduces the risk of large-scale rework later, because complexity and coupling are regularly addressed, and it aligns with Agile principles of sustainable pace. It also complements automated tests, which provide the safety net needed to refactor confidently.

Why this answer

Options A, C, and D are correct because managing technical debt in a DevOps environment requires proactive and automated quality practices. Allocating time for refactoring each iteration (A) prevents debt accumulation. Automating unit and integration tests (C) ensures early detection of regressions and quality issues.

Integrating static code analysis into the CI pipeline (D) provides continuous feedback on code quality and debt indicators. Option B is incorrect because deferring unit tests increases technical debt by delaying detection. Option E is incorrect because ignoring low-priority code smells allows debt to grow, which should be tracked and addressed systematically.

Exam trap

The trap here is that candidates may incorrectly assume that low-priority code smells can be safely ignored, but Azure DevOps and SonarQube best practices emphasize that all debt should be tracked and addressed systematically to prevent long-term degradation.

Practice this question →
13
Multi-Selectmedium

Which THREE elements are essential for an effective incident response process in a DevOps environment? (Choose three.)

Select 3 answers
A.Automated rollback or remediation capabilities.
B.A blame-free culture that identifies the person at fault.
C.Post-incident reviews with actionable improvements.
D.Manual approval gates for every change.
E.A clear escalation path and on-call rotation.
AnswersA, C, E

Automated rollback or remediation capabilities are essential because they enable rapid, deterministic recovery from failed deployments or incidents without human latency, reducing mean time to recovery (MTTR) and preventing error-prone manual steps. This aligns with DevOps principles of automation and resilience.

Why this answer

Automated rollback or remediation capabilities are essential because they enable rapid, consistent recovery from incidents without manual intervention. In a DevOps environment, this is typically implemented through deployment pipelines (e.g., Azure Pipelines) that support automatic rollback to a previous known-good version when health checks fail, or through infrastructure-as-code tools like Terraform that can revert state. This minimizes mean time to recovery (MTTR) and reduces human error during high-pressure situations.

Exam trap

The trap here is that candidates confuse a 'blame-free culture' with identifying the person at fault, when in reality the exam expects you to recognize that blameless postmortems focus on process improvements, not individual accountability.

Practice this question →
14
Multi-Selecthard

Which TWO GitHub Actions features can be used to enforce deployment approvals for a production environment? (Choose two.)

Select 2 answers
A.Deployment protection rules that require approval.
B.The 'deployment' event trigger in a workflow.
C.Environments with required reviewers.
D.Branch protection rules that require pull request reviews.
E.OpenID Connect (OIDC) for cloud provider authentication.
AnswersA, C

Deployment protection rules, when configured on an environment, can require manual approval from specified reviewers before a job referencing that environment can run. This pauses the workflow and enforces a human gate prior to deployment.

Why this answer

Deployment protection rules in GitHub Actions allow you to define required approvals before a workflow job can deploy to an environment. These rules are configured at the environment level and can mandate that a specific number of reviewers approve the deployment, effectively enforcing a manual approval gate for production environments.

Exam trap

The trap here is confusing branch protection rules (which control code merges) with environment-level deployment protection rules (which control deployment approvals), leading candidates to incorrectly select branch protection rules as a mechanism for deployment approvals.

Practice this question →
15
MCQmedium

You are designing a communication strategy for your DevOps team. They use Microsoft Teams for collaboration. You need to automatically notify the team when a release to production fails. Which Azure DevOps integration should you use?

A.Set up an email subscription to the DevOps team
B.Create a service hook to call a custom API
C.Publish a Wiki page with deployment status
D.Configure a notification subscription in Azure DevOps to send a Teams webhook
AnswerD

Azure DevOps notification subscriptions can be configured with an incoming webhook to send release failure alerts directly to a Teams channel. This leverages built-in integration, delivers real-time messages, and avoids custom development or additional hosting.

Why this answer

Azure DevOps notification subscriptions can be configured to send alerts to a Teams channel via an incoming webhook. This allows automatic, real-time notifications to the DevOps team when a release to production fails, directly within their collaboration platform.

Exam trap

The trap here is that candidates may confuse a generic email subscription or a custom service hook with the purpose-built Teams webhook integration, overlooking that Azure DevOps provides a direct notification subscription type for Teams that requires no custom development.

How to eliminate wrong answers

Option A is wrong because email subscriptions are a generic notification method that do not integrate directly with Microsoft Teams; they would require the team to check email separately, which is less efficient for real-time collaboration. Option B is wrong because creating a service hook to call a custom API is an overly complex and indirect approach; while it could theoretically work, it is not the standard or recommended integration for sending notifications to Teams. Option C is wrong because publishing a Wiki page with deployment status is a manual or static documentation method, not an automated notification mechanism; it does not provide real-time alerts when a release fails.

Practice this question →
16
MCQmedium

You are designing a communication strategy for a large Azure DevOps migration. The team is distributed across multiple time zones. Which approach best supports asynchronous collaboration?

A.Use Slack huddles for quick sync-ups.
B.Maintain a wiki in Azure DevOps with status and decisions.
C.Use email threads for status updates.
D.Schedule daily standup meetings at a fixed time.
E.Record all team meetings and share links.
AnswerB

A wiki in Azure DevOps stores status and decisions as versioned Markdown, letting distributed team members read and contribute at any hour without scheduling overlap. This directly satisfies the asynchronous collaboration constraint, unlike synchronous channels such as stand-ups or chat, which require simultaneous availability across time zones.

Why this answer

Maintaining a wiki in Azure DevOps provides a persistent, searchable, and asynchronous record of status and decisions, which is ideal for distributed teams across time zones. Option A is wrong because Slack huddles are real-time and require synchronous participation. Option C is wrong because email threads can be hard to search and lack integration with Azure DevOps.

Option D is wrong because daily standup meetings at a fixed time require synchronous attendance. Option E is wrong because recording meetings is passive and not easily searchable; the information is not structured for quick reference.

Practice this question →
17
MCQeasy

You want to ensure that every commit message in your repository follows a specific format. Which GitHub feature can enforce this?

A.Webhooks to validate and reject pushes
B.Branch protection rules
C.GitHub Actions workflow with push trigger
D.Required status checks with a commit lint action
AnswerD

A required status check created by a commit lint action (e.g., a GitHub Actions workflow that runs on pull_request and push events) validates commit messages against a convention and reports a success/failure status. By marking that status check as required in branch protection rules, the push or merge is blocked until the commit messages pass the linting rule.

Why this answer

Required status checks, when combined with a commit lint action in a GitHub Actions workflow, can enforce commit message formatting. The workflow runs on push or pull request events, and the status check must pass before a pull request can be merged, effectively rejecting commits that do not conform to the specified format.

Exam trap

The trap here is that candidates confuse a GitHub Actions workflow that runs a commit lint action (which alone does not enforce anything) with the combination of that workflow and a required status check in branch protection rules, which is what actually enforces the commit message format.

How to eliminate wrong answers

Option A is wrong because webhooks can trigger external services to validate pushes, but they cannot directly reject pushes; they only send event payloads. Option B is wrong because branch protection rules can require status checks, code reviews, or prevent force pushes, but they cannot enforce commit message formatting on their own. Option C is wrong because a GitHub Actions workflow with a push trigger can run a commit lint action, but without a required status check configured in branch protection rules, the workflow result does not block non-conforming commits from being merged.

Practice this question →
18
MCQhard

Your Azure DevOps project uses a self-hosted agent pool. Users report that builds are randomly failing with a 'disk full' error. The agents have 50 GB of disk space. What is the most effective way to mitigate this issue?

A.Add more agents to the pool
B.Use the 'Clean all build directories' option in the agent configuration
C.Enable the 'Clean after build' option on the build pipeline
D.Set 'Maximum number of parallel jobs' to 1
AnswerC

Enabling 'Clean after build' on the build pipeline triggers an automated workspace purge, typically using commands like `git clean -fdx` or equivalent, immediately after each job finishes. This removes source files, compiled outputs, test binaries, and cached dependencies from the agent's working directory (e.g., `_work`) at the point when they are no longer needed, so disk space is reclaimed on a per-build basis. This directly prevents the steady accumulation of stale build artifacts that ultimately exhausts the agent's local storage.

Why this answer

Enabling 'Clean after build' ensures workspace cleanup after each run, reclaiming disk space to prevent failures. Option A is wrong because adding more agents doesn't free disk space on existing agents. Option B is wrong because 'Clean all build directories' cleans before builds, which may not prevent mid-build disk full errors and can disrupt parallel builds.

Option D is wrong because limiting parallel jobs doesn't free disk space; a single build can still consume all available disk space.

Practice this question →
19
MCQeasy

Your team uses Azure Test Plans. You need to ensure that testers can easily see which test cases are blocked by a known bug. What should you do?

A.Configure the test plan to show only failed tests.
B.Create a test suite for each bug.
C.Link test cases to the bug and create a query for linked items.
D.Copy the test case and mark it as blocked.
AnswerC

Linking each blocked test case to its bug creates a traceable relationship, and a work item query filtering on linked items surfaces those test cases, giving testers a clear view of what the known bug blocks.

Why this answer

Azure Test Plans allows test cases to be linked directly to bugs via work item linking. By creating a query for linked items (e.g., a shared query that returns all test cases linked to a specific bug), testers can instantly see which test cases are blocked by that known bug. This provides a dynamic, filterable view without duplicating or reorganizing test artifacts.

Exam trap

The trap here is that candidates often confuse 'marking a test as blocked' (a manual status change) with the proper traceability approach of linking work items, leading them to choose Option D or B instead of leveraging Azure DevOps' built-in query and linking capabilities.

How to eliminate wrong answers

Option A is wrong because configuring the test plan to show only failed tests does not indicate which failures are caused by a known bug; it simply filters out passed tests, leaving all failures regardless of root cause. Option B is wrong because creating a test suite for each bug would require manual duplication and maintenance of test cases, leading to redundancy and confusion when bugs are fixed or closed. Option D is wrong because copying a test case and marking it as blocked creates an unnecessary duplicate that must be manually tracked and updated, breaking the traceability between the original test case and the bug.

Practice this question →
20
MCQmedium

Your project uses a monorepo in Azure Repos. You want to enforce that changes to a specific folder (/src/security) require approval from the security team. What is the best approach?

A.Add a required reviewer policy for all pull requests.
B.Configure a branch policy with a path filter and require approval from the security team group.
C.Move the security folder to a separate repository with its own policies.
D.Set folder-level permissions to restrict who can modify the folder.
AnswerB

Azure Repos branch policies support path filters, letting you scope required approvals to /src/security only. Assigning the security team group as required reviewer enforces their sign-off on changes touching that folder, while other paths remain unaffected.

Why this answer

Azure Repos branch policies allow you to define path filters that scope policy enforcement to specific folders. By adding a required reviewer policy with a path filter for `/src/security` and assigning the security team group, only pull requests modifying files under that folder will require their approval, leaving other changes unaffected.

Exam trap

The trap here is that candidates often confuse folder-level permissions (which control direct access) with branch policy path filters (which enforce workflow approvals), leading them to select Option D instead of the correct branch policy configuration.

How to eliminate wrong answers

Option A is wrong because a required reviewer policy without a path filter applies to all pull requests across the entire repository, forcing security team approval for every change, which is overly broad and not scoped to the specific folder. Option C is wrong because moving the folder to a separate repository introduces unnecessary complexity, breaks monorepo consistency, and does not leverage Azure Repos' built-in branch policy path filters for granular control. Option D is wrong because folder-level permissions in Azure Repos control direct push access but do not enforce pull request review workflows; a user with write permissions could still bypass approval by pushing directly to the branch if branch policies are not configured.

Practice this question →
21
MCQeasy

Your team uses Azure Pipelines to build and deploy a web app. You want to send a notification to a Microsoft Teams channel when a build fails. What should you configure?

A.Add a task in the pipeline to send an email on failure.
B.Create a service hook to trigger an Azure Logic App that sends a Teams message.
C.Add a dashboard widget that shows build status.
D.Use the built-in Azure Pipelines Teams integration to send a notification on build failure.
AnswerD

The built-in Azure Pipelines Teams integration lets you subscribe to build pipeline events, such as a failed build, and delivers an adaptive card notification directly to a configured Teams channel. This native subscription uses Azure DevOps service hooks to Teams internally, requiring no custom code, Logic Apps, or extra configuration, and is the canonical solution for notifying Teams of build failures.

Why this answer

Azure Pipelines has a built-in integration with Microsoft Teams that allows you to subscribe to notifications for pipeline events, such as build failures, directly from the Azure DevOps interface. This integration uses a service hook to send adaptive cards to a Teams channel without requiring custom logic or additional tasks.

Exam trap

The trap here is that candidates may overengineer the solution by choosing a custom Logic App or third-party task, overlooking the fact that Azure Pipelines has a first-class, built-in integration with Microsoft Teams that requires no additional code or services.

How to eliminate wrong answers

Option A is wrong because Azure Pipelines does not have a native 'send email on failure' task; email notifications are configured via subscription settings, not as a pipeline task. Option B is wrong because while a service hook can trigger an Azure Logic App to send a Teams message, this is an overly complex solution when the built-in Teams integration provides the same functionality with less overhead. Option C is wrong because a dashboard widget only displays build status visually within Azure DevOps and does not send proactive notifications to Microsoft Teams.

Practice this question →
22
MCQmedium

Your organization uses GitHub Copilot for pull request summaries. However, the summaries sometimes miss security-related changes. What should you recommend?

A.Configure Copilot to ignore non-security files.
B.Provide custom instructions to Copilot to emphasize security analysis.
C.Disable Copilot and rely on manual review.
D.Switch to a different AI model specialized in security.
AnswerB

Custom instructions steer Copilot's summary generation toward security-relevant diffs, satisfying the stem's requirement to surface missed security changes. Unlike repository-wide settings or model swaps, instructions directly shape the prompt context Copilot uses when drafting summaries, making security analysis an explicit priority during generation.

Why this answer

GitHub Copilot's pull request summaries can be customized using custom instructions to prioritize security analysis. By providing specific directives in the repository's `.github/copilot-instructions.md` file or through the Copilot settings, you can instruct the AI to explicitly highlight security-related changes, such as those involving authentication, encryption, or input validation. This ensures the generated summaries are more aligned with your organization's security review requirements without disabling the tool.

Exam trap

The trap here is that candidates may assume AI tools are inflexible and require replacement or disabling when they encounter limitations, rather than recognizing that GitHub Copilot supports custom instructions to refine its behavior for specific domains like security analysis.

How to eliminate wrong answers

Option A is wrong because configuring Copilot to ignore non-security files would prevent it from analyzing all files, potentially missing security issues in files that are not exclusively security-related (e.g., a configuration file that contains a security vulnerability). Option C is wrong because disabling Copilot entirely is an overreaction and discards its productivity benefits; the goal is to improve its output, not eliminate it. Option D is wrong because switching to a different AI model specialized in security is unnecessary and disruptive; GitHub Copilot already supports customization through instructions, and a specialized model would require separate integration and may not work seamlessly with pull request summaries.

Practice this question →
23
MCQhard

Your Azure DevOps pipeline uses a YAML template that includes a step to push a Docker image to Azure Container Registry. The pipeline fails with 'unauthorized: authentication required'. The service connection uses a workload identity federation. What is the most likely cause?

A.The Docker image tag contains invalid characters
B.The Azure Container Registry name is incorrect
C.The service principal used by the workload identity does not have the 'acrPush' role
D.The service connection secret has expired
AnswerC

The federated identity credential for the workload identity federation is functioning correctly in the authentication phase, but the associated service principal lacks the 'AcrPush' role assignment on the Azure Container Registry, which is required for pushing Docker images. Without this role, the registry rejects the push with an authorization error (e.g., 'unauthorized: authentication required' or 'insufficient permissions'), even though the service principal authenticated successfully.

Why this answer

The error 'unauthorized: authentication required' indicates that the Docker client could not authenticate with Azure Container Registry. With workload identity federation, the service principal used by the federated credential must have the 'acrPush' role assigned on the ACR scope to push images. Without this role assignment, the authentication token lacks the necessary permissions, even if the identity itself is valid.

Exam trap

The trap here is that candidates confuse authentication (identity validation) with authorization (permission to act), assuming any valid identity can push to ACR, but ACR requires explicit role assignment even for federated identities.

How to eliminate wrong answers

Option A is wrong because invalid characters in the Docker image tag cause a different error (e.g., 'invalid reference format') and do not trigger authentication failures. Option B is wrong because an incorrect ACR name would result in a 'name unknown' or 'repository not found' error, not an authentication error. Option D is wrong because workload identity federation does not use a client secret; it relies on a federated credential token exchange, so secret expiry is irrelevant.

Practice this question →
24
MCQmedium

A company recently migrated its CI/CD pipelines from Jenkins to Azure Pipelines. The development team is experiencing frequent build failures due to conflicting changes when multiple developers push code simultaneously. The team wants to maintain a linear history and avoid merge commits. Which strategy should you recommend?

A.Switch to Git with a central repository and require merge commits.
B.Enforce a rebase strategy for all pull requests in the branch policy.
C.Use Team Foundation Version Control (TFVC) with exclusive checkout enabled.
D.Configure Azure Repos to use squash merge when completing pull requests.
AnswerC

TFVC with exclusive checkout is correct because it enables server-side, per-file locking: as soon as one developer checks out a file, any other user's attempt to check out that same file is blocked until the first check-in, thereby ensuring no concurrent edits can create conflicts and enforcing a strictly linear history over the shared files.

Why this answer

Team Foundation Version Control (TFVC) with exclusive checkout enforces a lock on a file when a developer checks it out, preventing simultaneous edits. This eliminates conflicting changes that cause build failures when multiple developers push code concurrently, and since TFVC does not use merge commits, it maintains a linear history. The scenario explicitly requires avoiding merge commits and resolving conflicts from simultaneous pushes, which TFVC’s exclusive checkout directly addresses.

Exam trap

The trap here is that candidates often assume Git-based strategies (like rebase or squash merge) can prevent simultaneous push conflicts, but they only manage how history looks after a merge, not the underlying conflict that occurs when two developers push changes to the same file at the same time.

How to eliminate wrong answers

Option A is wrong because switching to Git with a central repository and requiring merge commits would introduce merge commits, violating the requirement to maintain a linear history and avoid merge commits. Option B is wrong because enforcing a rebase strategy for pull requests in Git still allows conflicting changes when multiple developers push simultaneously; rebase rewrites commit history but does not prevent conflicts at the push stage, and it can lead to non-linear history if not handled carefully. Option D is wrong because configuring Azure Repos to use squash merge when completing pull requests collapses all commits into one, but it still requires a pull request and merge operation, which can introduce merge commits if conflicts arise, and it does not prevent simultaneous push conflicts; squash merge is about commit history compression, not conflict prevention.

Practice this question →
25
MCQhard

Your organization uses Azure DevOps and has a strict compliance requirement: all changes to the main branch must be reviewed by at least two members of the 'ComplianceTeam' group. Additionally, a static code analysis tool must run and its results must be published to the pull request. The ComplianceTeam is a custom group defined in Azure DevOps, not a Microsoft Entra ID group. The team wants to enforce this using branch policies. You need to configure the minimum number of reviewers and also ensure that the code analysis results are visible to reviewers. What should you do?

A.Add a branch policy 'Require a minimum number of reviewers' set to 2, and specify the ComplianceTeam as required reviewers. Additionally, add a build policy that runs the code analysis and publishes results as a build summary.
B.Add a branch policy 'Require code owner review' and define the ComplianceTeam as code owners in a CODEOWNERS file.
C.Add a branch policy 'Comment resolution' and configure the ComplianceTeam to resolve comments.
D.Add a branch policy 'Automatically included reviewers' and set the ComplianceTeam to be automatically added to all PRs.
AnswerA

Setting 'Require a minimum number of reviewers' to 2 and specifying ComplianceTeam as required reviewers enforces exactly two approvals from that team before a pull request can be merged. Because required reviewers are mandatory, any approval from a team member counts toward the minimum, and the policy blocks the merge until both approvals are present. Adding a build policy that runs code analysis and publishes results as a build summary integrates the compliance gate directly into the PR, giving reviewers the evidence needed to approve confidently. This combination fully satisfies the strict compliance requirement.

Why this answer

The 'Require a minimum number of reviewers' branch policy enforces that at least two members from the ComplianceTeam must approve the pull request. Adding a build policy that runs static code analysis and publishes results as a build summary ensures the analysis output is visible directly in the PR, meeting the compliance requirement for both reviewer count and code analysis visibility.

Exam trap

The trap here is that candidates often confuse 'Automatically included reviewers' (which only adds reviewers but does not enforce approval) with 'Require a minimum number of reviewers' (which enforces the actual approval count), leading them to choose Option D instead of A.

How to eliminate wrong answers

Option B is wrong because 'Require code owner review' only mandates that a code owner (defined in a CODEOWNERS file) must approve changes to specific files; it does not enforce a minimum number of reviewers or require two specific members from the ComplianceTeam. Option C is wrong because 'Comment resolution' only tracks whether comments on a PR are resolved, not reviewer count or code analysis visibility. Option D is wrong because 'Automatically included reviewers' merely adds the ComplianceTeam as optional reviewers to the PR but does not enforce that at least two of them must approve the changes.

Practice this question →
26
MCQhard

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?

A.Create a custom process for each time zone and assign teams accordingly.
B.Use the same process but create separate areas for each team, then configure working days per area path.
C.Use the same process and configure working days in the team settings for each team.
D.Use the same process and configure capacity planning for each team to account for time off.
AnswerC

Azure DevOps allows each team in a shared project to have its own working days and non-working days under Team Settings, so teams in different time zones can use the same process while reflecting local calendars. This per-team calendar feeds backlog, sprint, and capacity views, making it the correct approach for a multinational company using a single project.

Why this answer

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.

Exam trap

The trap here is that candidates confuse team-level settings (like working days) with process-level customizations, assuming that different working days require different process templates, when in fact Azure DevOps separates team configuration from process inheritance.

How to eliminate wrong answers

Option A is wrong because creating a custom process for each time zone is unnecessary and introduces administrative overhead; working days are a team-level setting, not a process-level setting. Option B is wrong because area paths are used for organizing work items by feature or component, not for configuring working days; working days are configured per team, not per area path. Option D is wrong because capacity planning accounts for individual time off and sprint capacity, not recurring weekly working days for the entire team.

Practice this question →
27
Multi-Selecteasy

Which TWO Azure DevOps features can be used to implement change management processes?

Select 2 answers
A.Test plans.
B.Release approval gates.
C.Audit logging.
D.Project wiki.
E.Code search.
AnswersB, C

Release approval gates are a change management control that require designated reviewers to explicitly approve a release before it proceeds to an environment, and can also enforce automated checks. By gating the promotion of builds across stages, they ensure only authorized changes are deployed.

Why this answer

Release approval gates (Option B) in Azure Pipelines allow you to enforce manual or automated checks before a release proceeds to a stage, implementing change management by requiring sign-offs or validation against external systems. Audit logging (Option C) captures a chronological record of changes to Azure DevOps resources, providing an immutable trail for compliance and change review processes.

Exam trap

The trap here is that candidates confuse features for documentation or testing (Test plans, Wiki) with those that enforce process controls, overlooking that change management requires approval workflows and audit trails, not just recording or searching content.

Practice this question →
28
MCQhard

Your organization uses GitHub and wants to enforce that all commits to the main branch are signed with a GPG key that is verified against the user's GitHub account. Additionally, you want to block unsigned commits even if the committer is a repository admin. Which configuration should you use?

A.Add a pre-receive hook that rejects unsigned commits.
B.Enable 'Require signed commits' and set 'Include administrators' to false.
C.Enable 'Require signed commits' and set 'Include administrators' to true.
D.Enable 'Require signed commits' and configure web commit signing.
AnswerC

Enabling 'Require signed commits' with 'Include administrators' set to true ensures that every commit pushed to the protected branch must have a valid signature, regardless of the pusher's role. This branch protection setting applies to all users, including repository administrators, thereby meeting the organization's goal of enforcing signed commits across the board on GitHub.com.

Why this answer

Enabling 'Require signed commits' in a GitHub branch protection rule, combined with setting 'Include administrators' to true, enforces that every commit pushed to the protected branch must be signed with a GPG key verified against the user's GitHub account, and this restriction applies even to repository administrators. This configuration blocks unsigned commits entirely, meeting the requirement to enforce signing for all users including admins.

Exam trap

The trap here is that candidates often confuse 'Include administrators' with a separate setting or assume that admins are always exempt, leading them to choose Option B, but the question explicitly requires blocking unsigned commits for all users including admins, so 'Include administrators' must be set to true.

How to eliminate wrong answers

Option A is wrong because pre-receive hooks are only available in GitHub Enterprise Server (self-hosted) and are not supported in GitHub.com (SaaS), so this option is not applicable for a standard GitHub organization. Option B is wrong because setting 'Include administrators' to false would exempt repository administrators from the signing requirement, allowing them to push unsigned commits, which violates the requirement to block unsigned commits even for admins. Option D is wrong because 'web commit signing' is a feature for automatically signing commits made via the GitHub web interface, but it does not enforce signing for commits pushed via Git CLI or other tools, and it does not block unsigned commits from being pushed.

Practice this question →
29
MCQmedium

Your team uses feature flags to manage feature releases. You need to ensure that a feature flag is automatically turned off for all users except the development team after a production incident. What is the best approach?

A.Create a separate branch with the feature disabled and deploy it.
B.Use a feature management system like Azure App Configuration with a targeting filter to enable only for the dev team.
C.Set an environment variable in the production environment to disable the feature.
D.Manually toggle the feature flag off in the app configuration.
AnswerB

Azure App Configuration's feature management with a targeting filter evaluates flags at runtime, allowing you to define a dynamic rule that enables the feature only for members of the dev team while all other users see the old behavior. This approach provides instant, per-audience control without code changes or redeployment, and you can modify the filter or turn the flag off immediately via the configuration service, making it the correct solution for safe feature releases.

Why this answer

Azure App Configuration's feature management system provides a built-in targeting filter that allows you to dynamically enable a feature flag for specific users or groups (e.g., the development team) while disabling it for all others. This approach supports real-time, no-deployment changes, which is essential for quickly responding to a production incident without modifying code or redeploying.

Exam trap

The trap here is that candidates may choose manual toggling (Option D) because it seems simplest, but they overlook the requirement to keep the feature enabled for the development team, which requires a targeting filter rather than a global off switch.

How to eliminate wrong answers

Option A is wrong because creating a separate branch and redeploying introduces unnecessary delay and risk, and it contradicts the purpose of feature flags, which are designed to toggle features without code changes or deployments. Option C is wrong because environment variables require a restart or redeployment to take effect, and they lack the granular user/group targeting needed to enable the feature only for the development team. Option D is wrong because manually toggling the flag off in the app configuration would disable it for all users, including the development team, which does not meet the requirement of keeping it enabled for the dev team.

Practice this question →
30
MCQmedium

You run the PowerShell command shown in the exhibit. The virtual network already exists. What is the outcome?

A.The virtual network's tags are updated to the specified tags.
B.The virtual network is deleted and recreated.
C.An error occurs because the virtual network already exists.
D.A new virtual network with a different name is created.
AnswerA

The New-AzResource cmdlet with the -Force switch and a fully qualified ResourceId performs an in-place update of the existing virtual network's properties. Since the command specifies the existing resource's ID and the -Force parameter overrides the default error for existing resources, only the tags are applied, leaving the virtual network itself untouched.

Why this answer

The `New-AzResource` cmdlet can create a new resource or update an existing resource. If the virtual network already exists, the cmdlet updates it, including applying the specified tags. The `-Force` parameter suppresses confirmation prompts and does not determine create vs. update behavior.

Exam trap

Candidates may assume `New-Az*` cmdlets always create new resources and error if the resource exists, but `New-AzResource` supports both create and update, so it updates the existing resource.

How to eliminate wrong answers

Option B is wrong because `New-AzVirtualNetwork -Force` does not delete and recreate the virtual network; it updates the existing resource in place. Option C is wrong because the `-Force` parameter suppresses the 'resource already exists' error, allowing the command to proceed with an update. Option D is wrong because the command uses the same name (from the `-Name` parameter) and does not create a new virtual network with a different name.

Practice this question →
31
MCQeasy

Your organization is adopting Azure DevOps to manage a new project for a client. The client requires that all work items be linked to Git commits and pull requests. Additionally, they want a dashboard that shows the team's velocity and work item trends. You are responsible for setting up the project and configuring the necessary integrations. The team uses a Scrum process with Sprints. You have already created the project and imported the work items. What should you do next to meet the client's requirements?

A.Create a custom tool using Azure Functions to parse commit messages and link work items. Use the built-in Charts feature in Azure Boards to create velocity charts.
B.Configure branch policies on the main branch to require linking work items. Set up the repository to automatically link commits to work items. Then create an Analytics view in Azure Boards to track velocity and work item trends.
C.Instruct developers to manually add work item IDs in commit messages and pull request descriptions. Create a custom dashboard using Power BI connected to Azure Boards.
D.Enable the setting 'Automatically link work items' in the repository settings. Configure a service hook to post commit details to a Teams channel for visibility.
AnswerB

This is the correct approach because Azure DevOps branch policies on the main branch can enforce that every pull request links to at least one work item, ensuring traceability at merge time. Enabling the repository setting to automatically link commits to work items (under Project Settings > Repositories > your repo > Policies > Automatically link work items) further links commits made directly to branches, covering both commit and PR scenarios. Creating an Analytics view in Azure Boards (via the Analytics tab or Power BI) provides customizable, trend-capable data on velocity and work item flow, which is more robust than built-in charts for tracking trends over time.

Why this answer

Configuring branch policies on the main branch to require linking work items ensures that all pull requests are linked to work items, and enabling automatic linking of commits to work items covers commits. Creating an Analytics view in Azure Boards provides the necessary velocity and work item trend dashboards. Option A is incorrect because Azure Functions are unnecessary—Azure DevOps provides built-in linking and Analytics.

Option C is incorrect because manual linking is inefficient and error-prone, and Power BI is not required. Option D is incorrect because it does not enforce linking on commits/PRs and does not address the dashboard requirement.

Practice this question →
32
MCQeasy

You see the above YAML pipeline trigger configuration in an Azure Pipeline. The repository uses Git Flow with branches: feature/new-feature, develop, release/v1.0, and main. A developer pushes a commit to the branch feature/new-feature. Which action will trigger the pipeline?

A.A CI trigger will start because the branch name starts with 'feature/'.
B.No trigger will start.
C.A PR trigger will start because the branch name contains 'feature'.
D.A CI trigger will start for all branches because batch is set to true.
AnswerB

The trigger configuration specifies only develop, release/* and main branches, so a push to feature/new-feature matches no included branch filter. Azure Pipelines therefore queues no run, leaving the feature branch build untouched until it merges into an included branch.

Why this answer

The YAML trigger configuration (shown) explicitly lists the branches that trigger CI. Since feature/new-feature is not included in the branch filter, a push to that branch does not start a CI run. PR triggers are separate and require an actual PR to be created, not a push.

Exam trap

Azure Pipelines triggers on all branches by default when no trigger block is specified. However, when a trigger block is present, only the listed branches trigger. Do not assume that a branch name containing 'feature' automatically triggers CI or PR.

In this question, the branch filter excludes feature/*, so no trigger starts.

How to eliminate wrong answers

Option A is wrong because a CI trigger only starts if the YAML pipeline explicitly includes a trigger section with 'feature/*' or the branch name matches a configured pattern; simply having a branch name starting with 'feature/' does not automatically trigger a pipeline. Option C is wrong because a PR trigger requires a configured 'pr' block in the YAML pipeline or a branch policy on the target branch; a push to a feature branch does not create a pull request, so no PR trigger fires. Option D is wrong because setting 'batch: true' only affects how multiple pending CI runs are batched when a trigger is already configured; it does not enable CI triggers for all branches.

Practice this question →
33
Multi-Selecteasy

Which TWO practices help improve the efficiency of code reviews? (Choose two.)

Select 2 answers
A.Keep pull requests small and focused on a single change.
B.Include multiple unrelated changes in a single pull request to reduce the number of PRs.
C.Assign as many reviewers as possible to ensure thoroughness.
D.Require that all team members review every pull request.
E.Use a code review checklist to ensure common issues are checked.
AnswersA, E

Small, single-purpose pull requests reduce cognitive load for reviewers, allowing them to understand context quickly and catch defects more effectively. They also simplify rollbacks, bisecting regressions, and reducing merge conflicts, which shortens cycle time and accelerates feedback.

Why this answer

Keeping pull requests small and focused on a single change (Option A) improves code review efficiency because it reduces cognitive load on reviewers, allowing them to understand and evaluate the change quickly without context-switching. Smaller PRs also enable faster feedback loops and easier rollback if issues are found, which aligns with DevOps principles of continuous integration and delivery.

Exam trap

The trap here is that candidates may think more reviewers or requiring all team members to review ensures quality, but in practice, it reduces efficiency and accountability, while small, focused PRs and checklists are proven to improve both speed and accuracy.

Practice this question →
34
MCQhard

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets used in workflows are automatically rotated every 90 days. What is the best approach?

A.Use OpenID Connect (OIDC) to authenticate.
B.Use a script that calls the GitHub API to update the secret and run it in a scheduled workflow.
C.Manually update the secrets every 90 days.
D.Store secrets as environment secrets and configure expiration.
AnswerB

Automating rotation with a scheduled GitHub Actions workflow that calls the GitHub API is the correct approach: the workflow can generate a new secret value, call the Secrets API (for repository or environment secrets), and update the secret on a defined cadence. This ensures secrets are rotated programmatically without manual intervention, aligning with the requirement for automated periodic rotation.

Why this answer

It uses the GitHub API within a scheduled workflow to programmatically rotate secrets, ensuring automation without manual intervention. This approach directly addresses the requirement for automatic rotation every 90 days by generating new secret values and updating the repository or organization secrets via the API.

Exam trap

The trap here is that candidates may confuse OIDC with secret management, assuming it provides rotation capabilities, when in fact OIDC only handles authentication without any secret lifecycle management.

How to eliminate wrong answers

Option A is wrong because OpenID Connect (OIDC) is used for authentication between GitHub Actions and cloud providers, not for rotating secrets stored in GitHub; it does not provide a mechanism to update or rotate secrets. Option C is wrong because manually updating secrets every 90 days is error-prone, not automated, and violates the requirement for automatic rotation. Option D is wrong because GitHub does not support environment secrets with a configurable expiration date; secrets do not have a built-in expiration feature, and this option misrepresents the platform's capabilities.

Practice this question →
35
MCQhard

You are reviewing a branch protection rule JSON for a GitHub repository. Developers complain that they cannot merge pull requests. What is the most likely cause?

A.The signed commit requirement is enforced but developers are not signing commits.
B.The required approving review count is set to 1.
C.Rebase merging is disabled.
D.Squash merge is the only allowed method.
AnswerA

The branch protection rule enforces signed commits, meaning any push containing unsigned commits will be rejected by GitHub. Because developers are not signing their commits, every push fails the signing requirement, which explains the blocked merges despite other settings being valid.

Why this answer

When a branch protection rule requires signed commits, any pull request containing unsigned commits will be blocked from merging. GitHub verifies commit signatures using GPG or S/MIME, and if developers are not signing their commits, the merge will fail regardless of other settings.

Exam trap

The trap here is that candidates often confuse branch protection rules that block merging (like required signed commits or required status checks) with settings that merely affect merge options (like disabling rebase or restricting merge methods), leading them to incorrectly choose options that do not actually prevent merging.

How to eliminate wrong answers

Option B is wrong because a required approving review count of 1 is a common and valid setting that allows merging once at least one reviewer approves; it does not block merging by itself. Option C is wrong because disabling rebase merging only removes one merge method option but does not prevent merging via other allowed methods like merge commit or squash merge. Option D is wrong because restricting to squash merge only limits the merge strategy but still allows pull requests to be merged as long as other conditions (like reviews or status checks) are met.

Practice this question →
36
MCQhard

Your organization uses GitHub for code and GitHub Actions for CI/CD. You want to enforce that all workflows include a 'codeql-analysis' job for security scanning. What is the best approach?

A.Create a workflow template and add it to the organization's workflow templates directory
B.Use branch protection rules to require a status check named 'codeql-analysis'
C.Create a custom GitHub Action that runs CodeQL and require it in all workflows
D.Use GitHub's required workflows feature to mandate specific workflows
AnswerD

GitHub's required workflows feature (in public beta for organizations) lets administrators designate a workflow file in a central repository that is automatically created in all repositories and cannot be removed or modified by users; this ensures CodeQL scanning runs consistently across every repository in the organization.

Why this answer

GitHub's required workflows feature allows organization owners to enforce that specific workflows (like a CodeQL analysis) run on all repositories in the organization, ensuring consistent security scanning without relying on templates or manual setup. This is the only approach that centrally mandates the workflow's presence and execution across all repositories, even if developers create new workflows or modify existing ones.

Exam trap

The trap here is that candidates often confuse 'workflow templates' (which are optional) with 'required workflows' (which are mandatory), or they mistakenly believe that branch protection rules can enforce the existence of a workflow job, when in fact they only enforce the outcome of a status check that may not even be configured.

How to eliminate wrong answers

Option A is wrong because workflow templates are optional starting points that developers can choose to use or ignore; they do not enforce that every repository includes the 'codeql-analysis' job. Option B is wrong because branch protection rules require a status check to pass on pull requests, but they do not ensure the workflow itself exists in the repository—developers could omit the CodeQL job entirely and the branch protection would have no effect. Option C is wrong because creating a custom GitHub Action does not enforce its inclusion in all workflows; developers would still need to manually add it to each workflow file, and there is no mechanism to require its use across the organization.

Practice this question →
37
MCQmedium

Your organization uses GitHub Copilot for pull request summaries. However, some developers report that the summaries are inaccurate. What should you do to improve the quality of Copilot-generated pull request summaries?

A.Encourage developers to write more detailed commit messages.
B.Ask developers to write clear, structured PR titles and descriptions.
C.Disable Copilot for pull requests and use manual summaries.
D.Provide a link to a documentation wiki in the PR description.
AnswerB

Copilot's PR summary generation directly leverages the pull request title and description as key context. Clear, structured descriptions—such as separate sections for motivation, changes, and testing—help the model produce more accurate, well-organized summaries, so better input directly yields better output.

Why this answer

GitHub Copilot for pull request summaries relies on the PR title and description as primary input to generate accurate summaries. Clear, structured titles and descriptions provide better context for the AI model, reducing ambiguity and improving summary quality. Detailed commit messages (Option A) are not directly used by Copilot for PR summaries, as it focuses on the PR-level metadata.

Exam trap

The trap here is that candidates may overestimate the role of commit messages (Option A) in Copilot's PR summary generation, when in fact the model primarily uses the PR title and description, not the commit history, to produce the summary.

How to eliminate wrong answers

Option A is wrong because commit messages are not the primary input for Copilot's PR summary generation; the model uses the PR title and description, not individual commit messages, to synthesize a summary. Option C is wrong because disabling Copilot is a reactive measure that avoids the problem rather than addressing the root cause of inaccurate summaries, and manual summaries are less efficient. Option D is wrong because providing a documentation wiki link in the PR description does not directly improve the quality of Copilot-generated summaries; the model does not parse external links for content, and the summary is based on the text within the PR title and description itself.

Practice this question →
38
MCQhard

Your organization uses GitHub Enterprise and requires that all commits to the main branch are signed with a GPG key verified by your organization. Developers are getting errors when pushing signed commits. What is the most likely cause?

A.The branch protection rule requires a linear history.
B.The developer's GPG key is not uploaded to their GitHub account or not verified.
C.The developer's email in the commit does not match any email on their GitHub account.
D.The developer's SSH key is not added to their GitHub account.
AnswerB

GitHub marks a commit as verified only when the signature was made by a GPG key that is uploaded to the user's GitHub account and associated with a verified email matching the commit's author. If the key is missing or not yet verified (e.g., the email is unconfirmed), GitHub cannot confirm the signature's authenticity, resulting in an unverified status.

Why this answer

GitHub requires that the GPG key used to sign a commit be uploaded to the user's GitHub account and marked as verified. If the key is missing or unverified, GitHub cannot confirm the signature's authenticity, causing the push to be rejected when branch protection rules enforce signed commits.

Exam trap

The trap here is that candidates often confuse authentication (SSH keys) with signing (GPG keys) or assume email mismatch is the primary cause, when in fact the core issue is the absence or unverified status of the GPG key itself.

How to eliminate wrong answers

Option A is wrong because a linear history requirement (e.g., via squash merging or rebase-only) does not affect GPG signature verification; it controls commit topology, not signing. Option C is wrong because while the commit email must match a verified email on the GitHub account for the signature to be associated, the error described is specifically about GPG key verification, not email mismatch—GitHub will still accept the signed commit if the key is valid, but the commit may show as 'unverified' if the email doesn't match. Option D is wrong because SSH keys are used for authentication (proving identity to GitHub), not for signing commits; GPG keys are used for signing, and SSH keys have no role in commit signature verification.

Practice this question →
39
Multi-Selecteasy

Your team follows trunk-based development. The main branch should always be deployable. Which two practices must you implement? (Choose two.)

Select 2 answers
A.Require manual approval for every pull request.
B.Use feature flags to manage incomplete work.
C.Keep branches short-lived (less than a day).
D.Create release branches for each deployment.
E.Use long-lived feature branches for each feature.
AnswersB, C

Feature flags (also called toggles) let teams merge incomplete or experimental code into main behind a runtime switch, decoupling deployment from feature release and enabling continuous integration. This keeps main always in a releasable state while incomplete work remains safely hidden from users until the flag is turned on.

Why this answer

In trunk-based development, the main branch must always be deployable. Feature flags (B) allow incomplete or work-in-progress code to be merged into the main branch without affecting production behavior, because the new functionality is toggled off until ready. Keeping branches short-lived (C) (typically less than a day) minimizes merge conflicts and ensures that changes are integrated quickly, reducing the risk of long-lived divergence that could break the main branch.

Exam trap

The trap here is that candidates often confuse trunk-based development with GitFlow or other branching strategies, leading them to select release branches (D) or long-lived feature branches (E) as valid practices, when in fact trunk-based development explicitly avoids these in favor of short-lived branches and feature flags.

Practice this question →
40
MCQeasy

A developer wants to automatically trigger a GitHub Actions workflow when a pull request is opened that targets the 'release' branch. Which trigger should they use?

A.pull_request_target: branches: [release]
B.push: branches: [release]
C.workflow_dispatch:
D.pull_request: branches: [release]
AnswerD

The pull_request trigger with branches: [release] is the standard and correct event for running a workflow whenever a pull request is opened, updated, or reopened against the release branch; it automatically validates the PR's merged result and meets the requirement precisely.

Why this answer

The `pull_request` trigger fires when a pull request is opened, and the `branches: [release]` filter restricts it to PRs targeting the `release` branch. `pull_request_target` also fires on PR open events but runs in the base repository context and is intended for workflows requiring secrets or write access, not as the general PR-open trigger. `push` only fires on pushes to branches, not on PR opens. Therefore, D is correct.

Exam trap

The trap is confusing `pull_request` with `push` or `pull_request_target`. `push` only fires when code is pushed, not when a PR is opened. `pull_request_target` does fire on PR activity, but it is designed for fork-safe workflows requiring secrets/write permissions; using it without that context is unnecessary and potentially unsafe. The question asks for a trigger when a PR is opened targeting a branch, so `pull_request` is the appropriate choice.

How to eliminate wrong answers

Option A is wrong because `pull_request_target` runs in the context of the base repository (not the merge commit) and is designed for secure workflows when PRs come from forks; it is not the standard trigger for a simple PR open event. Option B is wrong because `push` triggers on commits pushed to a branch, not when a pull request is opened. Option C is wrong because `workflow_dispatch` requires manual triggering via the GitHub UI or API and does not respond to pull request events.

Practice this question →
41
MCQeasy

Your team is migrating from on-premises TFS to Azure DevOps Services. You need to ensure that all existing work item history and attachments are preserved. Which migration approach should you use?

A.Export to Excel and import using Azure DevOps Office Integration
B.Manually recreate work items in Azure DevOps
C.Use the Azure DevOps Migration Tools (open source)
D.Use the Azure DevOps REST API to migrate work items
AnswerC

The Azure DevOps Migration Tools are open-source utilities built specifically for TFS-to-Azure DevOps migrations, using the Client Object Model to incrementally copy work items while preserving full revision history, attachments, links, and custom field/process template mappings. They support repeated, configurable v2 migrations with migration state tracking, making them the only listed option that can meet historical fidelity and traceability requirements.

Why this answer

The Azure DevOps Migration Tools (an open-source project) are specifically designed to migrate work items, including history, attachments, and links, from on-premises TFS to Azure DevOps Services. These tools handle the complex data transformations required to preserve the full fidelity of work item data, which is not possible with simpler export/import methods.

Exam trap

The trap here is that candidates may assume the REST API is sufficient for full migration, but it lacks built-in support for preserving history and attachments, requiring custom development that is more error-prone than using the purpose-built open-source tools.

How to eliminate wrong answers

Option A is wrong because Excel export/import via Office Integration does not preserve work item history, attachments, or links; it only transfers flat field data and is intended for bulk editing, not migration. Option B is wrong because manually recreating work items is error-prone, time-consuming, and cannot replicate the original history, timestamps, or attachments, leading to data loss and audit gaps. Option D is wrong because while the Azure DevOps REST API can create work items, it does not natively support migrating history or attachments in a single operation; you would need to write custom scripts to handle each element, which is far more complex and less reliable than using the dedicated migration tools.

Practice this question →
42
MCQhard

Your team uses GitHub Issues for tracking bugs and features. They want to automatically assign issues to the person who created the pull request that closes the issue. Which GitHub Actions workflow trigger and action should you use?

A.Use the 'pull_request' event and the 'actions/assign' action to assign the issue.
B.Use the 'issues' event with 'closed' type and an action that assigns the issue to the PR author.
C.Use the 'push' event and call the GitHub API to assign the issue.
D.Use the 'schedule' event to periodically check for closed issues and assign them.
AnswerB

The 'issues' event with type 'closed' is the appropriate trigger because GitHub Actions fires it synchronously when an issue is closed, providing the issue payload directly. A workflow can then invoke the GitHub API (or a purpose-built action) to inspect the issue timeline, locate the 'cross-referenced' event pointing to the pull request that closed it, and fetch that PR's author for assignment. This reacts in real time without polling and does not require external state tracking.

Why this answer

The 'issues' event with 'closed' type triggers a workflow when an issue is closed, and the 'actions/github-script' action can be used to assign the issue to the pull request author by querying the pull request that closed the issue. Option A is incorrect because the 'pull_request' event does not directly close issues; closing an issue is done via a commit or pull request merge. Option C is incorrect because the 'push' event is not related to issue closure.

Option D is incorrect because the 'schedule' event is time-based and does not respond to issue closures.

Practice this question →
43
MCQhard

Your organization uses GitHub Advanced Security. You need to ensure that secrets detected in pull requests automatically block the PR from merging. What should you configure?

A.Configure a custom secret scanning pattern and set the 'Block pull requests' property.
B.Configure a code scanning query to detect secrets.
C.Enable secret scanning and set the severity to critical.
D.Enable push protection for secret scanning.
AnswerA

The correct approach is to configure a custom secret scanning pattern with the 'Block pull requests' property enabled. When a pull request contains a secret matching the custom pattern, the PR check fails and the merge is blocked, directly satisfying the requirement to block PRs when secrets are detected.

Why this answer

GitHub Advanced Security allows you to create custom secret scanning patterns with a 'Block pull requests' property. When enabled, this property prevents a pull request from being merged if the custom pattern detects a secret in the PR's changes, directly meeting the requirement to automatically block merging on secret detection.

Exam trap

The trap here is confusing push protection (which blocks pushes) with the 'Block pull requests' property (which blocks PR merges), leading candidates to incorrectly select push protection as the solution for merge blocking.

How to eliminate wrong answers

Option B is wrong because code scanning queries detect code vulnerabilities and errors, not secrets; secret scanning is a separate GitHub Advanced Security feature that specifically identifies secrets like tokens and keys. Option C is wrong because enabling secret scanning with a severity setting only controls alert visibility or filtering, not merge blocking; there is no 'severity' property that blocks pull requests. Option D is wrong because push protection for secret scanning prevents secrets from being pushed to the repository in the first place, but it does not block a pull request from merging after the push has already occurred; the requirement is to block merging of PRs, not to block pushes.

Practice this question →
44
MCQeasy

A team uses Azure Boards and wants to ensure that work items moved to the 'Done' state require a completed code review. What should they configure?

A.Add a work item rule in the process template to require a code review for the 'Done' transition.
B.Modify the work item type definition to add a custom field for code review status.
C.Use a tag to mark work items as code-reviewed before moving to 'Done'.
D.Configure branch policies in Azure Repos to require pull request approvals.
AnswerA

A process template rule is the correct mechanism in Azure Boards because rules can enforce conditions on state transitions, such as requiring a custom 'Code Review' field to be completed before a work item is allowed to move to 'Done'.

Why this answer

Azure Boards allows you to define work item rules within the process template that enforce specific conditions on state transitions. By adding a rule to the 'Done' transition that requires a completed code review (e.g., via a custom field or check), you ensure work items cannot be moved to 'Done' without meeting that prerequisite. This is done through the inherited process customization in Azure DevOps, where you can add rules to the work item type's state transition.

Exam trap

The trap here is confusing Azure Repos branch policies (which enforce code review on pull requests) with Azure Boards work item rules (which enforce conditions on work item state transitions), leading candidates to select Option D instead of A.

How to eliminate wrong answers

Option B is wrong because simply adding a custom field for code review status does not enforce a requirement; it only stores data, and without a rule on the transition, the field can be left empty. Option C is wrong because tags are informal metadata and cannot enforce a mandatory check; they are not evaluated by work item state transitions. Option D is wrong because branch policies in Azure Repos control pull request approvals for code branches, not work item state transitions in Azure Boards; they operate at the repository level, not the work item tracking level.

Practice this question →
45
MCQeasy

Your team uses Azure Boards to track work items. They want to automatically update the state of a work item when a pull request is merged in Azure Repos. What should you configure?

A.Configure a work item template.
B.Define a branch policy to link work items and set automatic state transition.
C.Create a service hook subscription.
D.Set pipeline variables in the YAML file.
AnswerB

A branch policy in Azure Repos can require pull requests to be linked to work items and include an option to automatically transition the linked work item's state when the PR is merged. This is the built-in mechanism that updates Azure Boards work items without custom code, as the policy triggers the state change (e.g., from Active to Done) on successful completion of the merge. It directly satisfies the requirement, making it the correct choice.

Why this answer

Azure Repos branch policies allow you to require linked work items for pull requests and automatically transition the state of a linked work item (e.g., from 'Active' to 'Resolved') upon merge. This is configured in the branch policy settings under 'Automatically update work items' with a state transition rule, directly integrating Azure Boards with pull request completion.

Exam trap

The trap here is that candidates often confuse service hooks (which only send notifications) with the branch policy's built-in work item state transition feature, leading them to select option C instead of B.

How to eliminate wrong answers

Option A is wrong because work item templates only define default field values when creating a work item; they do not trigger automatic state changes on pull request merge. Option C is wrong because service hook subscriptions can send notifications (e.g., to Slack or Teams) when a pull request is merged, but they cannot directly update the state of a work item in Azure Boards. Option D is wrong because pipeline variables in YAML files control build/release pipeline behavior, not work item state transitions triggered by pull request merges.

Practice this question →
46
Drag & Dropmedium

Drag and drop the steps to configure a service hook for build completion notifications to Microsoft Teams into the correct order.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

To configure a service hook for build completion notifications to Microsoft Teams, you must first access the Service Hooks page in Project Settings. Then, you create a new subscription and select the Build completed event and Microsoft Teams as the service. Finally, you provide the webhook URL and test the subscription to ensure it works.

Practice this question →
47
MCQeasy

Your Azure DevOps project has multiple teams. You need to ensure that each team's board only shows work items assigned to that team. What should you configure?

A.Create a shared query for each team and pin it to the dashboard.
B.Assign each team a unique iteration path.
C.Set permissions on area paths to restrict access.
D.Configure team settings to set default area paths for each team.
AnswerD

Configuring team settings to set default area paths for each team is the correct, supported way to scope a team's board to only its work items. Each Azure DevOps team has a set of selected area paths; the board automatically filters to items assigned to those paths, so teams see only their own backlog and board items.

Why this answer

Team settings allow you to configure default area paths for each team, which ensures that the team board only displays work items assigned to those area paths. This effectively scopes the board to the team's work. Option A is wrong because shared queries are custom views and do not affect the default board filtering; they are used for reporting or dashboards, not for team board visibility.

Option B is wrong because iteration paths control sprint scheduling and timeboxes, not the visibility of work items on the board; area paths are used for team assignment. Option C is wrong because permissions on area paths control access levels (who can view or edit), not which work items appear on a team board; area path permissions do not filter the board content by team.

Practice this question →
48
Multi-Selecteasy

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

Select 2 answers
A.Create an inherited process from the default process.
B.Add custom work item types to an inherited process.
C.Configure rules to create new work item types.
D.Use team settings to define new work item types.
E.Modify the default process directly.
AnswersA, B

Azure Boards default processes (Agile, Scrum, CMMI, Basic) are read-only system processes. To customize, you must create an inherited process, which is a copy that allows adding custom fields, work item types, rules, and other process-level changes while retaining the original defaults.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse team settings (which manage visibility and defaults) with process-level customization, or mistakenly believe the default process can be directly edited, but Azure Boards enforces that only inherited processes are customizable.

Practice this question →
49
MCQhard

You are deploying an ARM template using the parameters file shown. The deployment fails with an error that the referenced secret cannot be found. What is the most likely cause?

A.The secret name in the parameters file does not match the actual secret name in Key Vault.
B.The Key Vault does not have an access policy granting the deployment user 'Get' secret permission.
C.The resource group 'rg-kv' does not exist.
D.The Key Vault is in a different region than the deployment.
AnswerA

An ARM template dynamic Key Vault reference resolves the secret by name exactly as specified in the parameters file. If the name contains a typo or does not match the secret's actual name in Key Vault (including case sensitivity for secret names), Azure returns a 'Secret not found' error, even if the Key Vault and access policies are correctly configured.

Why this answer

The error 'referenced secret cannot be found' directly indicates that the secret name specified in the parameters file does not match the actual secret name stored in Azure Key Vault. ARM template deployment uses the `reference()` function to retrieve the secret value at deployment time, and if the secret name is misspelled or incorrect, the deployment fails with this specific error.

Exam trap

The trap here is that candidates often confuse the 'secret not found' error with permission issues (Option B), but the error message specifically indicates the secret name mismatch, not an access policy problem.

How to eliminate wrong answers

Option B is wrong because an incorrect access policy would produce a different error, such as 'Access denied' or 'Forbidden', not 'secret cannot be found'. Option C is wrong because if the resource group 'rg-kv' did not exist, the deployment would fail with a resource group not found error, not a secret not found error. Option D is wrong because Key Vault region does not affect secret retrieval; ARM templates can reference Key Vaults in any region as long as the deployment user has appropriate permissions.

Practice this question →
50
Matchingmedium

Match each Azure DevOps service to its primary function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Agile planning and work tracking

Source control with Git or TFVC

CI/CD build and release automation

Manual and exploratory testing

Package management and sharing

Why these pairings

The correct matches are: Azure Boards for agile planning, Azure Repos for version control, Azure Pipelines for CI/CD, and Azure Artifacts for package management. Common confusions include swapping Boards with Repos or Pipelines.

Practice this question →
51
Multi-Selectmedium

Your team uses Azure DevOps with a Git repository. You want to enforce that all pull requests to main must have at least one reviewer from the 'security' group. Which two configurations are required? (Choose two.)

Select 2 answers
A.Configure automatic reviewers for the security group.
B.Add the security group as a required reviewer for the main branch policy.
C.Create a repository policy for the main branch.
D.Set the minimum number of reviewers to 1 in the branch policy.
E.Configure a branch protection rule in GitHub.
AnswersB, D

Adding the security group as a required reviewer in the Azure DevOps branch policy for main is the correct approach. This policy blocks pull request completion until a member of that group approves, making the security review a hard condition. The policy can also specify 'Required' reviewers, which prevents the PR from being completed without the mandated approval. This is the standard, declarative way to enforce that a specific team always signs off on merges to the main branch.

Why this answer

You can add the security group as a required reviewer in the branch policy. Option D is correct because setting the minimum number of reviewers to 1 ensures at least one reviewer is required. Option A is incorrect because automatic reviewers are not the same as required reviewers; they only suggest reviewers but do not enforce mandatory review.

Option C is incorrect because a repository policy applies to all branches, not just main, and does not enforce required reviewers for pull requests; a branch policy is needed. Option E is incorrect because a branch protection rule is a GitHub feature, not available in Azure Repos.

Practice this question →
52
MCQmedium

Your team uses GitHub Issues to track work. You want to enforce that all new issues include a specific set of labels based on the issue type (bug, feature, task). What is the most efficient way to achieve this?

A.Configure branch protection rules to require label assignments.
B.Use a CODEOWNERS file to auto-assign labels.
C.Create YAML-based issue forms in the .github/ISSUE_TEMPLATE folder.
D.Set up a repository ruleset to restrict label modifications.
AnswerC

YAML-based issue forms in the `.github/ISSUE_TEMPLATE` folder allow you to define structured issue templates with fields and a `labels:` key that automatically applies specified labels when the form is submitted, enforcing consistent label assignment at issue creation.

Why this answer

GitHub issue forms, defined as YAML files in the .github/ISSUE_TEMPLATE folder, allow you to create structured templates that can enforce required fields, including mandatory label assignments. When a user submits an issue via a form, the labels specified in the template are automatically applied, ensuring consistency without manual intervention or additional automation.

Exam trap

The trap here is that candidates confuse branch protection rules or repository rulesets (which manage code changes) with issue management features, or mistakenly think CODEOWNERS can assign labels instead of reviewers.

How to eliminate wrong answers

Option A is wrong because branch protection rules apply to pull requests and branches, not to issue creation; they cannot enforce label assignments on new issues. Option B is wrong because CODEOWNERS is designed to automatically request reviews from specific teams or individuals based on file paths in a repository, not to assign labels to issues. Option D is wrong because repository rulesets control permissions and restrictions on branches and tags, not on issue metadata like labels; they cannot enforce label assignments on new issues.

Practice this question →
53
MCQmedium

A developer pushes a commit to a branch named 'releases/v1.0'. What will happen?

A.The pipeline runs but fails because the branch name contains a dot.
B.The pipeline runs only if a pull request is created.
C.The pipeline runs automatically on the push.
D.The pipeline does not run because the branch is not main.
AnswerC

This outcome is expected because the repository's Azure Pipelines YAML defines a continuous integration (CI) trigger with a branch include filter such as `releases/*`. Since `releases/v1.0` matches that pattern, the push event automatically queues a new pipeline run, even without a pull request. The filter comparison uses glob-style matching on the full branch ref, and Azure Pipelines evaluates it at the time the push is received, making the run immediate and unattended.

Why this answer

Azure Pipelines, by default, triggers a pipeline run automatically on any push to any branch unless a trigger filter is explicitly configured. The branch name 'releases/v1.0' is valid and does not contain any characters that would prevent a trigger; dots are allowed in branch names. The pipeline will execute the steps defined in the YAML file for that branch.

Exam trap

The trap here is that candidates may assume branch names with dots are invalid or that pipelines only run on the main branch, but Azure Pipelines treats all branches equally by default and dots are perfectly valid in Git branch names.

How to eliminate wrong answers

Option A is wrong because Azure Pipelines does not restrict branch names containing dots; dots are valid characters in Git branch names and do not cause pipeline failures. Option B is wrong because a push to a branch triggers the pipeline automatically by default, regardless of whether a pull request is created; pull request triggers are a separate configuration. Option D is wrong because Azure Pipelines does not require the branch to be 'main' to run; pipelines can be configured to trigger on any branch, and by default they trigger on all branches.

Practice this question →
54
MCQmedium

Refer to the exhibit. You have this YAML pipeline in an Azure Repos repository. What is the expected behavior when a pull request is created from a feature branch to the main branch?

A.The pipeline runs twice: once on PR creation and once on merge.
B.The pipeline runs automatically on the PR to main, triggered by the pr trigger.
C.The pipeline runs when the PR is merged to main, triggered by the trigger block.
D.The pipeline does not run automatically on the PR; it must be triggered manually or via branch policy.
AnswerD

Without a PR trigger or branch policy configured in the YAML, the pipeline has no event that fires on pull request creation, so it stays idle until manually queued or invoked by a build validation policy.

Why this answer

The YAML pipeline shown does not include a `pr` trigger, and the `trigger` block only applies to CI (continuous integration) builds on branch pushes, not pull requests. Without a `pr` trigger, Azure Pipelines does not automatically run on pull request creation; it must be triggered manually or via a branch policy configured in the repository settings.

Exam trap

The trap here is that candidates often assume the `trigger` block also applies to pull requests, but in Azure Pipelines, `trigger` and `pr` are separate, and omitting `pr` means no automatic PR build occurs.

How to eliminate wrong answers

Option A is wrong because the pipeline does not have a `pr` trigger, so it will not run on PR creation, and the `trigger` block only triggers on merges to main, not on PR creation. Option B is wrong because the `pr` trigger is not defined in the YAML; without it, Azure Pipelines does not automatically run on PRs to main. Option C is wrong because while the `trigger` block would cause the pipeline to run on a merge to main, the question asks about behavior when a PR is created, not when it is merged.

Practice this question →
55
MCQhard

Your team uses Azure Boards with a custom process. You need to ensure that when a bug is closed, it automatically triggers a new release pipeline. Which approach should you use?

A.Configure a CI trigger in the release pipeline.
B.Add a release gate that checks for closed bugs.
C.Create an Azure Function that polls work items.
D.Set up a Service Hook from Azure Boards to Azure Pipelines.
AnswerD

Service Hooks in Azure Boards can subscribe to work item state change events and directly trigger an Azure Pipelines release, providing the native, event-driven integration needed to initiate a release when a bug is closed or another work item field is updated.

Why this answer

Service Hooks in Azure DevOps allow you to integrate Azure Boards with Azure Pipelines by subscribing to events like 'work item updated' or 'work item state changed'. When a bug is closed (state changed to 'Closed'), a Service Hook can automatically trigger a release pipeline, enabling event-driven automation without polling or custom code. This is the correct approach because it directly connects the work item state change to pipeline execution.

Exam trap

The trap here is that candidates often confuse CI triggers (which respond to code changes) with event-driven triggers from work items, or mistakenly think release gates can initiate pipelines rather than just gate ongoing releases.

How to eliminate wrong answers

Option A is wrong because a CI trigger in a release pipeline is designed to fire on code changes (e.g., a commit or pull request merge), not on work item state changes in Azure Boards. Option B is wrong because release gates are conditions evaluated during a release (e.g., checking for approvals or quality metrics), not triggers that initiate a new release; they cannot start a pipeline based on a work item being closed. Option C is wrong because creating an Azure Function to poll work items introduces unnecessary complexity, latency, and overhead compared to the native event-driven Service Hook mechanism, which is simpler and more reliable.

Practice this question →
56
MCQhard

Your team uses GitHub Actions for CI/CD. You need to enforce that all workflows use approved actions from a private marketplace. Which GitHub feature should you configure?

A.Use environment secrets to store allowed action names.
B.Require self-hosted runners.
C.Set the Actions permissions to 'Allow only specified actions'.
D.Configure OpenID Connect (OIDC) for Actions.
AnswerC

Setting Actions permissions to 'Allow only specified actions' creates an explicit allowlist at the repository or organization level, so only actions (and optional version constraints) that you add are permitted. Any action not on that list is blocked from running, which is exactly the enforcement mechanism needed for this policy.

Why this answer

The 'Allow only specified actions' setting in GitHub Actions permissions allows you to restrict workflow execution to a curated list of actions from a private marketplace or specific verified publishers. This enforces governance by preventing the use of unapproved actions, which is critical for compliance and security in enterprise CI/CD pipelines.

Exam trap

The trap here is that candidates often confuse runner-level controls (self-hosted runners) with action-level governance, mistakenly thinking that restricting where code runs also restricts what actions can be used.

How to eliminate wrong answers

Option A is wrong because environment secrets are used to store sensitive values like API tokens, not to enforce action allowlists; they cannot control which actions are permitted at the repository or organization level. Option B is wrong because self-hosted runners control where workflows execute, not which actions they can use; they do not provide a mechanism to restrict action selection. Option D is wrong because OpenID Connect (OIDC) is used for short-lived authentication tokens between GitHub Actions and cloud providers, not for managing action permissions or marketplace access.

Practice this question →
57
MCQeasy

You are setting up a CI/CD pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). Your team wants to automatically generate release notes from commit messages and work items. Which Azure DevOps feature should you use?

A.Copy Files task
B.Azure Repos Wiki
C.Azure Test Plans
D.Generate release notes task (from YAML pipeline)
AnswerD

The Generate release notes task in a YAML pipeline is purpose-built to automatically create a Markdown or HTML changelog from the build's associated commits, work items, and test results. It queries the build's metadata through Azure DevOps APIs and uses Handlebars or custom templates to render a formatted release-notes file, which can then be published as a pipeline artifact or copied to a target. This is the correct answer because it directly transforms source-control and work-item data into release documentation without manual authoring.

Why this answer

The Generate release notes task (from YAML pipeline) is the correct choice because it is specifically designed to automatically generate release notes from commit messages and work items in Azure Pipelines. This task parses the commit history and linked work items between two Git refs (e.g., tags or branches) and outputs a formatted markdown file, which can be published as an artifact or used in a release pipeline. It directly addresses the requirement to derive release notes from commits and work items without manual effort.

Exam trap

The trap here is that candidates may confuse the Generate release notes task with other documentation or file-copy tasks, but only this task is purpose-built to parse commit messages and work items into structured release notes within a YAML pipeline.

How to eliminate wrong answers

Option A is wrong because the Copy Files task is used to copy files from a source folder to a destination folder within the pipeline, not to generate release notes from commit messages or work items. Option B is wrong because Azure Repos Wiki is a documentation repository for project wikis, not a pipeline task that can automatically generate release notes from commits and work items. Option C is wrong because Azure Test Plans is a testing and quality management tool for manual and exploratory testing, not a feature for generating release notes from commit messages or work items.

Practice this question →
58
MCQeasy

You are designing a process for incident management. When a critical bug is reported, you need to automatically create a work item in Azure Boards and notify the on-call engineer via Microsoft Teams. Which Azure DevOps feature should you use?

A.Create a release pipeline that triggers on work item creation.
B.Set up a service hook that sends a message to Teams when a bug is created.
C.Configure a work item notification in Azure DevOps to email the on-call engineer.
D.Use a work item template to pre-populate the bug form.
AnswerB

Azure DevOps service hooks can subscribe to events such as 'work item created' and send an HTTP POST to a Teams connector or webhook. This immediately posts a message to a Teams channel when a bug is created, meeting the incident management requirement.

Why this answer

Service hooks are used to notify external systems (like Microsoft Teams) when an event occurs in Azure DevOps, such as a work item being created. They do not create the work item itself; they react to its creation. To automatically create the work item when a critical bug is reported, you would use a separate mechanism such as the Azure Boards REST API or an external integration.

Among the provided options, B is the correct feature for the Teams notification, but the explanation should clarify that the automated creation is handled outside the service hook.

Exam trap

The trap here is that candidates confuse 'work item notifications' (email-based) with 'service hooks' (webhook-based), assuming any notification feature can send to Teams, but only service hooks support direct integration with external chat systems like Teams or Slack.

How to eliminate wrong answers

Option A is wrong because a release pipeline triggers on code commits or build artifacts, not on work item creation, and is designed for deployment automation, not incident notification. Option C is wrong because work item notifications in Azure DevOps are limited to email alerts and cannot send messages to Microsoft Teams; they also require manual configuration per user and do not support dynamic on-call routing. Option D is wrong because a work item template only pre-populates fields in the bug form, it does not automate creation or notification; it is a static template, not a reactive automation mechanism.

Practice this question →
59
Multi-Selectmedium

Your team uses GitHub Discussions for Q&A. You notice that many questions go unanswered. Which two actions can improve response rates? (Choose two.)

Select 2 answers
A.Limit the number of discussion categories to one.
B.Automatically close discussions that are unanswered for 7 days.
C.Create a template for new discussions to guide users.
D.Assign a team of maintainers to monitor unanswered discussions.
E.Convert unanswered discussions to issues.
AnswersC, D

GitHub Discussions supports issue forms-style templates that enforce structured problem statements—such as expected behavior, reproduction steps, and screenshots—which reduces vague posts, surfaces necessary context upfront, and lets maintainers answer more efficiently, directly improving Q&A quality.

Why this answer

Option C is correct because creating a discussion template guides users to provide complete, structured information (such as version, environment, and steps to reproduce), which makes questions easier to understand and answer, thereby improving response rates. Option D is correct because assigning a team of maintainers to monitor unanswered discussions ensures there is clear ownership and accountability for responding, directly reducing the number of questions that go unanswered. Option A is not appropriate because limiting discussions to a single category reduces organization and makes it harder for the right experts to find relevant questions.

Option B is not appropriate because auto-closing unanswered discussions after 7 days would suppress legitimate questions rather than encourage answers. Option E is not appropriate because converting unanswered discussions to issues does not by itself increase response rates and may simply move the problem elsewhere.

Exam trap

The trap here is that candidates confuse 'closing' or 'converting' discussions with 'managing' them, but the correct approach is to improve the quality of the initial post (via templates) and ensure active monitoring (via assigned maintainers), not to remove or repurpose unanswered content.

Practice this question →
60
MCQeasy

Your team uses Azure Boards with a Kanban board. You want to limit the number of work items in the 'In Progress' column to prevent bottlenecks. What should you configure?

A.Column limits on the Kanban board
B.Branch policies
C.Backlog level settings
D.Work item rules
AnswerA

Column limits on the Kanban board cap the number of work items allowed in each column at a time, enforcing WIP limits and exposing bottlenecks so the team can swarm and balance flow. This is the correct mechanism for preventing overloading a stage in the process.

Why this answer

Column limits on the Kanban board directly enforce work-in-progress (WIP) constraints by capping the number of work items allowed in a specific column, such as 'In Progress'. This prevents bottlenecks by signaling the team to complete existing work before pulling new items, aligning with Lean and Kanban principles. Azure Boards supports this configuration through the board settings, where you can set a maximum limit per column.

Exam trap

The trap here is confusing process configuration (column limits) with code governance (branch policies) or automation (work item rules), leading candidates to select options that manage code or workflows rather than direct board constraints.

How to eliminate wrong answers

Option B is wrong because branch policies are used to enforce code quality and review requirements on pull requests in Azure Repos, not to limit work items on a Kanban board. Option C is wrong because backlog level settings define the hierarchy of work item types (e.g., Epics, Features, User Stories) and their visibility, but do not control column-level WIP limits. Option D is wrong because work item rules automate field updates or state transitions based on conditions (e.g., when a field changes), but they cannot enforce a numeric cap on items in a column.

Practice this question →
61
Multi-Selecteasy

Which TWO actions are recommended practices for improving communication within a DevOps team?

Select 2 answers
A.Create a shared team charter with communication norms.
B.Hold daily stand-up meetings.
C.Use separate documentation repositories for each team.
D.Send monthly status reports via email.
E.Remove team chat channels to reduce noise.
AnswersA, B

A shared team charter defines agreed-upon communication channels, response-time expectations, and escalation paths, reducing ambiguity and ensuring consistent, effective collaboration across the DevOps team. It establishes the shared norms needed for smooth information flow and alignment.

Why this answer

A shared team charter with communication norms establishes explicit expectations for how the team interacts, reducing ambiguity and fostering a culture of transparency and accountability. Daily stand-up meetings promote regular, synchronous communication, enabling quick updates, identification of blockers, and alignment on priorities. Both practices align with DevOps principles of collaboration and shared ownership.

In contrast, separate documentation repositories, monthly email reports, and removing chat channels hinder real-time collaboration and transparency.

Exam trap

The trap here is that candidates may dismiss daily stand-ups as 'agile-only' or think monthly reports are sufficient, but the AZ-400 exam emphasizes that DevOps teams need frequent, synchronous communication (like stand-ups) and a shared charter to align on norms, not just asynchronous reports or channel removal.

Practice this question →
62
MCQmedium

Your team uses GitHub Flow and wants to enforce that all pull requests require at least one approval before merging to the main branch. Which branch protection rule should you configure?

A.Require status checks to pass before merging
B.Restrict who can push to matching branches
C.Require a pull request before merging with at least 1 approval
D.Require linear history
AnswerC

This branch protection policy forces all changes to go through a pull request and, when 'Require approvals' is set to 1, prevents merging until at least one eligible reviewer has explicitly approved. It directly creates the desired human review gate before any code is integrated.

Why this answer

GitHub branch protection's 'Require a pull request before merging' setting, with 'Require approvals' set to at least 1, enforces that changes to main go through a PR with a reviewer sign-off. This directly matches the requirement for at least one approval before merge. Status checks, push restrictions, and linear history address different concerns and do not enforce human approval.

Exam trap

The trap is confusing 'require status checks' (automated CI gate) with 'require pull request approvals' (human review gate) — the question asks specifically for approval, so only the PR-with-approval rule satisfies it.

How to eliminate wrong answers

Option A is wrong because requiring status checks enforces CI passing, not human approval — it does not guarantee a reviewer signs off. Option B is wrong because restricting who can push limits who can write to the branch but does not require a pull request or approval. Option D is wrong because requiring linear history only enforces a merge strategy (no merge commits), not review approval.

Practice this question →
63
Multi-Selectmedium

Your team uses Azure DevOps and wants to enforce that all work items must be linked to a pull request before merging. Additionally, the pull request must be approved by at least two reviewers. Which two branch policies should you enable?

Select 2 answers
A.Automatically update work items
B.Require a minimum number of reviewers
C.Check for linked work items
D.Build validation
E.Comment resolution
AnswersB, C

Require a minimum number of reviewers enforces the approval threshold by blocking completion until the specified count of approvers signs off, satisfying the two-reviewer constraint. Configure it on the target branch's policy settings, setting the minimum to two. It does not address work item linking, so the separate "Check for linked work items" policy is also needed.

Why this answer

Option B (Require a minimum number of reviewers) is correct because this branch policy lets you set the required reviewer count, so configuring it to two enforces that a pull request must be approved by at least two reviewers before it can complete. Option C (Check for linked work items) is correct because this policy blocks pull request completion unless at least one work item is linked, directly enforcing that all work items be associated with a pull request before merging. Option A (Automatically update work items) only changes the state of linked work items after a merge and does not require any link to exist, so it does not enforce the linking requirement.

Option D (Build validation) triggers a build pipeline to validate the merge but has nothing to do with reviewer counts or work item links. Option E (Comment resolution) only requires that active pull request comments be resolved and does not enforce reviewer approvals or work item linkage.

Exam trap

The trap here is that candidates often confuse 'Automatically update work items' with 'Check for linked work items,' but the former only updates status after merge, while the latter enforces the link before merge.

Practice this question →
64
Multi-Selectmedium

You are designing a process for your Azure DevOps project to improve traceability between work items and code changes. You need to ensure that developers can easily navigate from a work item to related commits and pull requests. Which two actions should you perform? (Choose two.)

Select 2 answers
A.Enable the 'Link work items to commits' setting in the repository options.
B.Configure branch policies to require linked work items on pull requests.
C.Use the Azure DevOps CLI to manually link work items to commits after each push.
D.Create a custom work item query that lists all commits without linked work items.
E.Instruct developers to include work item IDs in commit messages using the #ID syntax.
AnswersB, E

Enforcing linked work items on pull requests via branch policies ensures that every pull request has at least one work item linked. This creates a link between the pull request and the work item, allowing easy navigation from the work item to the pull request. It improves traceability by making the association mandatory.

Why this answer

Including work item IDs in commit messages using #ID automatically links commits to work items. Enforcing linked work items on pull requests via branch policies ensures that pull requests are also linked. Together, these actions provide bidirectional traceability, allowing navigation from work items to commits and pull requests.

The other options are either non-existent, manual, or misapply features.

Exam trap

The trap here is assuming that a repository setting exists to automatically link work items to commits, when the linking actually depends on commit message syntax.

Practice this question →
65
MCQmedium

Your organization uses Azure DevOps Services. The development team uses feature branches and pull requests to merge changes into the main branch. You need to implement a policy that ensures every pull request has at least two approvals from the 'Senior Developers' group, and the build must succeed before merging. Additionally, any comment on the pull request must be resolved before merging. The policy should apply to the main branch only. You have already created the 'Senior Developers' group in Azure DevOps. What should you do?

A.Configure the team's settings to require approvals for all pull requests.
B.Add a branch policy on the main branch that requires a minimum of two reviewers from 'Senior Developers', a successful build, and that all comments are resolved.
C.Set up a build validation policy on the main branch that runs the pipeline and fails if comments are unresolved.
D.Configure the repository's pull request settings to require approvals and comment resolution.
AnswerB

A branch policy on main enforces these requirements at code push/PR validation time, and can restrict reviewer approvals to members of the Senior Developers group. The required number of reviewers, build validation, and comment resolution are all configurable checks in Azure DevOps branch policies.

Why this answer

Azure DevOps branch policies allow you to enforce specific requirements on pull requests targeting a branch. By configuring a branch policy on the main branch, you can require a minimum number of reviewers from a specific group (e.g., 'Senior Developers'), a successful build, and that all comments are resolved before merging. This directly meets all the stated requirements.

Exam trap

The trap here is that candidates often confuse repository-level settings (which are global) with branch-specific policies, leading them to choose options that cannot enforce group-based reviewer requirements or comment resolution on a single branch.

How to eliminate wrong answers

Option A is wrong because team settings for pull request approvals apply globally to all branches and cannot enforce a minimum number of reviewers from a specific group or require comment resolution. Option C is wrong because build validation policies only run a pipeline and check for build success; they cannot evaluate whether comments are resolved, as comment resolution is a separate policy setting. Option D is wrong because repository pull request settings are not branch-specific and cannot enforce a minimum number of reviewers from a specific group or require comment resolution; those are branch policy features.

Practice this question →
66
Multi-Selectmedium

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

Select 2 answers
A.Create a work item in Azure Boards for each build.
B.Export pipeline logs to Power BI for reporting.
C.Configure a Service Hook to post to a Slack channel.
D.Set up an email notification for specific events.
E.Use a release pipeline to send SMS via Twilio.
AnswersC, D

Azure DevOps Service Hooks can be configured to trigger an HTTP POST to a Slack incoming webhook when build events such as build.completed occur, which delivers a real-time status message to a Slack channel. This is a documented, first-class integration pattern that enables automatic build status notifications to your team.

Why this answer

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.

Exam trap

The trap here is that candidates may think any integration is valid if it's technically possible (like using a release pipeline to call Twilio), but the question asks for 'valid ways' meaning standard, built-in, or officially supported methods within Azure Pipelines.

Practice this question →
67
MCQhard

Your organization uses GitHub for source control and GitHub Actions for CI/CD. You need to implement a branching strategy where every commit to the main branch triggers a build and deployment to a staging environment, but only after a successful pull request review. Which GitHub Actions trigger should you use?

A.pull_request_target with branches: [main] and types: [closed]
B.push with branches: [main]
C.pull_request with branches: [main]
D.workflow_dispatch
AnswerB

The push trigger on main fires for every commit pushed directly to the branch, including fast-forward merges and direct pushes, without requiring a pull request, so it cannot enforce branch protection review policies. This means unreviewed changes can trigger the workflow, unlike pull_request_target which only fires on the closed event after a PR is merged.

Why this answer

The `push` trigger with `branches: [main]` runs on every commit pushed to main. When branch protection requires pull request reviews, commits only reach main through a reviewed and merged PR, so this satisfies the 'only after successful pull request review' condition. In contrast, `pull_request_target` with `types: [closed]` triggers for any closed PR, including those not merged, and does not map one-to-one to commits on main.

To use a PR event, you would need an additional condition like `if: github.event.pull_request.merged == true`, which is not mentioned.

Exam trap

The trap is confusing pull_request closed with merge. A PR can be closed without merging, so types: [closed] does not guarantee a successful review and merge. The correct event for new commits on a branch is `push`.

How to eliminate wrong answers

Option B is wrong because a `push` trigger on `main` would run the workflow on every commit to main, including direct pushes that bypass pull request review, which violates the requirement for a successful review before deployment. Option C is wrong because `pull_request` triggers on pull request creation or updates (e.g., opened, synchronized), not specifically after the PR is closed/merged; it would run during the review process, not after approval. Option D is wrong because `workflow_dispatch` is a manual trigger that requires someone to manually run the workflow, which does not automate the deployment after a pull request merge.

Practice this question →
68
Drag & Dropmedium

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

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

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.

Practice this question →
69
MCQmedium

A development team is transitioning from a centralized version control system to Git in Azure Repos. The team lead wants to ensure that the branch structure supports both feature development and hotfix releases, with the ability to stabilize a release candidate before final deployment. Which branch strategy should the team implement?

A.Use trunk-based development with short-lived feature branches that merge directly to main.
B.Use a forking workflow where each developer forks the repository and creates pull requests.
C.Use Git Flow with feature, develop, release, and main branches.
D.Use GitHub Flow with feature branches and pull requests directly to main.
AnswerC

Git Flow's dedicated release branch lets the team stabilise a release candidate while develop continues accepting feature work, and main plus hotfix branches handle urgent production fixes. This matches the stem's feature, hotfix, and stabilisation requirements.

Why this answer

Git Flow is the correct choice because it explicitly supports feature development, release stabilization, and hotfix releases through its structured branch hierarchy. The release branch allows the team to stabilize a release candidate before merging to main, while hotfix branches can be created from main for urgent fixes. This aligns perfectly with the requirement for both feature development and hotfix releases with release candidate stabilization.

Exam trap

The trap here is that candidates often confuse GitHub Flow (option D) with Git Flow, but GitHub Flow lacks the dedicated release and hotfix branches needed for the described release stabilization and hotfix requirements.

How to eliminate wrong answers

Option A is wrong because trunk-based development with short-lived feature branches merging directly to main does not provide a dedicated release branch for stabilizing a release candidate before final deployment, nor does it inherently support hotfix releases without disrupting ongoing development. Option B is wrong because a forking workflow is designed for open-source collaboration where contributors do not have direct write access, not for managing a structured branch strategy with release and hotfix branches within a single team's repository. Option D is wrong because GitHub Flow uses feature branches and pull requests directly to main, which lacks a separate release branch for stabilization and a dedicated hotfix workflow, making it unsuitable for scenarios requiring release candidate stabilization.

Practice this question →
70
MCQmedium

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?

A.Create a release pipeline that triggers on build failure and creates a work item.
B.Add the 'Create work item on failure' task to the build pipeline.
C.Configure a Service Hook to create a work item on build failure.
D.Use a PowerShell script in the pipeline to call Azure DevOps REST API.
AnswerB

The built-in 'Create work item on failure' task runs on build failure and automatically creates a work item, such as a bug, with the ability to assign it to the last committer. It is the intended, simplest solution because it requires no custom code, external service hooks, or additional Azure DevOps REST API calls.

Why this answer

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.

Practice this question →
71
Multi-Selecteasy

Which TWO actions help improve communication and collaboration in a distributed Azure DevOps team?

Select 2 answers
A.Maintain a shared wiki with project documentation and decisions.
B.Use multiple chat channels for each topic to organize discussions.
C.Use long email threads for decision-making to ensure full documentation.
D.Schedule daily stand-up meetings at a time that works for all time zones.
E.Avoid using pull request comments to reduce noise.
AnswersA, D

Maintaining a shared wiki centralizes project documentation and decisions in a single source of truth, with versioning and searchability that reduce redundant questions and ensure all team members, regardless of location or role, can access consistent, up-to-date information.

Why this answer

A shared wiki (e.g., Azure DevOps Wiki) provides a single source of truth for project documentation and decisions, accessible asynchronously—critical for distributed teams. Additionally, scheduling daily stand-up meetings at a time that works for all time zones ensures regular synchronous alignment and promotes collaboration. Multiple chat channels can fragment discussions, long email threads are hard to follow, and avoiding PR comments removes a key asynchronous review/discussion mechanism.

Exam trap

The trap here is that candidates may think multiple chat channels improve organization, but Azure DevOps emphasizes asynchronous, traceable communication via work items, pull requests, and wikis rather than real-time chat fragmentation.

Practice this question →
72
Matchingmedium

Match each Azure Test Plans concept to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Container for test suites and configurations

Group of test cases

Individual test with steps and expected results

Execution of a set of test cases

Why these pairings

In Azure Test Plans, a Test Plan is a container for test suites and test cases with settings. A Test Suite groups test cases. A Test Case has steps and expected results.

A Test Run is an execution of test cases. A Test Point is a test case with a specific configuration.

Practice this question →
73
MCQeasy

Your team wants to automatically assign a code reviewer from a specific security group when a pull request modifies files in a 'security' folder. Which Azure DevOps feature should you use?

A.Add a required reviewer policy for the branch.
B.Enable 'Automatically approve' for security group.
C.Code ownership policy with automatic reviewer assignment.
D.Branch policy with minimum number of reviewers.
AnswerA

A required reviewer policy on a branch mandates that at least one specified reviewer must approve every pull request targeting that branch, but it does not automatically assign a specific person based on the code changes; it simply enforces a generic approval requirement and cannot dynamically select a reviewer based on file paths or expertise.

Why this answer

Azure DevOps branch policies include a 'Required reviewers' policy that can be configured with a path filter. By specifying the path 'security' and adding the security group as required reviewers, the system will automatically add those reviewers to any pull request that modifies files in that folder. This is the built-in feature designed for this scenario.

A CODEOWNERS file can also suggest reviewers based on file paths, but it is not a branch policy and does not enforce that the review must occur.

Exam trap

Candidates may confuse CODEOWNERS with branch policies. The correct approach is to use a branch policy with required reviewers and a path filter, not the CODEOWNERS file alone.

How to eliminate wrong answers

Option A is wrong because a 'required reviewer policy' for a branch is a generic branch policy that mandates a specific reviewer for all pull requests targeting that branch, but it does not allow file-path-based conditional assignment like the security folder scenario requires. Option B is wrong because 'Automatically approve' is not a built-in Azure DevOps feature; it would bypass the review process entirely, which contradicts the goal of assigning a reviewer for security oversight. Option D is wrong because a branch policy with a minimum number of reviewers only enforces a count of reviewers, not the specific assignment of a reviewer from a particular security group based on file changes.

Practice this question →
74
MCQhard

You are a DevOps engineer for a large enterprise that uses GitHub Enterprise Cloud. The development team follows a GitFlow branching strategy with develop, feature, release, and main branches. The release branch is created from develop when a release is ready. After testing, the release branch is merged into main and then tagged. However, the team frequently forgets to merge release branches back into develop, causing hotfixes applied to main to not be in develop. You need to implement an automated process to ensure that after a release branch is merged into main, the changes are also merged back into develop. The solution must not require manual intervention and must handle merge conflicts gracefully by opening a pull request for conflict resolution. Which approach should you use?

A.Configure a branch protection rule on main that requires a pull request to merge into develop.
B.Create a GitHub Actions workflow that triggers on push to main, attempts to merge main into develop, and if conflicts occur, opens a pull request for manual resolution.
C.Create a scheduled workflow that runs daily and merges main into develop if there are no conflicts.
D.Set up a webhook in GitHub that calls an Azure Function to merge main into develop.
AnswerB

This workflow triggers on every push to main, uses a script or git commands to merge main into develop, and if conflicts arise, it creates a pull request for manual conflict resolution, providing timely automation while preserving human oversight for conflicting changes.

Why this answer

It uses a GitHub Actions workflow triggered on pushes to main to automatically merge main into develop. If conflicts arise, the workflow opens a pull request for manual resolution, ensuring no changes are lost and the process remains automated without manual intervention.

Exam trap

The trap here is that candidates may choose a scheduled workflow (Option C) thinking it is sufficient, but it fails to handle merges that occur between scheduled runs and does not gracefully manage merge conflicts by opening a pull request.

How to eliminate wrong answers

Option A is wrong because a branch protection rule on main requiring a pull request to merge into develop does not automate the merge process; it only enforces a policy, leaving the team to remember to perform the merge. Option C is wrong because a scheduled daily workflow may miss merges that occur between runs, and it does not handle conflicts gracefully by opening a pull request—it only merges if there are no conflicts, which could silently skip merges. Option D is wrong because setting up a webhook to call an Azure Function introduces unnecessary complexity and external dependencies, and it does not natively handle merge conflicts by opening a pull request within GitHub.

Practice this question →
75
MCQmedium

Refer to the exhibit. You are reviewing the branch policy configuration for the main branch in Azure DevOps. The policy requires a successful status check for 'continuous-integration/azure-devops' but not for 'security-scanner'. The minimum approver count is 0 and direct push is disallowed. What is the effect of this policy?

A.Developers can push directly to main without a pull request.
B.Pull requests require at least two reviewers.
C.Both status checks are required to pass.
D.Pull requests must pass the 'continuous-integration/azure-devops' check, but no reviewer approval is needed.
AnswerD

The branch policy lists 'continuous-integration/azure-devops' under required status checks, so a pull request cannot be merged until that CI check succeeds. However, the Minimum approver count is explicitly configured to 0, meaning no reviewer approval is part of the merge gate. Thus, the pull request is blocked only by the CI pipeline result, not by human code review.

Why this answer

The policy requires a successful status check for 'continuous-integration/azure-devops' but not for 'security-scanner'. With a minimum approver count of 0 and direct push disallowed, pull requests must pass the required CI check, but no reviewer approval is needed. This means the PR can be completed automatically once the CI check passes, without any human reviewer.

Exam trap

The trap here is that candidates assume 'minimum approver count = 0' means direct push is allowed, or that all listed status checks are required, when in fact only explicitly selected checks are mandatory.

How to eliminate wrong answers

Option A is wrong because direct push is disallowed, so developers cannot push directly to main without a pull request. Option B is wrong because the minimum approver count is 0, meaning no reviewer approval is required, not at least two. Option C is wrong because the policy explicitly requires only 'continuous-integration/azure-devops' to pass; 'security-scanner' is not required.

Practice this question →
Page 1 of 2 · 95 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Configure processes and communications questions.

Start 20-question session