Courseiva

CCNA Configure processes and communications Questions

38 of 113 questions · Page 2/2 · Configure processes and communications · Answers revealed

Practice these questionsDomain overviewAll questions
76
MCQeasy

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

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

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
77
MCQeasy

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
78
Multi-Selecteasy

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

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

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

Why this answer

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

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

Exam trap

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

Practice this question →
79
MCQmedium

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

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

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

Why this answer

It directly enforces the requirement for at least one approval before merging. 'Require a pull request before merging' must be enabled, and within that, 'Required approvals' should be set to 1. Option A (status checks) verifies CI passes, not approvals. Option B restricts who can push to branches, which is unrelated to approval requirements.

Option D (linear history) enforces a linear commit history but does not mandate approvals.

Practice this question →
80
Multi-Selectmedium

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

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

Enforces at least two approvals.

Why this answer

The 'Require a minimum number of reviewers' policy enforces that a pull request must be approved by at least two reviewers before it can be completed. Option C is correct because the 'Check for linked work items' policy ensures that every pull request is associated with a work item, which satisfies the requirement that all work items must be linked to a pull request before merging.

Exam trap

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

Practice this question →
81
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
82
Multi-Selectmedium

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

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

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

Why this answer

Service Hooks in Azure Pipelines allow integration with external services like Slack by triggering HTTP POST requests containing build status payloads. Additionally, Azure Pipelines provides built-in email notifications for specific events, such as build completion or failure, which can be configured to send status updates to stakeholders. Both are standard, officially supported features.

Options like using a release pipeline to call Twilio are possible but are not standard built-in methods, so they are not considered 'valid ways' in this context.

Exam trap

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

Practice this question →
83
MCQhard

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

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

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
84
Drag & Dropmedium

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

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

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

Why this order

The correct order to set up a self-hosted Azure DevOps agent on a Windows VM is: create a Personal Access Token (PAT) first, then download the agent package, then run config.cmd to configure and register the agent with Azure DevOps, and finally start the agent as a service. Option A reflects this sequence correctly. Other options either place download before PAT creation or start the agent before configuration, which would fail.

Practice this question →
85
MCQmedium

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

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

Git Flow provides release branches for stabilization before merging to main.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
86
MCQmedium

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

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

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

Why this answer

The 'Create work item on failure' task in Azure DevOps build pipelines automatically creates a bug work item and assigns it to the last committer of the failed build. Option A is incorrect because release pipelines are meant for deployment, not build-time tasks. Option C is incorrect because while Service Hooks can trigger on build failure, they require additional custom logic to assign the work item to the last committer, making it less straightforward.

Option D is incorrect because using a PowerShell script to call the REST API is more complex and error-prone compared to the built-in task.

Practice this question →
87
Multi-Selecteasy

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

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

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

Why this answer

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

Exam trap

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

Practice this question →
88
Matchingmedium

Match each Azure Test Plans concept to its definition.

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

Concepts
Matches

Container for test suites and configurations

Group of test cases

Individual test with steps and expected results

Execution of a set of test cases

Why these pairings

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

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

Practice this question →
89
MCQeasy

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

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

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
90
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
91
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
92
MCQmedium

Your team uses Azure Boards to manage work items. You need to ensure that when a work item is moved to 'Closed', all linked pull requests in Azure Repos are automatically completed. What should you configure?

A.Service hook to a custom Azure Function
B.Work item 'Pull Request' tab
C.Work item rule (state transition rule)
D.Branch policy on the target branch
AnswerA

A service hook in Azure DevOps can subscribe to a 'Pull request completed' or 'Pull request merged' event and invoke an HTTP endpoint, such as an Azure Function, which then uses the REST API to transition an Azure Boards work item to the appropriate state. This is a valid external automation approach because it is not a built-in feature and requires custom code to correlate the PR to work items and call the update.

Why this answer

Azure Boards service hooks can trigger a custom Azure Function when a work item state changes to 'Closed', and that function can complete linked pull requests via Azure Repos REST API. Option C is incorrect because work item rules (state transition rules) in Azure Boards do not have a built-in action to automatically complete pull requests; they only allow changes to work item fields, not external actions like completing PRs.

Practice this question →
93
Multi-Selecthard

Which THREE are benefits of using a monorepo with Azure Repos and CI/CD pipelines?

Select 3 answers
A.Granular repository-level permissions
B.Faster build times due to smaller codebase
C.Easier code sharing across projects
D.Simplified dependency management
E.Atomic cross-component commits
AnswersC, D, E

