Courseiva

CCNA Processes Communications Questions

50 of 125 questions · Page 2/2 · Processes Communications topic · Answers revealed

Practice these questionsExam hubAll questions
76
MCQmedium

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

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

Issue forms enforce structure and labels at creation time.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
77
MCQhard

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

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

This enforces approval from two members of the specified team.

Why this answer

Option D is correct because the 'Require pull request reviews before merging' rule with 'Required reviewers' set to the team slug 'security-team' enforces approval from two members of that specific team. Option A (Require code owner review) would require a CODEOWNERS file and only enforce from listed owners. Option B (Dismiss stale reviews) is unrelated.

Option C (Restrict who can dismiss reviews) does not set the reviewer requirement.

Practice this question →
78
MCQmedium

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

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

The branch matches the trigger pattern.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
79
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
80
MCQhard

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

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

Service Hooks can trigger a release on work item state change.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
81
MCQhard

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

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

This policy restricts workflows to an approved list.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
82
MCQeasy

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

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

This built-in task automates release notes from commits and work items.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Service hooks can integrate with Teams connectors.

Why this answer

Service hooks in Azure DevOps allow you to integrate with external services like Microsoft Teams by triggering on specific events, such as the creation of a bug work item. This enables automatic notification to the on-call engineer via Teams without requiring a release pipeline or email configuration. The service hook listens for the 'Work item created' event and sends a customizable message to a Teams channel, directly addressing the requirement for automated notification.

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 →
84
Multi-Selectmedium

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

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

Helps users ask clear questions.

Why this answer

Option C is correct because providing a template for new discussions guides users to include essential details (e.g., environment, error logs, steps to reproduce), which reduces ambiguity and makes it easier for community members to provide accurate answers. This directly increases the likelihood of receiving responses by setting clear expectations and reducing back-and-forth clarification.

Exam trap

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

Practice this question →
85
MCQmedium

Your team uses Azure Boards and wants to automatically update the work item state when a pull request is merged. The policy should require a successful build before merging and update the work item to 'Resolved' on merge. Which branch policy should you configure?

A.Automatically update work items
B.Require a minimum number of reviewers
C.Comment resolution
D.Check for linked work items
AnswerA

This policy updates work item state on merge.

Why this answer

The 'Automatically update work items' branch policy in Azure Repos is specifically designed to update the state of linked work items when a pull request is completed (merged). By configuring this policy, you can set the work item to transition to 'Resolved' upon merge, and you can also require a successful build as a prerequisite for merging. This directly meets the requirement to automatically update the work item state on merge while enforcing a build validation.

Exam trap

The trap here is that candidates may confuse 'Check for linked work items' (which only verifies a link exists) with 'Automatically update work items' (which actually changes the work item state), or they may think that a reviewer requirement or comment resolution can trigger work item updates.

How to eliminate wrong answers

Option B is wrong because 'Require a minimum number of reviewers' only enforces that a certain number of people approve the pull request; it does not update work items or require a build. Option C is wrong because 'Comment resolution' requires that all comments on the pull request are resolved before merging, but it has no effect on work item state transitions or build validation. Option D is wrong because 'Check for linked work items' ensures that the pull request is linked to at least one work item, but it does not automatically update the work item state or enforce a build requirement.

Practice this question →
86
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 restrict the number of items in a column, preventing bottlenecks.

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 →
87
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 charter sets expectations for communication.

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. This practice aligns with DevOps principles of collaboration and shared ownership, ensuring all members understand preferred channels, response times, and escalation paths.

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 →
88
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 directly enforces the approval requirement before merge.

Why this answer

Option B is correct because 'Require a pull request before merging' with 'Required approvals' set to 1 enforces the policy. Option A is wrong because it only changes the name, not approvals. Option C is wrong because it restricts who can push, not the approval requirement.

Option D is wrong because it requires status checks, not approvals.

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

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

Branch policies provide all required enforcement.

Why this answer

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

Service Hooks support Slack.

Why this answer

Service Hooks in Azure Pipelines allow you to integrate with external services like Slack by triggering HTTP POST requests containing build status payloads. This enables real-time notifications to stakeholders without requiring custom scripting or additional infrastructure, making it a valid and direct communication method.

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 →
92
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
AnswerA

This trigger fires when a PR is closed (merged) into main, ensuring review was completed.

Why this answer

Option A is correct because the `pull_request_target` trigger with `types: [closed]` and `branches: [main]` ensures the workflow runs only after a pull request targeting the main branch is closed (merged). This satisfies the requirement of deploying to staging only after a successful pull request review and merge, not on every push. The `pull_request_target` event runs in the context of the base repository, providing access to secrets, which is appropriate for deployment workflows.

Exam trap

