Courseiva

CCNA Configure processes and communications Questions

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

Secrets are stored in Key Vault and referenced securely in pipelines.

Why this answer

Option A is correct because variable groups linked to Azure Key Vault allow secure storage. Option C is correct because secret variables should be set in the pipeline UI or variable groups, not YAML. Option B is wrong because checking secrets into the repository is insecure.

Option D is wrong because logging secrets is a security risk. Option E is wrong because storing secrets in the YAML file exposes them in the repository.

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

Code owners provides automatic assignment. The scheduled workflow provides timely escalation without excessive overhead.

Why this answer

Option B is correct because 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

Requires approval from a code owner.

Why this answer

Option A is correct because 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
MCQmedium

Your team uses GitHub and wants to implement a policy that requires all pull requests to have a successful status check from a GitHub Actions workflow that runs unit tests. Additionally, the policy should require that the PR author is not allowed to merge their own PR. The repository is for a critical application and the main branch is protected. You need to configure the branch protection rules. Which combination of settings should you use?

A.Enable 'Require pull request reviews before merging' with 2 approvals, and enable 'Allow force pushes'.
B.Enable 'Require pull request reviews before merging' with 1 approval from a specific team, and disable 'Require status checks'.
C.Enable 'Require code owner review' and 'Require status checks to pass before merging'.
D.Enable 'Require pull request reviews before merging' with 1 approval, and enable 'Require status checks to pass before merging' with the unit test check required.
AnswerD

This ensures at least one approval from someone else (author cannot self-approve) and status checks pass.

Why this answer

Option D is correct because it combines two essential protections: requiring at least one approval prevents the PR author from merging their own PR (since the author cannot self-approve), and requiring the unit test status check to pass ensures that only code with successful automated tests can be merged into the protected main branch. This directly satisfies both policy requirements.

Exam trap

The trap here is that candidates may think 'Require code owner review' alone prevents self-merge, but it does not—a code owner can approve their own PR unless additional settings are applied, and it does not enforce a separate approval from another contributor.

How to eliminate wrong answers

Option A is wrong because enabling 'Allow force pushes' on a protected branch would allow bypassing the review and status check requirements, undermining the policy. Option B is wrong because disabling 'Require status checks' would allow merging without the unit test workflow passing, violating the requirement for a successful status check. Option C is wrong because 'Require code owner review' only mandates review from code owners, not a general approval, and does not prevent the PR author from merging their own PR (the author could be a code owner).

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

Option B is correct because 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 →
6
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 →
7
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 can enforce a minimum number of reviewers for pull requests.

Why this answer

Option C is correct because 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 →
8
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

This applies the policy only to the feature branch and allows BetaTeam to push directly.

Why this answer

Option D is correct because 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 →
9
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

Work item rules can require approval from a group.

Why this answer

Option A is correct because 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 →
10
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

Option A is correct because 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 →
11
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 enforces both requirements efficiently: the scan runs in CI, and branch policies ensure reviews. Using Copilot for commit messages improves traceability without overhead.

Why this answer

Option B is correct because 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 →
12
MCQmedium

Your team uses a monorepo in Azure Repos. You want to enforce that every PR to the main branch includes a work item link and a specific label. Which branch policy should you configure?

A.Comment requirements
B.Check for linked work items
C.Required status check (using a custom build pipeline)
D.Build validation
AnswerC

A custom build pipeline can verify work item links and labels, and the required status check enforces it.

Why this answer

Option C is correct because Azure Repos branch policies allow you to enforce 'Required status checks' that can invoke a custom build pipeline. This pipeline can run a script to verify that the PR contains a work item link and a specific label, and fail the check if those conditions are not met. The other options either lack the ability to enforce both conditions or are not designed for custom validation logic.

Exam trap

The trap here is that candidates often confuse 'Build validation' with 'Required status check', not realizing that 'Build validation' only ensures the code compiles and tests pass, while 'Required status check' is the policy type that allows you to enforce a custom pipeline that can validate arbitrary PR metadata like work item links and labels.

How to eliminate wrong answers

Option A is wrong because 'Comment requirements' only enforce that a minimum number of comments are posted on the PR, not that specific metadata like work item links or labels are present. Option B is wrong because 'Check for linked work items' only verifies that at least one work item is linked to the PR, but it cannot enforce the presence of a specific label. Option D is wrong because 'Build validation' triggers a build pipeline to run and pass, but it does not inherently check for work item links or labels unless you explicitly code that logic into the pipeline; however, the question asks for the branch policy to configure, and 'Required status check' is the policy type that allows you to require a custom pipeline check, whereas 'Build validation' is a separate policy that only ensures the build succeeds without the ability to enforce metadata conditions by itself.

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