Shared libraries are in the same repo.

Why this answer

A monorepo enables easier code sharing across projects by allowing multiple teams to reference the same source files, libraries, and modules without needing separate package feeds or cross-repo synchronization. In Azure Repos, this means you can use common build artifacts and shared code directly within the same repository, reducing duplication and simplifying collaboration.

Exam trap

The trap here is that candidates confuse the benefits of a monorepo with those of a multi-repo setup, assuming that a monorepo inherently improves build times or permissions granularity, when in reality it often worsens both without specific pipeline optimizations like sparse checkout or path-based triggers.

Practice this question →
94
MCQhard

Your team uses trunk-based development with short-lived feature branches. You notice that code reviews often delay merging because reviewers are not available. What is the best way to reduce review latency while maintaining quality?

A.Enable auto-merge for pull requests that have passed all checks.
B.Require only one reviewer instead of two.
C.Create a separate review team that only handles pull requests.
D.Encourage pair programming or mob programming to review code in real-time.
AnswerD

Pair or mob programming embeds code review into the development process itself—another developer is continuously reviewing as the code is written, so there is no separate async review cycle to wait through at merge time. This directly reduces trunk-based development lead time and eliminates PR queue latency.

Why this answer

Pair programming or mob programming allows code to be reviewed in real-time during development, reducing the need for asynchronous pull request reviews and thus decreasing review latency while maintaining quality. Option A is incorrect because enabling auto-merge does not address reviewer availability; it still requires a review to be completed. Option B is incorrect because requiring only one reviewer may reduce review depth and quality.

Option C is incorrect because creating a separate review team can introduce new bottlenecks and does not solve the issue of reviewer unavailability.

Practice this question →
95
MCQhard

You are the DevOps lead for a financial services company. The company uses Azure DevOps Services with a single project containing multiple teams. The compliance team requires that all production deployments be approved by a change advisory board (CAB) member. Additionally, any deployment that changes a configuration value stored in Azure App Configuration must be audited. You have set up a release pipeline with a manual approval gate and a pre-deployment condition that runs a PowerShell script to validate configuration changes. However, the compliance team reports that some deployments bypassed the approval gate. Upon investigation, you find that developers with 'Edit release pipeline' permissions can modify the pipeline and remove the approval gate. You need to ensure that the approval gate cannot be bypassed by developers. You also need to ensure that any change to a configuration key is logged to Azure Monitor. What should you do?

A.Create a new service connection with limited permissions and require that all pipeline runs use it. Use an Azure Policy to audit configuration changes.
B.Configure environment-level approvals in the release pipeline and use Azure Policy to enforce that all deployments go through the environment. Use diagnostic settings on App Configuration to stream logs to Azure Monitor.
C.Implement a branch policy on the release pipeline's YAML file in the repository to require approval for changes. Use a webhook to send configuration change events to Azure Monitor.
D.Create a protected variable group that stores the approval gate configuration and set the pipeline to use it. Restrict edit permissions on the release pipeline to a security group that does not include developers. For configuration changes, use an Azure Resource Manager template with a deployment script that sends logs to Azure Monitor.
AnswerD

Protected variable groups allow you to store critical configuration like approval gate settings and restrict access through pipeline permissions, ensuring only authorized users can modify those gates, and referencing the variable group in the pipeline makes the approval logic itself subject to governance. Restricting edit permissions on the release pipeline to a security group that excludes developers prevents developers from altering the pipeline definition to remove or bypass the required approvals, which is essential for compliance. Using an Azure Resource Manager template with a deployment script that sends logs to Azure Monitor provides an auditable, infrastructure-as-code approach for configuration changes, capturing exactly what was changed and who deployed it, and seamlessly integrating with Azure Monitor for centralized log retention and alerting. This layered defense enforces mandatory approval gates and provides complete change auditability, satisfying financial services compliance requirements.

Why this answer

It addresses both requirements: restricting pipeline edit permissions to a security group that excludes developers prevents them from removing the approval gate, and using an ARM template with a deployment script that sends logs to Azure Monitor ensures configuration changes are audited. Protected variable groups secure sensitive configuration, but the key is permission separation and audit logging via ARM deployment scripts.

Exam trap

The trap here is that candidates assume environment-level approvals or branch policies alone are sufficient, but they overlook that users with 'Edit release pipeline' permissions can bypass these controls by modifying the pipeline definition.

How to eliminate wrong answers

