Courseiva

CCNA Configure processes and communications Questions

75 of 113 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

Azure Key Vault variable groups securely store and manage secrets outside the pipeline definition, with access control and auditing. Option D is correct because secret variables set in the pipeline UI or variable groups are masked in logs and not exposed in the YAML file. Option B is incorrect: enabling script access to the system token and printing secrets in logs is a security risk.

Option C is incorrect: storing secrets directly in the YAML pipeline file exposes them in the repository. Option E is incorrect: storing secrets as plain text in the repository is insecure.

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

Automated checks reduce manual review burden.

Why this answer

Enabling required status checks ensures that automated tests, builds, or other validation steps must pass before a pull request can be merged. This enforces quality gates directly in the branch protection rules, preventing broken code from being merged and reducing manual review overhead.

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

You applied the above branch policy to a GitHub repository. A developer tries to push a commit to the main branch that is signed with an S/MIME signature. What will happen?

A.The commit is rejected because S/MIME is not in the allowed signature types.
B.The commit is accepted because S/MIME is implicitly allowed.
C.The commit is accepted because it is signed.
D.The commit is rejected because the policy is in 'block' mode, which blocks all pushes.
AnswerA

Only GPG and SSH are allowed.

Why this answer

The branch policy in question is configured to allow only GPG or SSH signatures. S/MIME is not listed as an allowed signature type, so the commit is rejected. GitHub's branch protection rules enforce signature requirements based on the allowed signature types specified in the policy.

Exam trap

The trap here is that candidates may assume any signed commit is accepted, overlooking that GitHub's branch policy explicitly restricts which signature types are allowed, and S/MIME is not among them.

How to eliminate wrong answers

Option B is wrong because S/MIME is not implicitly allowed; only explicitly configured signature types (GPG or SSH) are permitted. Option C is wrong because the commit being signed does not guarantee acceptance; the signature type must match the allowed types in the policy. Option D is wrong because the 'block' mode does not block all pushes; it only blocks pushes that violate the specific policy rules, such as using an unapproved signature type.

Practice this question →
6
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 →
7
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 →
8
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 →
9
MCQhard

Your organization uses GitHub Enterprise and wants to enforce that all repositories have a specific issue template. What is the most scalable way to achieve this?

A.Create a global issue template in the organization settings.
B.Use a script to periodically check and add templates.
C.Create a repository template and require all new repos to use it.
D.Configure a CODEOWNERS file in each repository.
AnswerA

Global templates apply to all repositories.

Why this answer

GitHub Enterprise allows organization owners to create a global issue template by placing a `.github/ISSUE_TEMPLATE/` directory in the `.github` repository. This template is automatically applied to all repositories within the organization, ensuring consistency without manual intervention per repo. This is the most scalable approach as it centralizes enforcement at the organization level.

Exam trap

The trap here is that candidates often confuse repository templates (which only affect new repos) with organization-level templates (which apply globally), leading them to choose option C as a scalable solution.

How to eliminate wrong answers

Option B is wrong because using a script to periodically check and add templates is reactive, not proactive; it introduces latency, potential race conditions, and administrative overhead, and does not enforce the template at creation time. Option C is wrong because a repository template only applies to new repositories created from that template; existing repositories and those created without the template would not have the issue template, so it is not a scalable enforcement mechanism. Option D is wrong because a CODEOWNERS file is used to define individuals or teams responsible for code reviews, not to enforce issue templates; it has no mechanism to require or apply issue templates.

Practice this question →
10
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 →
11
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, branches, and pull requests creates end-to-end traceability from requirement to deployed code, enabling validation that completed work aligns with the work item and supporting auditability.

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 →
12
MCQmedium

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

A.Enable the 'Automatically update work item status' setting in the repository's pull request configuration.
B.Instruct developers to manually update the work item after merging.
C.Set up a branch policy that requires linked work items.
D.Create a service hook to call Azure DevOps REST API on pull request merge.
AnswerA