The trap here is confusing `pull_request` (which triggers on PR events like opened or synchronized) with `pull_request_target` (which triggers on PR events but runs in the base repo context), and forgetting that `types: [closed]` is needed to run after merge, not during the PR lifecycle.

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

Why this order

Agent setup requires PAT creation, download, configuration, registration, and service start.

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

This built-in task creates a bug assigned to the responsible committer.

Why this answer

Option B is correct because the 'Create work item on failure' task in a build pipeline automatically creates a bug and assigns it to the person who triggered the build or the last committer. Option A (Service Hook) would require custom logic. Option C (YAML task with REST API) is more complex and not built-in.

Option D (Release pipeline) is for deployments, not builds.

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

Centralized documentation aids transparency.

Why this answer

A shared wiki (e.g., Azure DevOps Wiki) provides a single source of truth for project documentation, decisions, and onboarding materials. It is version-controlled, searchable, and accessible asynchronously, which is critical for distributed teams to stay aligned without relying on real-time communication.

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

Basic test artifacts in Azure Test Plans.

Practice this question →
98
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.
AnswerC

Code ownership can auto-assign based on file patterns.

Why this answer

Option B is correct because code ownership policies allow automatic reviewer assignment based on file paths. Option A is wrong because branch policies are separate. Option C is wrong because auto-approve bypasses review.

Option D is wrong because required reviewers are for all PRs, not per folder.

Practice this question →
99
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 automates the merge and handles conflicts with a PR.

Why this answer

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

Minimum approver count is 0, so no approval required; only the required status check must pass.

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 →
101
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
AnswerC

Azure Boards supports rules that automatically complete linked PRs when a work item is closed.

Why this answer

Option D is correct because Azure Boards can be configured with a rule that automates PR completion when a work item state changes. Option A is wrong because branch policies do not react to work item changes. Option B is wrong because service hooks can trigger webhooks but not directly complete PRs; a custom function would be needed.

Option C is wrong because the 'Pull Request' tab is informational.

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

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

Real-time review eliminates async delays.

Why this answer

Option B is correct because pair programming or mob programming can reduce the need for asynchronous reviews as code is reviewed in real-time. Option A is incorrect because reducing reviewer count may lower quality. Option C is incorrect because automatic merging bypasses review.

Option D is incorrect because a separate review team introduces bottlenecks.

Practice this question →
104
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 and restricted permissions prevent bypassing approvals; ARM template with script logs changes.

Why this answer

Option D is correct because 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 →
105
Multi-Selecteasy

Your team uses Azure DevOps and wants to automate the creation of a bug work item when a release pipeline fails. Which two actions should you take?

Select 2 answers
A.Set a scheduled trigger for the release pipeline.
B.Configure a Service Hook to create a work item when a release stage fails.
C.Add a build completion trigger to the release pipeline.
D.Add the 'Create work item on failure' task to the release pipeline.
E.Configure a pre-deployment approval.
AnswersB, D

Service Hooks can create work items on failure.

Why this answer

Option B is correct because Service Hooks in Azure DevOps allow you to integrate with external services and trigger actions, such as creating a work item in Azure Boards, when a release stage fails. Option D is correct because the 'Create work item on failure' task can be added directly to a release pipeline to automatically generate a bug work item upon failure, providing a built-in automation mechanism without external dependencies.

Exam trap

The trap here is that candidates may confuse triggers (scheduled or build completion) with event-driven actions, or assume that approvals can automate work item creation, when in fact only Service Hooks and the dedicated task directly create work items on failure.

Practice this question →
106
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 filter must include stakeholders for them to receive notifications.

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

Branch policies can require specific reviewers or groups.

Why this answer

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

Refer to the exhibit. The JSON above shows a branch policy configuration for the main branch in Azure Repos. A developer pushes a third commit to an existing pull request after two reviewers have already approved. What happens?

A.The existing approvals remain valid because dismiss_stale_reviews is false.
B.The pull request is automatically merged because allowed merge types include squash.
C.The approvals are dismissed because require_last_push_approval is true.
D.The pull request is blocked because the merge type is not allowed.
AnswerC

The new push invalidates previous approvals.

Why this answer

Option B is correct because require_last_push_approval is true, so after the new push, previous approvals are dismissed, requiring re-approval. Option A is wrong because require_last_push_approval overrides dismiss_stale_reviews. Option C is wrong because allowed merge types are squash and rebase, but that doesn't affect approval.

Option D is wrong because the pull request can still be updated.

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

Options B and D are correct. Option B is correct because variables mapped from Azure Key Vault are secure and audited. Option D is correct because secret variables should be set in the pipeline UI, not YAML.

Option A is wrong because hardcoding secrets is insecure. Option C is wrong because secret variables are masked, not visible.

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