Option A is wrong because creating a new service connection with limited permissions does not prevent developers with 'Edit release pipeline' permissions from modifying the pipeline to bypass the approval gate; Azure Policy audits Azure resources but does not enforce pipeline-level approval gates. Option B is wrong because environment-level approvals in a release pipeline can still be bypassed if developers have 'Edit release pipeline' permissions to remove the environment or its approvals; Azure Policy does not enforce pipeline deployment flows. Option C is wrong because a branch policy on the YAML file only protects changes to the pipeline definition, not runtime bypass of the approval gate, and webhooks for configuration change events do not replace the need for audit logging to Azure Monitor via diagnostic settings or deployment scripts.

Practice this question →
96
MCQmedium

During a sprint review, stakeholders complain that they don't receive notifications about completed work items. The team uses Azure Boards with a custom notification subscription. What is the most likely cause?

A.Email notifications are disabled at the organization level.
B.The subscription is set to deliver only to the team members.
C.The subscription's 'Deliver to' filter excludes stakeholders.
D.The subscription was automatically disabled after the first notification.
AnswerC

The 'Deliver to' filter in an Azure DevOps notification subscription controls exactly which roles, groups, or individuals receive the alert. If stakeholders are omitted from that filter, they will not get any notifications from this subscription even though the subscription itself is active and functioning, which directly explains the symptom.

Why this answer

The most likely cause is that the custom notification subscription's 'Deliver to' filter is configured to exclude stakeholders. In Azure Boards, notification subscriptions can have filters that restrict delivery to specific groups or roles, and if stakeholders are not included in the filter, they will not receive notifications even if the subscription is active. This directly addresses the complaint that stakeholders are not getting notified about completed work items.

Exam trap

The trap here is that candidates might assume the issue is a global email disable or an automatic subscription expiry, rather than understanding that Azure Boards notification subscriptions rely on explicit filter configurations that can exclude specific roles like stakeholders.

How to eliminate wrong answers

Option A is wrong because if email notifications were disabled at the organization level, no one would receive any notifications, not just stakeholders, and the team would likely be aware of a global setting change. Option B is wrong because the subscription being set to deliver only to team members would explain why stakeholders don't receive notifications, but the question specifies a custom subscription with a 'Deliver to' filter, and the correct filter-based exclusion is more precise; however, the 'Deliver to' filter is the mechanism that controls who receives the notification, and excluding stakeholders is the direct cause. Option D is wrong because Azure Boards notification subscriptions are not automatically disabled after the first notification; they remain active until manually disabled or deleted, and there is no built-in behavior that disables subscriptions after a single delivery.

Practice this question →
97
MCQhard

An organization uses Azure DevOps and wants to implement a change management process where all changes to the main branch require approval from a change advisory board (CAB). The CAB members are not part of the development team. How should they configure this?

A.Set branch permissions to restrict push to main and only allow CAB to approve via manual process.
B.Create a new branch policy on main that requires a minimum number of reviewers from a separate CAB group.
C.Use a service hook to notify CAB when a PR is created, and rely on manual approval.
D.Add the CAB as members of the development team and require team review.
AnswerB

A branch policy on main can require a minimum number of reviewers from a specific Azure DevOps group, such as a separate CAB. This ensures automated enforcement of the approval requirement, so pull requests cannot be completed without the mandated CAB reviews.

Why this answer

Azure DevOps branch policies allow you to enforce a minimum number of reviewers from a specific security group (e.g., a CAB group) on pull requests targeting the main branch. This ensures that every change to main requires explicit approval from CAB members, who are separate from the development team, without relying on manual processes or altering team membership.

Exam trap

The trap here is that candidates often confuse branch permissions (which control who can push) with branch policies (which control the review process), leading them to choose Option A instead of the correct policy-based solution.

How to eliminate wrong answers

Option A is wrong because restricting push permissions to main would block all direct pushes, but it does not enforce a review process; it would require a manual, non-auditable workflow outside Azure DevOps. Option C is wrong because a service hook only sends a notification when a PR is created; it does not enforce approval as a required gate, so changes could still be completed without CAB sign-off. Option D is wrong because adding CAB members to the development team would grant them unnecessary permissions and violate the requirement that CAB is separate from the development team; the team review policy would also apply to all team members, not specifically to CAB.

Practice this question →
98
MCQmedium

Your organization uses Microsoft Teams for communication. You want to send a notification to a Teams channel when a release pipeline fails. Which action should you configure?