The 'Automatically update work item status' setting in a repository's Pull Request configuration is the native Azure DevOps mechanism that transitions linked work items to their resolved/closed state (e.g., Done) when the pull request is successfully merged. This server-side automation triggers on merge, uses the work item state mapping defined in the project's process configuration, and requires zero custom code or maintenance. For a team wanting automated status updates, this is the built-in, supported approach.

Why this answer

Azure Repos provides a setting in the repository's pull request configuration to automatically update linked work items to a specified state (e.g., 'Resolved') when a pull request is merged. This setting automatically updates work items that are linked via the work item ID in the pull request description. Option B is incorrect because it requires manual effort, which is not automatic.

Option C is incorrect because branch policies for linked work items only enforce linking, not automatic status updates. Option D is incorrect because although service hooks can be used to call REST APIs, Azure DevOps already provides a built-in mechanism for this scenario, making it unnecessary to create custom hooks.

Practice this question →
13
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 →
14
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 →
15
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 →
16
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 →
17
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 →
18
MCQmedium

Your organization is adopting Microsoft Entra ID for identity management. You need to configure Azure DevOps to trust tokens issued by Entra ID for service connections. Which authentication method should you use?

A.Service principal with client secret
B.Managed identity
C.OAuth 2.0 authorization code grant
D.Personal access token (PAT)
AnswerB

Managed identities provide an automatically managed identity in Entra ID for service connections.

Why this answer

Managed identity (Option B) is correct because it allows Azure DevOps to authenticate to Microsoft Entra ID without storing any credentials, using an identity automatically managed by Azure. This is the recommended approach for service connections when the Azure DevOps agent runs on an Azure resource (e.g., a VM or App Service) that supports managed identities, as it eliminates the need for secret rotation and reduces security risk.

Exam trap

The trap here is that candidates often confuse managed identity with service principal authentication, thinking that a client secret is required for any non-interactive authentication, but managed identity provides a secretless, automatically rotated credential that is specifically designed for Azure-hosted resources.

How to eliminate wrong answers

Option A is wrong because a service principal with a client secret requires manual management and rotation of the secret, which introduces security overhead and potential exposure, whereas the question asks for a method where Azure DevOps trusts tokens issued by Entra ID without storing secrets. Option C is wrong because OAuth 2.0 authorization code grant is an interactive flow designed for user delegation, not for automated service-to-service authentication in a CI/CD pipeline, and it would require user interaction or a refresh token. Option D is wrong because a personal access token (PAT) is a user-bound token that must be manually created and scoped, and it does not leverage Entra ID's token issuance for service connections; it is not a trust-based authentication method with Entra ID.

Practice this question →
19
MCQhard

Your team uses Azure DevOps and wants to implement a change management process where all production releases must be approved by a change advisory board (CAB) after the build is complete but before deployment. The approval must be recorded in the pipeline. What is the best approach?

A.Configure a branch policy requiring CAB member approval on pull requests.
B.Add a manual intervention task in the YAML pipeline.
C.Set up a service hook to send an email to the CAB and wait for a reply.
D.Create a release pipeline with a pre-deployment approval gate for the production stage.
AnswerD

Pre-deployment approvals allow designated approvers to approve before deployment, with full audit trail.

Why this answer

A release pipeline with a pre-deployment approval gate for the production stage enforces that a designated approver (or group, such as the CAB) must approve the release before deployment begins. The approval is recorded in the pipeline's audit trail, satisfying the requirement for documented change management. This approach aligns with Azure DevOps release management best practices for gating production deployments.

Exam trap

The trap here is that candidates often confuse manual intervention tasks (Option B) with formal approval gates, not realizing that manual intervention lacks the built-in approval recording and multi-approver workflow required for CAB sign-off in a change management process.

How to eliminate wrong answers

Option A is wrong because branch policies on pull requests control code merging into a branch, not post-build pre-deployment approvals; they do not gate the deployment pipeline after the build is complete. Option B is wrong because a manual intervention task in a YAML pipeline pauses the pipeline for an interactive input, but it does not provide a formal approval gate with recorded sign-off; it is typically used for manual steps like data entry, not for CAB approval workflows. Option C is wrong because a service hook that sends an email and waits for a reply is not a built-in approval mechanism; it requires custom logic to parse replies and does not integrate with Azure DevOps' native approval recording and audit features.