Links provide traceability.

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). This practice ensures that tracking is effective by providing visibility into which code delivered a specific feature or fix, which is essential for auditability and impact analysis.

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

This built-in feature updates work item status on merge.

Why this answer

Option C is correct because Azure Boards supports automatically linking work items to pull requests and updating their status based on merge events. Option A is incorrect because branch policies do not update work items. Option B is incorrect because service hooks can trigger actions but are not the built-in mechanism for this scenario.

Option D is incorrect because manual linking does not automate status updates.

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

This workflow can run on pull_request and fail if no keyword found.

Why this answer

Option A is correct because 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 →
16
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

Regular refactoring helps manage and reduce technical debt.

Why this answer

Option A is correct because allocating time for refactoring in each iteration is a core practice of managing technical debt in a DevOps environment. This ensures that code quality issues are addressed incrementally, preventing debt from accumulating and reducing future maintenance costs. In Agile and DevOps workflows, this is often implemented as a 'refactoring budget' within sprint planning, directly aligning with continuous improvement principles.

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

Enables quick recovery without manual intervention.

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

Protection rules can require manual approval.

Why this answer

Option A is correct because 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 →
19
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 can send notifications to Teams via webhook when a release fails.

Why this answer

Option D is correct because 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 →
20
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 →
21
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

Option D is correct because 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 →
22
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

Option C is correct because Azure DevOps Wiki provides a persistent, searchable record of decisions and status. Option A is wrong because daily standups require synchronous attendance. Option B is wrong because email threads are hard to search and not integrated.

Option D is wrong because Slack huddles are real-time. Option E is wrong because meeting recordings are passive and not searchable.

Practice this question →
23
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, C

This task directly updates work item fields.

Why this answer

Options B and D are correct. Release gates can update work items based on release status, and the 'Update work item' task can set field values. Option A is wrong because service hooks are for external integrations.

Option C is wrong because branch policies are for PRs, not builds. Option E is wrong because work item queries are read-only.

Practice this question →
24
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 status check can validate commit messages and be required.

Why this answer

Option D is correct because 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 →
25
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

This removes workspace artifacts after each build, freeing space.

Why this answer

Option C is correct because enabling 'Clean after build' ensures workspace cleanup after each run. Option A is wrong because adding more agents doesn't free disk space. Option B is wrong as it only prevents concurrent builds, but the issue is disk space, not concurrency.

Option D is wrong because it cleans only at the beginning, not after.

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

Option C is correct because 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 →
27
MCQeasy

You are designing the communication strategy for a large team using Azure DevOps. The team uses a Kanban board and wants to automatically notify stakeholders when work items are moved to 'Done'. Which Azure DevOps feature should you use?

A.Use the built-in email subscription for work item changes.
B.Set up a pipeline notification for the work item.
C.Configure team alerts in the project settings.
D.Create a service hook subscription to send events to a webhook.
AnswerD

Service hooks can send notifications to external systems like Slack or email gateways.

Why this answer

Option D is correct because service hook subscriptions in Azure DevOps allow you to send real-time notifications to external systems (like webhooks) when specific events occur, such as a work item moving to 'Done'. This is the appropriate feature for automatically notifying stakeholders outside of Azure DevOps, as it integrates with custom endpoints or third-party services.

Exam trap

The trap here is that candidates often confuse built-in email notifications (Option A or C) with service hooks, not realizing that the requirement to 'automatically notify stakeholders' implies an external integration (webhook) rather than just internal email alerts.

How to eliminate wrong answers

Option A is wrong because built-in email subscriptions for work item changes are designed to notify individual users or groups within Azure DevOps via email, not to automatically notify external stakeholders through a webhook or other integration. Option B is wrong because pipeline notifications are triggered by pipeline events (e.g., build or release completion), not by work item state changes on a Kanban board. Option C is wrong because team alerts in project settings are for sending email notifications to team members about specific events (like work item updates), but they do not support sending events to external webhooks or custom endpoints.

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

Option B is correct because 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 →
29
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

This is the native way to notify Teams.

Why this answer

Option D is correct because 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 →
30
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

Option B is correct because 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 →
31
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 credential must be assigned the AcrPush role on the registry.

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 →
32
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 locks files, preventing concurrent edits and ensuring linear history.