A.Configure an email notification to the team.
B.Add the 'Microsoft Teams Notification' task to the pipeline.
C.Use Azure Monitor alerts to send to Teams.
D.Add a Service Hook endpoint for Teams.
AnswerB

This task sends customizable messages to Teams.

Why this answer

The 'Microsoft Teams Notification' task is a built-in Azure DevOps pipeline task that directly sends customizable notifications to a specified Teams channel when a pipeline event (such as failure) occurs. It requires no external configuration or additional services, making it the simplest and most appropriate choice for sending failure notifications from a release pipeline to Teams.

Exam trap

The trap here is that candidates confuse the 'Microsoft Teams Notification' task (a pipeline task) with a Service Hook subscription (a project-level integration), leading them to choose Option D even though it is not an action configured within the pipeline itself.

How to eliminate wrong answers

Option A is wrong because email notifications target individual or group email addresses, not a Teams channel, and require SMTP configuration; they do not integrate with Teams' messaging infrastructure. Option C is wrong because Azure Monitor alerts are designed for monitoring Azure resources and services, not for reacting to Azure DevOps pipeline events; they would require additional logic and webhook configuration to forward to Teams. Option D is wrong because a Service Hook endpoint for Teams is used to subscribe to Azure DevOps events (like release completion) and send them to a Teams channel via a connector, but it is not a pipeline task; it is configured at the project or collection level, not within the pipeline itself, and requires manual setup of a Teams incoming webhook.

Practice this question →
99
Multi-Selectmedium

Which TWO practices are recommended for managing secrets in Azure Pipelines?

Select 2 answers
A.Define secret variables in the pipeline UI and mark them as secret
B.Use environment variables in the build agent
C.Use Azure Key Vault to store secrets and map them as variables
D.Set secret variables in the YAML file with the 'secret' keyword
E.Store secrets as plain text in YAML variables
AnswersA, C

This keeps secrets out of the repository.

Why this answer

Azure Pipelines allows you to define secret variables in the pipeline UI (or via the Azure DevOps CLI) and mark them as secret. When marked as secret, the value is encrypted at rest, masked in logs, and never exposed to the pipeline YAML or output. This is the recommended practice for managing sensitive data like API keys or passwords directly within the pipeline.

Exam trap

The trap here is that candidates often confuse the ability to define variables in YAML with the ability to define secret variables in YAML, not realizing that Azure Pipelines explicitly prohibits storing secret values in YAML files to prevent repository exposure.

Practice this question →
100
MCQeasy

Your team wants to implement a policy that requires all pull requests to have at least one approval from a member of the 'Senior Developers' group before merging. Which mechanism should you use?

A.Add a CODEOWNERS file that designates 'Senior Developers' as owners of all files.
B.Create a branch policy on the target branch that requires a minimum number of reviewers from the 'Senior Developers' group.
C.Configure the pull request dashboard to display required reviewers.
D.Set up a build validation policy that runs a script to check approvals.
AnswerB

A branch policy on the target branch that requires a minimum number of reviewers from the Senior Developers group enforces that at least that many senior devs must approve before the PR can be completed, and you can also set it to block merge until their approvals are obtained.

Why this answer

Azure Repos branch policies allow you to enforce required reviewers on pull requests. By creating a branch policy on the target branch that requires a minimum number of reviewers from the 'Senior Developers' group, you ensure that no pull request can be completed without at least one approval from that group. This directly meets the requirement without relying on file-level ownership or external scripts.

Exam trap

The trap here is that candidates confuse CODEOWNERS (which only requests reviews) with a branch policy that enforces required approvals, leading them to choose option A even though it does not block merging without the required approval.

How to eliminate wrong answers

Option A is wrong because a CODEOWNERS file designates owners for specific files and automatically requests their review, but it does not enforce a minimum number of approvals from a group before merging; it only notifies them. Option C is wrong because configuring the pull request dashboard to display required reviewers is a UI customization that does not enforce any policy or block merging. Option D is wrong because a build validation policy runs a script to validate code quality or compliance, but it cannot enforce a specific number of human approvals from a group; it is meant for automated checks, not reviewer requirements.

Practice this question →
101
MCQhard

A company uses Microsoft Entra ID for identity. They want to enforce that all code changes in Azure Repos require a linked work item and a successful policy evaluation. Which branch policy should they configure?

A.Set the merge strategy to squash merge.
B.Enable 'Automatically include reviewers'.
C.Require work item linking in the branch policy.
D.Enforce a minimum number of comments.
AnswerC