Branch policies enforce review requirements.

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

This policy mandates a work item for each pull request.

Why this answer

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

This enforces that quality checks must pass.

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

This setting deletes the branch after PR merge.

Why this answer

Option A is correct because branch policies can auto-delete after merge. Option B is wrong because cleanup scripts are manual. Option C is wrong because retention policies are for pipelines, not branches.

Option D is wrong because manual deletion is not automated.

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

Parallel jobs allow concurrent builds.

Why this answer

Option C is correct because parallel jobs allow multiple builds to run concurrently, reducing queue time. Option A is wrong because changing the agent specification does not increase concurrency. Option B is wrong because Microsoft-hosted agents incur additional cost.

Option D is wrong because reducing pipeline steps may not be feasible and doesn't address concurrency.

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

This rule rejects unsigned commits.

Why this answer

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

Branch policy restricts pushes to specific groups.

Why this answer

Option D is correct because the branch policy enforces that only members of the 'Code Owners' group can push directly to the branch; the developer lacks that membership. Option A (Insufficient permissions at project level) is less specific. Option B (Pipeline service principal missing) is unrelated.

Option C (Incorrect branch name) would give a different error.

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

Custom fields allow tracking additional data.

Why this answer

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

This integration automatically links and can transition work items on merge.

Why this answer

Option C is correct because 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 #{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 →
120
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

Option B is correct because environment approvals in YAML pipelines can require manual approval before deployment to production, and branch filters on triggers can restrict to release branches. Option A is wrong because branch policies are for source control, not pipeline deployment. Option C is wrong because build validation runs on PR creation, not on merge.

Option D is wrong because 'Check for linked work items' does not enforce branch restrictions.

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

Branch protection rules enforce PRs and reviews.

Why this answer

Option B is correct because 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 CODEOWNERS file alone does not block commits.

Option D is incorrect because a .gitignore file does not enforce branch policies.

Practice this question →
122
MCQhard

You execute the above Azure CLI command. A pipeline YAML references the variable group 'Config' and uses the variable 'env'. However, the pipeline fails because the variable 'env' is not found. What is the most likely reason?

A.The variable 'env' is a secret variable and cannot be used in YAML.
B.The variable group 'Config' is not linked to the pipeline.
C.The variable name is case-sensitive; the YAML uses 'Env' instead of 'env'.
D.The variable group is scoped to a specific branch, and the pipeline is running on a different branch.
AnswerC

Variable names are case-sensitive in Azure Pipelines.

Why this answer

Option C is correct because Azure DevOps variable names are case-sensitive. The pipeline YAML references the variable 'env', but if the variable group defines it as 'Env' (or any other casing), the pipeline will fail with a 'not found' error. This is a common pitfall when variable names are not matched exactly, including case, in YAML pipelines.

Exam trap

The trap here is that candidates assume variable names are case-insensitive (as in many programming languages or operating systems), but Azure DevOps treats them as case-sensitive, causing a mismatch error when the casing differs between the variable group and the YAML reference.

How to eliminate wrong answers

Option A is wrong because secret variables can be used in YAML pipelines; they are referenced with the same syntax as non-secret variables, though they cannot be displayed in logs. Option B is wrong because the question states the pipeline references the variable group 'Config', implying it is linked; if it were not linked, the pipeline would fail with a different error (e.g., 'variable group not found'). Option D is wrong because variable group scoping to a branch affects when the group is available, but the error message specifically says 'variable not found', not 'variable group not available'.

Practice this question →
123
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: eq(variables['Build.SourceBranch'], 'refs/heads/main')
AnswerD

The condition can skip the approval when the branch is main.

Why this answer

Option D is correct because the manual validation task with a condition `eq(variables['Build.SourceBranch'], 'refs/heads/main')` will only pause the pipeline for manual approval when the source branch is NOT main (the condition evaluates to false for non-main branches, triggering the approval). This directly implements the requirement: approval is required only for deployments originating from branches other than 'main'.

Exam trap

The trap here is that candidates confuse pre-deployment approvals (which are environment-level and unconditional) with conditional task-level approvals, and they overlook that the condition must be written to trigger the manual validation only when the branch is NOT main, not when it is main.

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

This integration automatically creates work items from GitHub issues.

Why this answer

Option D is correct because the GitHub + Azure Boards integration provides automatic syncing. Option A is wrong because a GitHub Action would require custom code. Option B is wrong because a webhook is manual setup.

Option C is wrong because Azure Pipelines is not needed.

Practice this question →
125
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 app provides easy integration with Teams.

Why this answer

Option C is correct because 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 · 125 questions total

Ready to test yourself?

Try a timed practice session using only Processes Communications questions.

Start 20-question session