Why this answer

Option C is correct because 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 →
33
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

No push restriction is set.

Why this answer

Option A is correct because the rule does not specify a restriction on direct pushes (no push restrictions). Option B is wrong because required status checks apply to pull requests, not direct pushes. Option C is wrong because lockBranch is false, so pushes are allowed.

Option D is wrong because enforceAdmins applies to admin overrides, not direct pushes.

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

This enforces two approvals from the specified team and makes analysis results available.

Why this answer

Option A is correct because 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 →
35
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

Option A is correct because branch policies with automation can update work items when PRs are completed. Option B is wrong because service hooks are for external integrations, not internal work item updates. Option C is wrong because work item templates only set initial values.

Option D is wrong because pipeline variables are for build/release, not work item updates.

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

Team settings allow per-team working days.

Why this answer

Option C is correct because 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 →
37
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

Approvals are a change management control.

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

This enforces signed commits for all users, including admins.

Why this answer

Option C is correct because 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 →
39
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

Option B is correct because 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 →
40
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

This allows dynamic control without redeployment.

Why this answer

Option B is correct because 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 →
41
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

-Force allows updating tags.

Why this answer

The `New-AzVirtualNetwork` cmdlet with the `-Force` parameter will update an existing virtual network if it already exists, rather than failing or recreating it. The `-Tag` parameter specifies the tags to apply, so the existing virtual network's tags are updated to the specified values. This behavior is consistent with Azure PowerShell's idempotent design for resource management.

Exam trap

The trap here is that candidates assume `New-Az*` cmdlets always create new resources and will error if the resource exists, but the `-Force` parameter changes this behavior to an update operation.

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

Branch policies enforce linking, and Analytics views provide the required dashboard data.

Why this answer

Option A is correct because it ensures all commits and PRs are linked to work items via policies, and the Analytics view provides velocity and trend data. Option B disables linking, contrary to the requirement. Option C only links PRs, not commits.

Option D uses manual linking which is error-prone and inefficient.

Practice this question →
43
MCQeasy

Your team is adopting GitHub Discussions for community Q&A. You want to ensure that only maintainers can create new discussion categories, but any authenticated user can create discussion posts within existing categories. How should you configure this?

A.Only maintainers can create categories; any authenticated user can create posts.
B.Enable discussions at the organization level and set permissions.
C.Configure branch protection to enforce maintainer-only posting.
D.Use a GitHub Action to approve discussion posts.
AnswerA

This is the default GitHub behavior.

Why this answer

Option A is correct because GitHub Discussions natively allows repository administrators to control category creation permissions independently from post creation permissions. By default, only users with 'triage' or higher access can create categories, while any authenticated user (including those without write access) can create posts within existing categories. This satisfies the requirement without additional configuration.

Exam trap

The trap here is that candidates may confuse branch protection rules (which apply to code) with discussion permissions, or assume that organization-level settings override repository-level category controls, when in fact category creation is a repository-level permission tied to the 'triage' role.

How to eliminate wrong answers

Option B is wrong because enabling discussions at the organization level does not provide granular control over who can create categories versus posts; it only enables the feature across repositories, and category permissions are managed per repository, not organization-wide. Option C is wrong because branch protection rules apply only to branches (e.g., enforcing pull request reviews or status checks), not to GitHub Discussions, which is a separate feature unrelated to code branches. Option D is wrong because GitHub Actions can automate workflows but cannot modify the built-in permission model for discussion categories; there is no action that can override the native role-based access controls for category creation.

Practice this question →
44
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 pipeline trigger configuration shown (not provided in text but implied by the answer) does not include a CI trigger for branches matching 'feature/*'. Without an explicit trigger block or a wildcard pattern like 'feature/*', only the default branch (typically 'main') triggers a CI pipeline on push. Since the push is to 'feature/new-feature' and no PR trigger is configured, no pipeline run is initiated.

Exam trap

The trap here is that candidates assume any push to a branch with a name containing 'feature' will automatically trigger a CI or PR pipeline, but Azure Pipelines requires explicit trigger configuration for non-default branches.

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 →
45
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 PRs are easier and faster to review.

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

Automated rotation via API.

Why this answer

Option B is correct because 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 →
47
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 3 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
AnswersA, B, D

Ensures discussions are resolved, promoting issue linking.

Why this answer