Requiring work item linking in the branch policy is correct because it enforces that every pull request must have at least one linked work item before it can be completed. This creates an auditable trace from code changes back to the original requirement or task in Azure Boards.

Why this answer

Requiring work item linking in the branch policy ensures that every pull request (PR) in Azure Repos must be associated with a work item (e.g., user story, bug) before it can be completed. Combined with a successful policy evaluation (e.g., build validation, required reviewers), this enforces traceability and compliance for all code changes.

Exam trap

The trap here is that candidates may confuse branch policy settings that add metadata (like auto-include reviewers or comment counts) with policies that enforce mandatory linking or validation, leading them to select options that only facilitate review but do not enforce the required traceability.

How to eliminate wrong answers

Option A is wrong because setting the merge strategy to squash merge controls how commits are combined into the target branch (e.g., squashing all commits into one), but it does not enforce any requirement for linked work items or policy evaluation. Option B is wrong because enabling 'Automatically include reviewers' adds specific reviewers to a PR based on file paths or other criteria, but it does not enforce work item linking or policy evaluation. Option D is wrong because enforcing a minimum number of comments only requires a certain number of comments on a PR before it can be completed, which does not ensure work item linking or policy evaluation.

Practice this question →
102
Multi-Selecteasy

Which TWO features of GitHub Actions can be used to enforce code quality standards before merging?

Select 2 answers
A.Environments
B.Secrets
C.Branch protection rules with required status checks
D.Status checks
E.Repository variables
AnswersC, D

Branch protection rules with required status checks enforce quality by preventing a pull request from being merged until all specified status checks pass. This directly enforces that CI/CD workflows, including code quality jobs, succeed before changes are accepted into a protected branch.

Why this answer

Branch protection rules with required status checks (C) enforce that pull requests must pass specific GitHub Actions workflows (e.g., linting, testing, security scans) before merging. Status checks (D) are the actual workflow runs that report pass/fail to the pull request; when required, they block merging until all checks succeed. Together, they ensure code quality gates are met automatically.

Exam trap

The trap here is that candidates confuse 'Environments' (deployment gates) with 'branch protection rules' (merge gates), or assume 'Secrets' or 'Variables' can enforce quality, when they are purely for storing configuration data.

Practice this question →
103
MCQeasy

Your team uses GitFlow and wants to enforce that all feature branches are deleted after merging to develop. Which automation should you implement?

A.Enable the 'Automatically delete source branches' policy in the branch policy.
B.Use a post-merge script in the pipeline.
C.Train developers to delete branches manually.
D.Configure branch retention policies in Azure Repos.
AnswerA

Enabling 'Automatically delete source branches' in the branch policy for the target branch (e.g., main or develop) ensures that whenever a pull request is merged, the source feature branch is deleted automatically. This is a native Azure Repos policy that enforces cleanup without relying on developer action or custom scripts, making it the correct way to enforce branch cleanup in GitFlow.

Why this answer

The 'Automatically delete source branches' policy in Azure Repos branch policies automatically removes a feature branch once its pull request is completed into the target branch (e.g., develop). This directly enforces the GitFlow requirement without manual intervention or pipeline scripting, as it is a native repository-level setting.

Exam trap

The trap here is that candidates may confuse branch retention policies (which are time-based cleanup rules) with the immediate deletion policy on PR completion, or assume a pipeline script is necessary when a built-in repository policy already exists.

How to eliminate wrong answers

Option B is wrong because a post-merge script in the pipeline can delete branches, but it requires custom code, runs only on pipeline execution, and may fail if the pipeline is skipped or the merge happens outside a build (e.g., via the web UI). Option C is wrong because training developers to delete branches manually relies on human compliance, which is unreliable and not an automated enforcement mechanism. Option D is wrong because branch retention policies in Azure Repos control how long branches are kept before automatic cleanup (e.g., after a set number of days), not immediate deletion upon merge to develop.

Practice this question →
104
MCQhard

Your Azure DevOps pipeline uses a self-hosted agent pool. You notice that builds are queuing for a long time. What is the most effective way to reduce queue times without incurring additional costs?

A.Allocate more parallel jobs to the agent pool.
B.Reduce the number of steps in the pipeline.
C.Increase the agent specification (e.g., from DS2 to DS4).
D.Switch to Microsoft-hosted agents to get more parallelism.
AnswerA

Allocating more parallel jobs to the self-hosted agent pool increases the maximum number of pipeline runs that can execute concurrently on that pool. Each parallel job consumes one agent slot; with additional parallel job capacity, more builds or releases can run at the same time, directly addressing a bottleneck caused by concurrency limits.