Practice this question →
20
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

Wiki provides persistent, searchable documentation.

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 →
21
Multi-Selecthard

Which TWO Azure DevOps features can be used to automate the process of updating work items when a build or release completes?

Select 2 answers
A.Pipeline task 'Update work item' from the Azure DevOps extension.
B.Service hooks to trigger an Azure function.
C.Release gates with work item update actions.
D.Work item query charts.
E.Branch policy with required reviewers.
AnswersA, B

The 'Update work item' pipeline task is a built-in task that directly modifies work items (e.g., change state, assignee) upon pipeline completion, making it a native automation feature.

Why this answer

The 'Update work item' pipeline task, available via the Azure DevOps Extension, directly modifies work items as part of a build or release pipeline, providing native automation. Option B is correct because service hooks can trigger external processes (e.g., an Azure function) that update work items via the REST API, offering flexibility for custom logic. Option C is incorrect because release gates are designed to evaluate conditions (e.g., quality checks) and do not include built-in actions to directly update work items.

Options D and E are unrelated; query charts are for visualization, and branch policies with required reviewers enforce code review, not work item updates.

Exam trap

The trap here is that candidates may confuse release gates (Option C) as a direct automation feature for work item updates. However, release gates only evaluate conditions and lack native work item update actions. The correct features are the 'Update work item' pipeline task (native) and service hooks (customizable via external triggers).

Practice this question →
22
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 →
23
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 →
24
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 provides traceability.

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 →
25
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

This ensures only changes to that path get additional review.

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 →
26
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 →
27
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 refine Copilot behavior.

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 →
28
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 →
29
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 →
30
MCQmedium

Refer to the exhibit. You are migrating repository policies from Azure Repos to GitHub. The JSON shows a branch protection rule you plan to apply to the main branch. A developer pushes a hotfix directly to main without a pull request. What happens?

A.The push is blocked because required status checks are not met.
B.The push is blocked because enforceAdmins is true.
C.The push succeeds because no push restriction is defined.
D.The push is rejected because lockBranch is false.
AnswerC

The push succeeds because no branch policy restricts direct pushes to this branch, so only the repository's standard Git permissions apply. As long as the user has Contribute permission on the repository, a direct push to a non-locked branch is permitted.

Why this answer

The branch protection rule includes required status checks and lockBranch (set to false), but it does not require pull requests before merging. In GitHub, direct pushes to a branch are only blocked if 'Require a pull request before merging' is enabled. Since that is not present here, the developer can push directly to main without a pull request, and the push succeeds.

Options A and B are incorrect because required status checks and enforceAdmins do not block direct pushes; they only affect pull request merges. Option D is incorrect because lockBranch set to false allows modifications.

Exam trap

Remember that 'Require a pull request before merging' is the only setting that restricts direct pushes. Status checks and enforceAdmins apply to pull requests, not direct pushes.

Practice this question →
31
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 →
32
MCQmedium

Your team uses Azure Boards to track work items. They want to automatically update the 'Remaining Work' field on a task when a developer completes a pull request linked to that task. Which Azure DevOps feature should you configure?

A.Define a pipeline variable to update the field during build.
B.Use a service hook to trigger an Azure Function that updates the work item.
C.Create a work item template that sets remaining work.
D.Configure a branch policy to automatically update work items on PR completion.
AnswerD

This is the correct feature to update work items when a PR is completed.

Why this answer

Azure DevOps branch policies include a setting to automatically update work items linked to a pull request upon completion. Specifically, under branch policy settings, you can enable 'Automatically update work items' which, when a PR is completed, sets the 'Remaining Work' field to zero (or another configured value) for linked tasks. This directly meets the requirement without custom scripting or external services.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing a custom integration (like service hooks) or misapply pipeline variables, missing the fact that Azure DevOps provides a native, configuration-only feature under branch policies to automatically update work items on PR completion.

How to eliminate wrong answers

