Courseiva

CCNA Configure processes and communications Questions

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

Practice these questionsDomain overviewAll questions
76
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 →
77
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

A monorepo lets several projects import shared libraries directly from one repository, so a change to a common module is immediately visible to every consumer. This satisfies the stem's code-sharing benefit, since Azure Pipelines can trigger builds across affected projects without cross-repository package publishing or version pinning.

Why this answer

Option C is correct because a monorepo places all projects in a single repository, so shared libraries, utilities, and interfaces can be referenced directly rather than published and consumed as versioned packages across multiple repos. Option D is correct because dependencies between components are resolved from one consistent source tree, avoiding version-skew and cross-repo package coordination that complicates dependency management. Option E is correct because a single commit can change multiple components together, so a cross-component change lands atomically and CI/CD can validate the whole change set in one pipeline run.

Option A is not a benefit of a monorepo; granular repository-level permissions are actually harder because everything lives in one repo, and Azure Repos permissions are typically applied at repo, branch, or path level rather than per project. Option B is not a benefit either, since a monorepo is a larger codebase and builds are not inherently faster; faster builds usually require path filters, incremental builds, or pipeline caching rather than resulting from the monorepo itself.

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 →
78
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 →
79
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 →
80
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 →
81
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.
AnswerA

This option is incorrect because although dismiss_stale_reviews is false, the branch policy also sets require_last_push_approval to true. In Azure DevOps, require_last_push_approval forces all previous approvals to be invalidated whenever a new push occurs, regardless of whether stale review dismissals are enabled. Thus, the current commits have no valid approval, and the PR cannot be merged.

Why this answer

In Azure Repos, the 'Block on last push' policy (require_last_push_approval) only revokes an approval from the user who made the most recent push, preventing them from approving their own changes. It does not invalidate approvals from other reviewers. The setting that resets all approvals when new commits are pushed is 'Reset code reviewer votes when there are new changes' (dismiss_stale_reviews).

Since dismiss_stale_reviews is false in the given configuration, the two existing approvals remain valid when the developer pushes a third commit.

Exam trap

Do not confuse 'require_last_push_approval' with 'dismiss_stale_reviews'. The former only affects the last pusher's approval, while the latter resets all approvals on any new push.

How to eliminate wrong answers

Option A is wrong because `dismiss_stale_reviews` is not present in the JSON; instead, `require_last_push_approval` is set to true, which overrides any default behavior and forces dismissal of approvals on new pushes. Option B is wrong because the `allowed_merge_types` list includes squash, but automatic merging is not triggered by a push; the PR still requires valid approvals and policy compliance. Option D is wrong because the merge type (squash) is explicitly allowed in the configuration, so the PR is not blocked on that basis.

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

Defining variables in the pipeline UI and marking them secret encrypts the value at rest in Azure DevOps and masks it in logs, satisfying the requirement to keep credentials out of plain-text YAML. Secret variables are not automatically exposed to scripts, so tasks must map them explicitly via environment variables.

Why this answer

Option A is correct because defining variables in the pipeline UI (Library variable groups or pipeline variables) and marking them as secret encrypts them at rest and masks their values in logs, which is the built-in Azure Pipelines mechanism for handling sensitive values. Option C is correct because Azure Key Vault is the recommended centralized secret store, and Azure Pipelines can link a Key Vault as a variable group so secrets are fetched at runtime and never persisted in the pipeline definition. Option B is not recommended because plain environment variables on the build agent are not encrypted or masked and can leak into logs or be read by other processes.

Option D is wrong because there is no 'secret' keyword for variables in YAML; secrets must come from the UI, variable groups, or Key Vault. Option E is wrong because storing secrets as plain text in YAML exposes them in source control and build logs.

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 →
83
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 →
84
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 →
85
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 →
86
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 →
87
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 →
88
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 →
89
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 →
90
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 →
91
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 →
92
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 on the main branch are the GitHub-native mechanism to require pull request reviews before any merge, which directly prevents direct commits. Enabling 'Require a pull request before merging' with a minimum number of approvals blocks the developer's direct push and forces the GitHub Flow review step.

Exam trap

The trap is assuming CODEOWNERS or .gitignore enforce policy — they only suggest reviewers or ignore files; only branch protection rules actually block direct commits to a protected branch.

How to eliminate wrong answers

Option A is wrong because a manual sign-off after each commit is a post-hoc, human process with no enforcement — the commit already landed on main, so quality was not prevented. Option C is wrong because .gitignore only prevents untracked files from being staged; it has no effect on commits to tracked files or on branch-level policy. Option D is wrong because a CODEOWNERS file only auto-assigns reviewers to pull requests — it does not block direct pushes and does nothing if no PR is opened.

Practice this question →
93
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 →
94
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 GitHub + Azure Boards integration is a built-in, officially supported connector that automatically links GitHub repositories to Azure Boards and can create work items from GitHub issues with minimal configuration. It is the most efficient method because it requires no custom code, no webhook scripting, and no pipeline setup—just install the integration from the Azure DevOps Marketplace and authorize it.

Exam trap

The trap is overengineering the solution—candidates may choose custom GitHub Actions or webhooks because they sound more 'technical' or flexible, but the exam rewards the simplest, most efficient native integration for the stated requirement.

How to eliminate wrong answers

Option B is wrong because creating a GitHub Action that calls the Azure DevOps REST API requires writing and maintaining custom YAML/workflow code, handling authentication tokens, and managing error cases—far less efficient than the native integration. Option C is wrong because Azure Pipelines with a GitHub trigger is designed for CI/CD build/release automation, not for creating work items in Azure Boards; it does not natively create work items from issues. Option D is wrong because configuring a raw webhook from GitHub to Azure DevOps requires a custom endpoint or Azure Function to receive and process the payload, which is more complex and error-prone than the official integration.

Practice this question →
95
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 is the officially supported integration that lets you subscribe a Teams channel to pipeline events, including build failures, with rich notifications and actionable cards. Installing the app and configuring the channel subscription is the intended approach. It provides native integration without custom webhooks or email workarounds.

Exam trap

The trap is choosing a generic webhook or email subscription because it seems simpler; candidates often miss that the native Azure Pipelines app provides the supported, low-effort subscription model for Teams channels.

How to eliminate wrong answers

Option A is wrong because email subscriptions send email to an address; Teams channel email addresses are not designed for structured pipeline notifications and lack the rich formatting and actions of the native app. Option B is wrong because while a generic webhook can post to a Teams incoming webhook URL, it requires custom payload formatting and does not provide the out-of-the-box subscription model or event filtering that the Azure Pipelines app offers. Option D is wrong because there is no built-in 'Post to a Microsoft Teams channel' task in Azure Pipelines; you would need a custom script or extension, which is more effort and less integrated.

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

Ready to test yourself?

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

Start 20-question session