Why this answer

Allocating more parallel jobs to the self-hosted agent pool allows multiple pipelines or jobs to run concurrently, directly reducing queue times. This is achieved by adjusting the parallelism setting in the agent pool's properties, which does not incur additional costs as you are already paying for the self-hosted infrastructure.

Exam trap

The trap here is that candidates often confuse improving individual job performance (faster agents or fewer steps) with increasing parallelism. If the pool has idle agents but the parallelism limit is set too low, increasing the limit is a free way to reduce queue times. However, if the pool is actually saturated (all agents busy), increasing the parallelism setting alone will not help; you would need to add agents or optimize the pipeline.

How to eliminate wrong answers

Option B is wrong because reducing the number of steps in the pipeline may slightly decrease the duration of each build, but it does not address the root cause of queuing—insufficient concurrent execution capacity. Option C is wrong because increasing the agent specification (e.g., from DS2 to DS4) improves the speed of individual job execution but does not increase the number of jobs that can run simultaneously, so queue times remain unchanged. Option D is wrong because switching to Microsoft-hosted agents typically incurs additional costs for parallel jobs beyond the free tier, and the question explicitly requires no additional costs.

Practice this question →
105
MCQeasy

Your organization wants to enforce that all commits to the main branch are signed using GPG or S/MIME. Which GitHub feature should you enable?

A.Use the GitHub API to check commit signatures after push.
B.Configure a branch protection rule that requires signed commits.
C.Enable the 'Include administrators' setting in branch protection.
D.Require SSH key authentication for all users.
AnswerB

Branch protection rules are evaluated during the push, and requiring signed commits causes GitHub to reject any push containing commits without a valid verified signature, thereby enforcing the policy before the commit is accepted. This is a preventive control at the repository level.

Why this answer

GitHub branch protection rules include a 'Require signed commits' setting that enforces all commits pushed to the protected branch must be signed with a verified GPG or S/MIME key. This ensures commit integrity and non-repudiation directly at the repository level, without requiring external scripts or API calls.

Exam trap

The trap here is that candidates confuse authentication (SSH keys) with commit signing (GPG/S/MIME), or assume that post-push API checks are equivalent to pre-merge enforcement.

How to eliminate wrong answers

Option A is wrong because using the GitHub API to check commit signatures after push is a reactive, custom workaround that does not prevent unsigned commits from being merged; it only audits them after the fact. Option C is wrong because the 'Include administrators' setting merely extends existing branch protection rules to admin users, but does not itself enforce signed commits. Option D is wrong because SSH key authentication only verifies the transport layer identity of the user, not the commit signature; commits can still be pushed without any signing.

Practice this question →
106
MCQeasy

A developer reports that their Azure DevOps pipeline is failing with 'Access denied' when trying to push to a protected branch. The branch policy requires a successful build and approval from the 'Code Owners' group. The developer is a member of 'Contributors' but not 'Code Owners'. What is the most likely cause?

A.The branch name contains invalid characters.
B.The pipeline's service principal lacks 'Create Branch' permission.
C.The developer lacks 'Contribute' permissions at the project level.
D.The developer is not in the 'Code Owners' group allowed to bypass the policy.
AnswerD

Azure DevOps branch policies provide a checkbox called 'Allow bypassing of branch policy' that can be granted to specific security groups, commonly a 'Code Owners' group. If the developer is not a member of that allowed group, the Git server rejects their push with an error like 'Denied by branch policy'. Because the push never reaches the remote, the CI pipeline never triggers, so the developer sees a failed build—rather than a missing 'Contribute' right or a pipeline service principal issue.

Why this answer

The branch policy requires membership in the 'Code Owners' group to push directly to the branch. The developer is not a member, so they get 'Access denied'. Option A (invalid characters) would cause a different error.

Option B (pipeline service principal lacking permission) is unrelated to the developer's push. Option C (lacking 'Contribute' permissions at project level) is less specific and would result in a different error; the error here is specifically due to branch policy enforcement.

Practice this question →
107
Multi-Selectmedium

Which THREE steps are essential when customizing an Azure DevOps process?

Select 3 answers
A.Use Hosted XML process model to customize.
B.Add custom fields to work item types.
C.Directly modify the 'Agile' system process.
D.Create an inherited process from an existing system process.
E.Add custom work item types to the process.
AnswersB, D, E