Option A is wrong because pipeline variables are used to pass values during build or release execution, not to update work item fields in Azure Boards; they have no direct mechanism to modify work items. Option B is wrong because while service hooks can trigger an Azure Function to update work items, this is an overly complex, custom-coded solution when a built-in branch policy feature exists for exactly this purpose. Option C is wrong because work item templates are used to pre-populate fields when creating new work items, not to update existing work items automatically upon PR completion.

Practice this question →
33
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 →
34
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 →
35
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 →
36
MCQmedium

Your team uses Azure Pipelines to deploy a web app. They want to automatically roll back the deployment if the post-deployment smoke tests fail. What is the recommended approach?

A.Define an approval gate that requires manual sign-off after deployment.
B.Use a deployment gate with a monitoring tool that automatically initiates a rollback if health check fails.
C.Set up a manual intervention step in the pipeline to decide rollback.
D.Configure a release variable that toggles between deployment slots.
AnswerB

Gates can evaluate health and trigger rollback.

Why this answer

Azure Pipelines supports deployment gates that can integrate with monitoring tools (e.g., Azure Monitor, Application Insights) to evaluate health metrics after deployment. If the gate detects a failure (e.g., a smoke test health check fails), it can automatically trigger a rollback to the previous stable version, ensuring zero manual intervention and faster recovery.

Exam trap

The trap here is that candidates often confuse manual approval gates or manual intervention steps with automated rollback, failing to recognize that only a deployment gate with a monitoring tool can provide the continuous health evaluation and automatic rollback required for a fully automated recovery process.

How to eliminate wrong answers

Option A is wrong because an approval gate with manual sign-off does not automate rollback; it only pauses the pipeline for human approval, which defeats the goal of automatic rollback on smoke test failure. Option C is wrong because a manual intervention step requires a human to decide and execute the rollback, which is not automated and introduces delay and potential error. Option D is wrong because a release variable that toggles between deployment slots only switches traffic between slots but does not automatically trigger a rollback based on smoke test results; it requires manual or separate logic to detect failure and toggle the variable.

Practice this question →
37
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 →
38
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 →
39
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 →
40
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 push to feature/new-feature does not match any branch in the trigger include list, and the PR trigger only applies to PRs.

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 →
41
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 →
42
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 →
43
Multi-Selectmedium

Your organization uses GitHub and wants to ensure that all commits to the main branch are associated with a GitHub issue. Which three settings should you configure?

Select 2 answers
A.Require conversation resolution before merging
B.Require status checks to pass before merging
C.Allow force pushes
D.Require pull request reviews before merging
E.Allow deletions
AnswersB, D

Requiring status checks to pass before merging is correct because you can configure a custom status check that verifies a pull request references an issue, directly ensuring association.

Why this answer

Requiring status checks to pass before merging can include a custom status check that validates that a pull request is linked to a GitHub issue, directly enforcing association. Option D is correct because requiring pull request reviews before merging forces all changes to go through a pull request, which must be linked to a GitHub issue to satisfy the review process, ensuring traceability. Option A is incorrect because requiring conversation resolution only ensures comments are resolved, not that commits are associated with an issue.

Options C and E are irrelevant to issue association.

Exam trap

The trap here is that candidates may think 'Require conversation resolution before merging' ensures issue association, but it only resolves PR discussions. The correct combination involves status checks (custom) and pull request reviews to enforce linking.

Practice this question →
44
MCQhard

Refer to the exhibit. You are reviewing an Azure DevOps YAML pipeline. The pipeline is configured with a webhook trigger from GitHub for pull request opened events. However, the pipeline does not trigger when a PR is opened. What is the most likely cause?

A.The webhook subscription is not configured in GitHub.
B.The webhook name does not match the service connection.
C.The pipeline lacks an agent pool specification.
D.The webhook filter is incorrect; 'opened' should be 'created'.
AnswerA

The YAML defines the webhook, but GitHub needs to be configured to send events to Azure DevOps.

Why this answer

The most likely cause is that the webhook subscription is not configured in GitHub. Azure DevOps YAML pipelines with webhook triggers require an explicit webhook to be set up in the GitHub repository to send events (like pull request opened) to Azure DevOps. Without this subscription, Azure DevOps never receives the event, so the pipeline cannot trigger.