Option A is correct because requiring conversation resolution before merging ensures that all comments on a pull request are resolved before the PR can be merged. This is a branch protection rule that enforces that discussions tied to the PR (which should reference a GitHub issue) are fully addressed, indirectly ensuring the commit is associated with an issue. Option B is correct because requiring status checks to pass before merging can include a check that verifies the commit message contains an issue reference or that a linked issue exists.

Option D is correct because requiring pull request reviews before merging forces all changes to go through a PR, which must be linked to a GitHub issue, ensuring traceability.

Exam trap

The trap here is that candidates may think 'Require status checks' is unrelated to issue association, but it can be configured with a custom status check that validates issue references, making it a valid and necessary setting alongside PR reviews and conversation resolution.

Practice this question →
48
MCQhard

Your Azure DevOps environment uses Microsoft Entra ID for authentication. You need to ensure that users from a partner organization can access only a specific Azure Boards project without being added to your tenant as guests. What should you do?

A.Issue OAuth 2.0 tokens to the partner users.
B.Invite the partner users as Microsoft Entra B2B guests and assign them to the project.
C.Configure Microsoft Entra ID identity protection to allow the partner IP range.
D.Create service principals for the partner users.
AnswerB

B2B collaboration allows external users with specific permissions.

Why this answer

Option B is correct because Microsoft Entra B2B collaboration allows you to invite external users as guests, granting them access to specific resources like an Azure Boards project without fully adding them to your tenant. This meets the requirement of restricting access to only that project while avoiding permanent guest accounts in your directory.

Exam trap

The trap here is that candidates may confuse OAuth 2.0 tokens or service principals with user access, not realizing that B2B guest invitations are the correct mechanism for granting external users limited access without full tenant membership.

How to eliminate wrong answers

Option A is wrong because OAuth 2.0 tokens are used for delegated authorization and authentication flows, not for granting direct access to Azure DevOps projects; they require the user to already be authenticated in the tenant. Option C is wrong because Microsoft Entra ID Identity Protection is a security tool for detecting risks like compromised identities, not for granting access based on IP ranges. Option D is wrong because service principals are non-human identities used for automated processes or applications, not for individual user access to Azure Boards.

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

Option B is correct because the 'trigger' is set to 'none', which disables all triggers except the webhook? Actually, 'trigger: none' disables the CI trigger but does not affect resource triggers like webhooks? Wait, in Azure DevOps YAML, 'trigger: none' disables the CI trigger, but resource triggers (like webhooks) still work. However, the pipeline might not be set to use the correct webhook? Actually, the most likely cause is that the webhook is not properly configured in GitHub to send events to Azure DevOps. Option A (Incorrect filter) is possible but the filter looks correct.

Option C (Missing agent pool) would cause a runtime error. Option D (Webhook name mismatch) would cause connection issue but the exhibit shows 'GitHubPR' as name.

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

Unsigned commits will be rejected.

Why this answer

Option A is correct because 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 →
51
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

Required workflows enforce that designated workflows are present in all repositories.

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

Better input leads to better Copilot output.

Why this answer

Option B is correct because 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 →
53
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

Option A is correct because 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 →
54
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

The key must be uploaded and verified for GitHub to recognize the signature.

Why this answer

Option B is correct because 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 →
55
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

Option B is correct because 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 →
56
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 allow merging incomplete features safely.

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

Option A is correct because 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 →
58
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

Option B is correct because 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 →
59
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

This triggers on PRs targeting the release branch.

Why this answer

Option D is correct because the `pull_request` trigger fires when a pull request is opened, and the `branches: [release]` filter restricts it to PRs targeting the `release` branch. This matches the developer's requirement exactly: automatically trigger a workflow when a PR is opened against `release`.

Exam trap

The trap here is confusing `pull_request` with `pull_request_target` or `push`, where candidates mistakenly think a push to the branch or a fork-safe trigger is needed, but the question explicitly asks for a trigger when a pull request is opened, not when code is pushed.

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

These tools are designed to preserve full history, attachments, and links.

Why this answer

Option C is correct because 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 →
61
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 triggers when an issue is closed, and the action can fetch the closing PR author.

Why this answer

Option D is correct because the 'issues' event with 'closed' type can trigger a workflow that uses the 'actions-ecosystem/action-add-assignees' action to assign the issue to the PR author. Option A is incorrect because 'pull_request' events do not directly close issues. Option B is incorrect because 'push' events are not related to issue closure.

Option C is incorrect because 'schedule' events are time-based.

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

Option B is correct because 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 →
63
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

This will fail the PR check when a secret is detected.

Why this answer

Option A is correct because 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 →
64
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