Adding custom fields to work item types is essential because it enables teams to capture, query, and report on project-specific data that is not covered by the default system fields, supporting more tailored workflow and metrics.

Why this answer

Customizing work item types by adding custom fields is a fundamental step in tailoring Azure DevOps processes to capture project-specific data. This is done through the inherited process model, which allows you to extend system processes without modifying the base definitions, ensuring upgrades and maintenance remain supported.

Exam trap

The trap here is that candidates often confuse the deprecated Hosted XML model with the current Inheritance model, or mistakenly think they can edit system processes directly, leading them to select options A or C instead of recognizing that only inherited processes support customization.

Practice this question →
108
MCQmedium

Your team uses Azure Boards and wants to automate work item state transitions when code is merged. What should you use?

A.Azure Pipelines with 'Update work item' task
B.Branch policy in Azure Repos
C.GitHub + Azure Boards integration with automatic work item linking
D.Power Automate with Azure DevOps connector
AnswerC

The GitHub + Azure Boards integration automatically links GitHub commits and pull requests to Azure Boards work items when the commit or PR title includes the work item ID (e.g., 'AB#123'). When configured, it can also transition the linked work item to a 'Done' or 'Closed' state upon the merge of the PR, providing the desired automation directly from the merge event without additional pipeline tasks or services.

Why this answer

GitHub + Azure Boards integration, when configured with automatic work item linking, automatically transitions work items (e.g., from 'Active' to 'Resolved') when a pull request is merged. This is achieved through the integration's ability to detect commit messages or PR descriptions containing 'AB#{ID}' or 'Fixes AB#{ID}' patterns, which trigger state changes defined in the Azure Boards project configuration.

Exam trap

The trap here is that candidates often confuse the 'Update work item' task in Azure Pipelines (Option A) as a direct merge-triggered automation, but it requires a pipeline run, whereas the GitHub integration provides a simpler, event-driven solution without additional pipeline overhead.

How to eliminate wrong answers

Option A is wrong because the 'Update work item' task in Azure Pipelines runs during a build or release pipeline, not directly when code is merged; it requires a pipeline trigger on merge, which adds unnecessary complexity and delay. Option B is wrong because branch policies in Azure Repos enforce code review and build validation, but they do not have built-in functionality to update work item states; they only require a linked work item, not state transitions. Option D is wrong because Power Automate with Azure DevOps connector can automate work item updates, but it is an external orchestration tool that requires custom flow design and polling or triggers, not a native, seamless integration like GitHub + Azure Boards.

Practice this question →
109
MCQhard

Your team uses a Git flow branching strategy with develop and release branches. You want to enforce that only release branches can be merged into main, and all merges into main require a successful deployment to a production-like environment. How should you implement this in Azure Pipelines?

A.Branch policy with required reviewers for main
B.Required status check for 'Check for linked work items'
C.YAML pipeline with environment approvals and branch filters on trigger
D.Build validation policy on main
AnswerC

Environment approvals enforce manual sign-off, and branch filters ensure only release branches trigger deployment.

Why this answer

A YAML pipeline with environment approvals can require manual approval for deployment to a production-like environment, ensuring only successful deployments from a production-like environment allow merges. Branch filters on triggers can restrict pipeline execution to only release branches, preventing other branches from triggering the pipeline that leads to main. Option A is wrong because branch policies with required reviewers only enforce PR review requirements, not deployment or branch source restrictions.

Option B is wrong because the 'Check for linked work items' status check ensures work items are linked but does not enforce branch restrictions or deployment validation. Option D is wrong because build validation runs on PR creation but does not enforce environment approvals or restrict the source branch to release branches only.

Practice this question →
110
MCQeasy

Your team uses GitHub Flow for feature development. A developer commits directly to the main branch without creating a pull request. Which practice should you enforce to ensure code quality and prevent direct commits?

A.Require a manual sign-off from a team lead after each commit.
B.Configure branch protection rules on the main branch to require pull request reviews before merging.
C.Set up a .gitignore file to prevent certain file types from being committed.
D.Add a CODEOWNERS file that automatically assigns reviewers to any changes.
AnswerB

Configuring branch protection rules on the main branch to require pull request reviews before merging is correct because GitHub branch policies natively block direct pushes and enforce PR-based collaboration. By requiring at least one approved review, you integrate quality checks into the merge workflow, ensuring feature changes go through review before reaching the main branch—a core mechanism in GitHub Flow.

Why this answer