Exam trap

The trap here is that candidates assume the YAML webhook trigger definition alone is sufficient, but Azure DevOps requires the external webhook subscription to be manually configured in GitHub, which is a common misconfiguration in real-world scenarios.

How to eliminate wrong answers

Option B is wrong because the webhook name is not a required field for GitHub webhooks; Azure DevOps identifies the webhook via the service connection and the payload URL, not a name. Option C is wrong because the absence of an agent pool specification would cause a pipeline failure at runtime (e.g., 'No agent found'), not prevent the pipeline from triggering on a webhook event. Option D is wrong because 'opened' is the correct event type for a pull request being opened in GitHub's webhook payload; 'created' is not a valid pull request event type (it is used for branches or tags).

Practice this question →
45
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 →
46
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 →
47
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 →
48
MCQmedium

A team uses Azure Repos with a Git branching strategy that includes feature branches. They want to ensure that all feature branches are deleted automatically after the pull request is completed. What should they do?

A.Enable 'Automatically delete source branch' in the branch policy.
B.Enable 'Create a merge commit' option in the branch policy.
C.Configure branch retention policy in the pipeline to delete branches after build.
D.Create a work item to remind developers to delete branches after merge.
AnswerA

This deletes the source branch after the PR is completed.

Why this answer

Azure Repos branch policies include an 'Automatically delete source branch' checkbox. When enabled, the source branch (e.g., a feature branch) is automatically deleted once the pull request is completed (merged or abandoned). This enforces cleanup without manual intervention, directly meeting the requirement.

Exam trap

The trap here is that candidates may confuse pipeline retention policies (which manage build artifacts) with Git branch management, or assume that a manual work item is sufficient for automation, when Azure Repos provides a direct built-in setting for automatic branch deletion.

How to eliminate wrong answers

Option B is wrong because 'Create a merge commit' is a merge type setting that controls how commits are integrated, not a branch deletion mechanism. Option C is wrong because branch retention policies in Azure Pipelines control how long pipeline runs and artifacts are kept, not the deletion of Git branches in Azure Repos. Option D is wrong because creating a work item is a manual process that relies on developer discipline, not an automated enforcement mechanism.

Practice this question →
49
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 →
50
MCQmedium

Your team uses GitHub Issues for work tracking. You want to automate the creation of a new issue when a build pipeline fails in Azure Pipelines. Which action should you implement in the YAML pipeline?

A.Add a GitHub Action that triggers on pipeline completion.
B.Use a PowerShell task to call the GitHub Issues API.
C.Configure a Service Hook in Azure DevOps to GitHub Issues.
D.Add a task to create a work item in Azure Boards.
AnswerB

The GitHub API allows creating issues from any HTTP client.

Why this answer

Azure Pipelines does not natively support creating GitHub Issues directly from a YAML pipeline. Instead, you must use a PowerShell task (or a script task) to call the GitHub Issues API (POST /repos/{owner}/{repo}/issues) with an authentication token to create the issue when the build fails. This approach gives you full control over the issue content and is the standard way to integrate with GitHub Issues from Azure Pipelines.

Exam trap

The trap here is that candidates confuse Service Hooks (external configuration) with pipeline tasks, thinking a Service Hook can be defined inside a YAML pipeline, when in fact Service Hooks are configured outside the pipeline in Azure DevOps project settings and cannot be triggered conditionally based on pipeline failure within the YAML definition.

How to eliminate wrong answers

Option A is wrong because a GitHub Action triggers on GitHub events (e.g., push, pull request), not on Azure Pipelines completion; Azure Pipelines and GitHub Actions are separate platforms, and a GitHub Action cannot directly respond to an Azure Pipelines build failure. Option C is wrong because Service Hooks in Azure DevOps can send notifications to GitHub (e.g., create an issue) but they are configured in the Azure DevOps project settings, not in the YAML pipeline; the question asks for an action implemented in the YAML pipeline, so a Service Hook is an external configuration, not a pipeline task. Option D is wrong because adding a task to create a work item in Azure Boards would create an Azure Boards work item, not a GitHub Issue; the question specifically requires creating a GitHub Issue, not an Azure Boards item.