Work item rules enforce conditions on state transitions.

Why this answer

Option A is correct because 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 →
65
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

Branch policies can require linked work items and automatically transition their state when a pull request is merged.

Why this answer

Option B is correct because 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 →
66
Drag & Dropmedium

Drag and drop the steps to configure a static route on a Cisco IOS router into the correct order.

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

Steps
Order

Why this order

Static routes require global config mode and must specify the destination network, subnet mask, and next-hop address or exit interface.

Practice this question →
67
MCQeasy

Your team uses Azure Repos and wants to enforce that every commit message includes a work item ID. Which policy should you configure?

A.Repository settings to restrict file paths.
B.Branch policy to require a minimum comment length.
C.Branch policy to require linked work items.
D.Pre-push Git hook.
AnswerC

This policy ensures pull requests link to work items.

Why this answer

Option C is correct because Azure Repos branch policies include a 'Require linked work items' setting that enforces every commit in a pull request to be associated with a work item. This ensures commit messages reference a work item ID, as the policy blocks pull requests without linked work items, directly meeting the requirement.

Exam trap

The trap here is that candidates confuse client-side Git hooks (like pre-push) with server-side branch policies, assuming hooks can enforce requirements centrally, but hooks are optional and can be skipped by developers using --no-verify.

How to eliminate wrong answers

Option A is wrong because restricting file paths controls which files can be changed in a branch, not commit message content or work item linking. Option B is wrong because requiring a minimum comment length only enforces a character count in commit messages, not the presence of a work item ID. Option D is wrong because a pre-push Git hook is a client-side script that can be bypassed by developers and is not centrally enforced via Azure Repos policies.

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

This filters the board to show only work items in the team's area paths.

Why this answer

Option B is correct because team configurations define which area paths and work items appear on the team board. Option A is wrong because work item queries are for custom views, not default board filtering. Option C is wrong because area paths are used in team configuration, not a separate setting.

Option D is wrong because iteration paths control sprints, not board visibility.

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

Inherited processes allow customization.

Why this answer

Option A is correct because 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 →
70
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

Approval gates require manual approval 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.

Exam trap

The trap here is confusing environment checks (automated) with approval gates (manual), leading candidates to select option B because they think 'checks' include manual validation, but environment checks are strictly automated and cannot require human intervention.

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

Typo or mismatch causes not found.

Why this answer

Option A is correct because 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 →
72
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

These are the five main Azure DevOps services.

Practice this question →
73
MCQhard

Your organization uses GitHub Actions for CI/CD. A workflow that deploys to production uses a secret stored in GitHub Actions secrets. The secret is exposed in the logs due to a debug step. What is the most effective way to prevent future exposure?

A.Remove the debug step from the workflow.
B.Use the ::add-mask:: command in the workflow to mask the secret in logs.
C.Delete the compromised secret and create a new one.
D.Enable secret scanning and push protection for the repository.
AnswerD

Secret scanning detects and blocks secrets from being exposed in logs or commits.

Why this answer

Option D is correct because enabling secret scanning and push protection for the repository proactively detects and blocks secrets (including GitHub Actions secrets) from being exposed in logs or commits. This is the most effective long-term solution as it prevents future exposure at the platform level, rather than relying on manual remediation or masking that can be bypassed.

Exam trap

The trap here is that candidates often focus on immediate remediation (deleting the secret or masking logs) rather than the preventive, platform-level control that secret scanning and push protection provide, which is the most effective way to prevent future exposure.

How to eliminate wrong answers

Option A is wrong because simply removing the debug step does not prevent future exposure if other steps or workflows inadvertently log secrets; it is a reactive, not preventive, measure. Option B is wrong because the ::add-mask:: command only masks the secret in the current workflow run's logs after it has already been used, and it does not prevent the secret from being exposed in other runs or if the secret value changes; it also requires manual addition to every workflow. Option C is wrong because deleting and recreating the secret only addresses the immediate compromise but does not prevent the same mistake from happening again with the new secret; it lacks a preventive control.

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

Option A is correct because 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 →
75
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

Required reviewers enforce specific groups.

Why this answer

Option B is correct because you can add the security group as a required reviewer. Option D is correct because you need to set the minimum number of reviewers to 1. Option A is wrong because a branch policy is needed, not a repository policy.

Option C is wrong because automatic reviewers are separate from required reviewers. Option E is wrong because a branch protection rule is a GitHub concept, not Azure Repos.

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

Ready to test yourself?

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

Start 20-question session