Branch protection rules prevent direct commits to the main branch and require pull requests with reviews. Option A is incorrect because manual sign-off is not enforceable. Option C is incorrect because a .gitignore file does not block commits or enforce branch policies.

Option D is incorrect because a CODEOWNERS file alone does not block direct commits.

Practice this question →
111
MCQhard

Your Azure DevOps pipeline deploys to multiple environments. You want to require manual approval before production deployment, but only if the deployment originated from a branch other than 'main'. How can you implement this?

A.Set a pre-deployment approval on the production environment
B.Configure a deployment group with approval gates
C.Use a branch policy that requires approval for non-main branches
D.Add a manual validation task with a condition: ne(variables['Build.SourceBranch'], 'refs/heads/main')
AnswerD

Add a manual validation task with a condition: This is the correct method. However, the condition in the option uses `eq` instead of `ne`, which would trigger approval for main branches. When corrected to `ne(variables['Build.SourceBranch'], 'refs/heads/main')`, it pauses the pipeline for approval only when the source branch is not main, fulfilling the requirement.

Why this answer

To require manual approval only for non-main branches, add a manual validation task to the production deployment job with a condition checking that the source branch is not main: `ne(variables['Build.SourceBranch'], 'refs/heads/main')`. This pauses the pipeline and waits for approval. Pre-deployment approvals (A) cannot be conditional on branch, and deployment groups (B) are not for manual approval.

Branch policies (C) do not apply to pipeline stages.

Exam trap

The trap is to use the condition `eq` instead of `ne`, which would require approval on main branches instead of non-main branches. Pre-deployment approvals (option A) are unconditional and cannot be scoped to branch conditions.

How to eliminate wrong answers

Option A is wrong because a pre-deployment approval on the production environment applies to ALL deployments to that environment, regardless of the source branch, and cannot be conditionally applied based on branch. Option B is wrong because deployment group approval gates are used for controlling deployments to physical or virtual machines in a deployment group, not for conditional branch-based approvals in multi-environment pipelines. Option C is wrong because branch policies apply to pull requests and code changes in the repository, not to pipeline deployment approvals; they cannot gate a release pipeline's deployment step.

Practice this question →
112
MCQeasy

You need to automatically create a work item in Azure Boards when a GitHub issue is opened. What is the most efficient way to achieve this?

A.Install the GitHub + Azure Boards integration
B.Create a GitHub Action that calls Azure DevOps REST API
C.Use Azure Pipelines with a GitHub trigger
D.Configure a webhook in GitHub to Azure DevOps
AnswerA

The GitHub + Azure Boards integration is a native, two-way sync that automatically creates and links Azure Boards work items from GitHub commits, branches, and pull requests, and can be configured to create work items from GitHub issues. This is the official, supported method that requires no custom code and provides rich traceability between GitHub and Azure Boards.

Why this answer

The official GitHub + Azure Boards integration provides automatic two-way syncing between GitHub issues and Azure Boards work items. This requires minimal configuration and no custom code. Option B requires writing a GitHub Action and calling the Azure DevOps REST API, which is more complex.

Option C involves using Azure Pipelines, which is not designed for this purpose. Option D involves manually configuring a webhook, which is less streamlined than the integration.

Practice this question →
113
MCQmedium

Your company uses Microsoft Teams for collaboration. You want to send notifications to a Teams channel whenever a build pipeline in Azure Pipelines fails. Which approach should you use?

A.Configure an email subscription in Azure DevOps to send alerts to the Teams channel email address.
B.Set up a webhook in Azure DevOps to post to the Teams channel's incoming webhook URL.
C.Install the Azure Pipelines app for Microsoft Teams and subscribe the channel to pipeline notifications.
D.Use the 'Post to a Microsoft Teams channel' task in the pipeline.
AnswerC

The Azure Pipelines app for Microsoft Teams is the official integration that lets you subscribe a channel to pipeline events, such as completed builds and releases, failed jobs, and pending approvals. It uses the Teams bot framework to deliver structured, interactive cards and does not require custom code, webhook secrets, or manual service hook construction, making it the recommended and simplest setup.

Why this answer

The Azure Pipelines app for Microsoft Teams provides built-in integration to subscribe to pipeline events and send notifications to channels. Option A is incorrect because email subscriptions are separate. Option B is incorrect because webhooks require custom configuration.

Option D is incorrect because the Teams connector is deprecated in favor of the app.

Practice this question →
← PreviousPage 2 of 2 · 113 questions total

Ready to test yourself?

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

Start 20-question session