Practice this question →
51
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 →
52
Multi-Selecteasy

You are designing a process to manage work item tracking in Azure Boards. Your team uses a custom process based on the Agile template. You need to ensure that when a bug is resolved, the associated user story is automatically moved to the 'Done' state. Which TWO approaches can you use to achieve this?

Select 2 answers
A.Set up an 'Automate' level rule on the user story to move to 'Done' when all child bugs are resolved.
B.Modify the 'View' rule on the user story to automatically transition when child bugs are resolved.
C.Configure a rule on the work item type to automatically transition the user story when a linked bug is resolved.
D.Create a Power Automate flow triggered when a bug state changes to 'Resolved', then update the parent user story.
E.Use service hooks to call a custom webhook that updates the user story.
AnswersA, C

Automate levels in Azure DevOps Services (inherited processes) allow automatic state transitions based on child work item status.

Why this answer

Azure Boards supports 'Automate' level rules on work item types that can automatically transition a parent user story to 'Done' when all its child bugs are resolved. This rule is configured directly in the process settings under the user story work item type, leveraging the parent-child link hierarchy to enforce the state change.

Exam trap

The trap here is that candidates may confuse 'Automate' rules (which handle automatic state transitions based on linked work items) with 'View' rules (which only affect field visibility) or overcomplicate the solution by choosing external automation like Power Automate or service hooks when native process rules suffice.

Practice this question →
53
Multi-Selecthard

A team uses Azure Boards to manage work items. They want to automatically update the state of a work item when a related pull request is merged in Azure Repos. Which TWO actions should they configure to enable this integration?

Select 2 answers
A.Set up a webhook in Azure Repos to call Azure Logic Apps on pull request merge.
B.Add a branch policy that requires a linked work item for pull requests.
C.In the pull request description, use the #mention syntax to reference the work item.
D.Configure a Service Hooks subscription in Azure DevOps to send pull request merge events to Azure Boards.
E.Create an Azure Function that listens for pull request merge events and updates work items via the REST API.
AnswersB, C

This ensures every PR has a work item, and on merge, the work item state can be updated.

Why this answer

A branch policy that requires linked work items for pull requests ensures that every PR is associated with a work item. When the PR is merged, Azure Repos automatically updates the state of the linked work item (e.g., from 'Active' to 'Resolved') based on the default or configured transition rules. This integration is built into Azure DevOps without requiring external services.

Exam trap

The trap here is that candidates often confuse external automation (webhooks, Azure Functions, Logic Apps) with the native, built-in integration that Azure DevOps provides, leading them to select custom solutions instead of the simple branch policy configuration.

Practice this question →
54
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 →
55
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 →
56
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 →
57
Multi-Selectmedium

Which TWO approaches can you use to enforce consistent commit message conventions across your GitHub repositories?

Select 2 answers
A.Add a .gitattributes file
B.Use a GitHub Action to validate commit messages on push
C.Set the default branch to main
D.Create a repository rule that requires commit message patterns
E.Set up an issue template
AnswersB, D

A custom action can check commit messages and reject non-conforming pushes.

Why this answer

GitHub Actions can be configured with a workflow that triggers on `push` events to validate commit messages against a regex pattern, rejecting non-conforming commits. Option D is correct because repository rulesets (or branch protection rules) allow you to define required commit message patterns that must match before a push is accepted, enforced server-side. Both approaches enforce conventions consistently across all contributors.

Exam trap

The trap here is that candidates often confuse `.gitattributes` or branch naming with commit message enforcement, failing to recognize that only server-side rules or CI/CD actions can validate commit message content.

Practice this question →
58
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 →
59
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 →
60
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 →
61
Drag & Dropmedium

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

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 →
62
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 →
63
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 →
64
MCQeasy

Your team wants to include a manual validation step before deploying to production. Which Azure Pipelines feature should they use?

A.Pipeline decorators.
B.Environment checks.
C.Pre-deployment conditions with approval gates.
D.Post-deployment gates.
AnswerC

Pre-deployment conditions with approval gates define a manual approval step that must be completed by authorized reviewers before the deployment job is allowed to start, making it the correct way to include a manual validation step before deployment.

Why this answer

Pre-deployment conditions with approval gates allow you to require manual approval before a release is deployed to a specific stage, such as production. This is the correct feature because it explicitly pauses the pipeline before deployment and waits for designated approvers to validate the build, meeting the requirement for a manual validation step. Environment checks are a broader feature that can include both automated checks and manual approvals; however, the specific configuration for requiring manual approval in a release pipeline is pre-deployment conditions with approval gates.

Exam trap

The trap here is confusing environment checks (which may include both automated and manual checks) with the specific pre-deployment approval gate feature. Environment checks can include an 'Approvals' check, but the question asks for the feature that explicitly models the pre-deployment approval workflow, which is 'Pre-deployment conditions with approval gates'.

How to eliminate wrong answers

Option A is wrong because pipeline decorators are used to automatically inject additional steps (e.g., security scans) into every pipeline run, not to pause for manual validation. Option B is wrong because environment checks are automated evaluations (e.g., resource availability, compliance) that run before deployment, but they do not provide a manual approval mechanism. Option D is wrong because post-deployment gates run after the deployment to production has already occurred, so they cannot serve as a manual validation step before deployment.

Practice this question →
65
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 →
66
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 →
67
Multi-Selecthard

Your team uses Azure Boards and has several work item types (Epic, Feature, User Story, Bug, Issue). They want to enforce a rule that bugs can only be linked to Features, not directly to Epics. Which TWO actions should you perform?

Select 2 answers
A.Customize the Epic work item type to remove the 'Child' link to Bug.
B.Configure the Epic work item type to require a link to a Bug.
C.Use a work item rule to set the parent type to Feature when a Bug is created.
D.Add a rule to the Bug work item type that prohibits linking to Epics.
E.Customize the Bug work item type to remove the 'Parent' link to Epic.
AnswersA, E

This prevents users from linking an Epic to a Bug as a child.

Why this answer

By customizing the Epic work item type to remove the 'Child' link type to Bug, you prevent any Bug from being linked as a child of an Epic. This enforces the rule that Bugs can only be linked to Features. Option E is correct because by customizing the Bug work item type to remove the 'Parent' link type to Epic, you prevent a Bug from having an Epic as its parent, which directly enforces the desired linking restriction.

Exam trap

The trap here is that candidates often assume work item rules can enforce link restrictions, but Azure Boards rules only control field values and state transitions, not link types, so the correct approach is to customize the work item type definitions to remove the unwanted link relationships.

Practice this question →
68
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 →
69
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 →
70
MCQhard

Your organization uses GitHub and wants to implement a policy that requires all pull requests to be approved by at least two members of the 'security-team' team before merging. The 'security-team' team is a child team of 'engineering'. Which branch protection rule setting should you use?

A.Enable 'Dismiss stale pull request approvals when new commits are pushed'.
B.Use the 'Require pull request reviews before merging' rule and set 'Required reviewers' to the security team.
C.Require a minimum number of reviewers and set it to 2.
D.Require code owner review and add the security team as code owners.
AnswerB

This enforces approval from two members of the specified team.

Why this answer

'Require pull request reviews before merging' with 'Required reviewers' set to the security team. This configuration enables branch protection to enforce reviews from that specific team. To require approval from at least two members, you must also set the 'Required number of reviewers' to 2 within the same branch protection rule.

Option A is unrelated to reviewer requirements. Option C only sets a minimum number of reviewers without specifying which team, so it could allow any approver. Option D requires a CODEOWNERS file and only applies to file patterns owned by the team, not all pull requests.

Therefore, B is the foundational setting needed to achieve the policy.

Practice this question →
71
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 →
72
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

No automatic trigger for PRs to main; the pr trigger is only for develop.

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 →
73
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 →
74
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 →
75
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 →
Page 1 of 2 · 113 questions totalNext →

Ready to test yourself?

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

Start 20-question session