Knowledge + Practice

CCNA Design and implement a source control strategy Questions

75 of 95 questions · Page 1/2 · Design and implement a source control strategy · Answers revealed

Practice these questions Domain overview All questions

1

MCQeasy

Your team uses GitHub for source control. You need to ensure that sensitive data, such as connection strings, is never committed to the repository. Which tool should you use?

A.GitHub Actions

B.Dependabot

C.Git Large File Storage (LFS)

D.GitHub secret scanning

AnswerD

Secret scanning detects secrets like connection strings in code.

Why this answer

GitHub secret scanning automatically detects sensitive data like connection strings, API keys, and tokens as they are pushed to a repository, preventing them from being committed. It scans for known patterns and can block the push or alert the repository administrator, making it the correct tool for this requirement.

Exam trap

The trap here is that candidates often confuse secret scanning with Dependabot (which handles dependency vulnerabilities, not secrets) or assume GitHub Actions can be scripted to scan for secrets, but secret scanning is a dedicated, built-in feature that operates at the push level without requiring workflow configuration.

How to eliminate wrong answers

Option A is wrong because GitHub Actions is a CI/CD automation platform for building, testing, and deploying code, not a tool for scanning or blocking sensitive data in commits. Option B is wrong because Dependabot is used for automated dependency updates and security vulnerability alerts, not for detecting secrets or connection strings in source code. Option C is wrong because Git LFS is designed to handle large binary files by replacing them with text pointers, not for scanning or preventing sensitive data from being committed.

Practice this question →

2

Multi-Selectmedium

Your team is migrating from TFVC to Git in Azure Repos. Which TWO actions should you take to ensure a smooth migration?

Select 2 answers

A.Use the Azure DevOps Migration Tool to directly map TFVC permissions to Git repository permissions.

B.Use the git-tfs tool to clone the TFVC repository with full history into a local Git repository.

C.Create a single Git repository with multiple branches that mirror the TFVC branch structure.

D.Train the development team on Git branching strategies and commands before the migration.

E.Enable Git LFS in the new repository to handle large binary files from TFVC.

AnswersB, D

git-tfs preserves history during migration.

Why this answer

Option B is correct because the git-tfs tool is specifically designed to bridge TFVC and Git, allowing you to clone a TFVC repository with full changeset history into a local Git repository. This preserves the commit history, which is critical for audit trails and code review continuity during the migration.

Exam trap

The trap here is that candidates often confuse the Azure DevOps Migration Tool's capabilities, assuming it can directly convert TFVC permissions to Git permissions, when in reality Git permissions are managed differently and require manual reconfiguration of branch policies and security groups.

Practice this question →

3

MCQhard

You are designing a source control strategy for a global team of 200 developers working on a single large .NET solution. The solution takes 45 minutes to build. You need to reduce build times and enable independent versioning of components. What should you do?

A.Migrate from Git to Team Foundation Version Control (TFVC) for better performance

B.Stay in a monorepo and use one pipeline with path filters to build only changed components

C.Split the solution into multiple repositories, each with its own CI/CD pipeline

D.Keep the monorepo and disable continuous integration builds to reduce load

AnswerC

Multiple repositories with independent builds reduce build times and enable independent versioning.

Why this answer

Splitting the solution into multiple repositories (a multi-repo strategy) allows independent teams to version and build their components separately, reducing the monolithic 45-minute build to smaller, parallel CI/CD pipelines. This approach also enables independent versioning of components, which is impossible in a monorepo without complex tooling. Each repository can have its own pipeline that triggers only on changes to that component, drastically cutting build times.

Exam trap

The trap here is that candidates often think path filters in a monorepo (Option B) reduce build time, but they only control pipeline triggers—the actual build still compiles the entire solution, so the 45-minute build remains unchanged.

How to eliminate wrong answers

Option A is wrong because migrating from Git to TFVC would not reduce build times or enable independent versioning; TFVC is a centralized version control system that still requires building the entire solution and lacks Git's branching/merging efficiency for parallel work. Option B is wrong because staying in a monorepo with path filters still requires the entire solution to be built in a single pipeline, and the 45-minute build time is not reduced—path filters only skip pipeline triggers but do not change the fact that the build itself must process the whole solution. Option D is wrong because disabling continuous integration builds would eliminate automated builds entirely, which defeats the purpose of reducing build times and enabling independent versioning; it would only hide the problem, not solve it.

Practice this question →

4

Multi-Selecteasy

Which TWO Git commands are commonly used to incorporate changes from a remote repository into your local branch while keeping history linear?

Select 2 answers

A.git pull --rebase

B.git fetch

C.git merge

D.git cherry-pick

E.git rebase

AnswersA, E

Fetches and rebases local commits on top of remote branch.

Why this answer

`git pull --rebase` (A) is correct because it fetches changes from the remote and then replays your local commits on top of the fetched commits, resulting in a linear history without merge commits. `git rebase` (E) is correct because it directly rewrites commit history by moving or combining a sequence of commits onto a new base, which can be used to incorporate remote changes linearly when combined with `git fetch`.

Exam trap

The trap here is that candidates often confuse `git fetch` (which only downloads data) with `git pull` (which integrates), or they assume `git merge` always creates a merge commit and forget that fast-forward merges can keep history linear, but the question explicitly asks for commands that keep history linear, and `git merge` does not guarantee that.

Practice this question →

5

MCQmedium

Your Azure DevOps project contains a Git repository with multiple branches. You need to ensure that code reviews are mandatory for all pull requests targeting the 'release' branch. Additionally, the build pipeline must pass before merging. How should you configure branch policies?

A.Enable 'Build validation' only.

B.Enable 'Require a minimum number of reviewers' only.

C.Enable 'Require a minimum number of reviewers' and 'Build validation'.

D.Enable 'Require a minimum number of reviewers' and 'Comment resolution'.

AnswerC

Enforces both code review and successful build.

Why this answer

Option C is correct because the requirement specifies two distinct conditions: mandatory code reviews (enforced by 'Require a minimum number of reviewers') and a passing build pipeline before merge (enforced by 'Build validation'). In Azure Repos, branch policies allow you to combine multiple checks; enabling only one of these would leave the other requirement unmet. Therefore, both policies must be enabled to satisfy the full criteria.

Exam trap

The trap here is that candidates often assume 'Comment resolution' implies code review completion, but it only requires that all discussion comments are resolved, not that a specific number of reviewers have approved the changes.

How to eliminate wrong answers

Option A is wrong because enabling only 'Build validation' ensures the pipeline passes but does not enforce mandatory code reviews, leaving the review requirement unmet. Option B is wrong because enabling only 'Require a minimum number of reviewers' enforces code reviews but does not require the build pipeline to pass before merging, violating the build condition. Option D is wrong because 'Comment resolution' ensures all comments are resolved before merging, but it does not enforce a minimum number of reviewers or build validation, so it fails both stated requirements.

Practice this question →

6

Multi-Selecthard

Which TWO approaches can you use to enforce consistent commit message formatting across your organization? (Choose two.)

Select 2 answers

A.Use a pre-receive hook in GitHub to validate commit messages

B.Use a GitHub workflow that checks PR titles

C.Configure a branch policy in Azure Repos to require commit message validation

D.Provide a commit message template to developers

E.Use Git hooks only on client side

AnswersA, C

Enforced on every push.

Why this answer

Option A is correct because GitHub's pre-receive hooks are server-side scripts that execute on the repository before accepting a push, allowing you to enforce commit message format validation across all contributors. This ensures that every commit pushed to the remote repository meets your organization's formatting standards, regardless of local client configurations.

Exam trap

The trap here is that candidates often confuse client-side Git hooks (which are optional and local) with server-side hooks (which enforce policy remotely), or they mistakenly believe that PR title checks or templates provide the same level of enforcement as server-side validation.

Practice this question →

7

MCQhard

You have the above branch policy configuration for the main branch. A developer pushes a new commit to an existing pull request. What happens?

A.The existing approvals are reset, but no new build is queued.

B.The pull request is automatically completed.

C.The existing approvals are reset, and a new build is automatically queued.

D.The existing approvals remain valid, and the build is not requeued.

AnswerC

Both settings trigger on new push.

Why this answer

Option A is correct because 'resetOnSourcePush' is true, so the vote count resets, and 'queueOnSourceUpdateOnly' is true, so a new build is queued. Option B is wrong because the build is queued. Option C is wrong because the vote count resets.

Option D is wrong because the build is queued and votes reset.

Practice this question →

8

Multi-Selectmedium

Your organization uses Azure Repos and wants to implement a Git branching strategy that supports continuous delivery with hotfix capabilities. Which THREE practices should be part of the strategy?

Select 3 answers

A.Feature branches have long lifetimes and are merged to main only after full feature completion.

B.Release branches are used to stabilize a release before merging to main.

C.Main branch is always in a deployable state.

D.Hotfixes are merged directly to develop and then cherry-picked to main.

E.Hotfix branches are created from main and merged back into main and develop.

AnswersB, C, E

Release branches allow final testing and bug fixes before production.

Why this answer

Option B is correct because release branches allow a team to stabilize a release candidate without disrupting ongoing development on the main branch. Once the release is fully tested and stable, it is merged into main, ensuring that main always contains production-ready code. This aligns with the continuous delivery principle of maintaining a deployable main branch.

Exam trap

The trap here is confusing the hotfix branching model with the incorrect practice of merging hotfixes directly to develop and cherry-picking to main, which violates the principle that main must always be in a deployable state and can lead to missing fixes in the development branch.

Practice this question →

9

MCQhard

Your organization uses GitHub Enterprise and wants to enforce that all repositories have a consistent CODEOWNERS file. Which approach should you use to centrally manage this?

A.Use repository rulesets to require that the CODEOWNERS file exists and has a specified pattern

B.Create a CODEOWNERS file at the organization level

C.Use a script to push CODEOWNERS to each repo manually

D.Create a GitHub Actions workflow that runs on push to check CODEOWNERS

AnswerA

Rulesets can enforce file presence and content.

Why this answer

Repository rulesets in GitHub Enterprise allow you to centrally enforce policies across all repositories in an organization, including requiring that a CODEOWNERS file exists and matches a specific pattern. This ensures consistency without manual intervention or per-repo configuration, leveraging GitHub's native repository management capabilities.

Exam trap

The trap here is that candidates confuse organization-level CODEOWNERS (which doesn't exist) with repository rulesets, or assume a post-push check (like a workflow) is equivalent to a pre-push enforcement mechanism.

How to eliminate wrong answers

Option B is wrong because GitHub does not support a single organization-level CODEOWNERS file; CODEOWNERS must be defined per repository within a .github/ or root directory. Option C is wrong because manually pushing CODEOWNERS to each repo via a script is error-prone, lacks centralized enforcement, and does not prevent future non-compliance. Option D is wrong because a GitHub Actions workflow that runs on push to check CODEOWNERS only detects violations after the fact, rather than preventing non-compliant pushes or enforcing the file's existence proactively.

Practice this question →

10

Multi-Selecthard

Your organization uses GitHub for source control. You need to implement a secure source control strategy that prevents secrets from being exposed and ensures code quality. Which THREE practices should you implement?

Select 3 answers

A.Configure branch protection rules requiring status checks to pass

B.Store secrets in a .env file committed to the repository

C.Require commit signing using GPG keys

D.Enable GitHub secret scanning for the repository

E.Use pre-commit hooks to scan for secrets before commits

AnswersA, D, E

Status checks enforce code quality gates.

Why this answer

Option A is correct because branch protection rules enforce required status checks (e.g., CI builds, code reviews) before merging, which prevents code that fails quality gates from entering protected branches. This directly supports code quality by ensuring only validated changes are merged.

Exam trap

The trap here is that candidates may confuse commit signing (which ensures authenticity) with secret scanning or code quality enforcement, leading them to select option C instead of recognizing that it does not address the stated goals of preventing secret exposure or ensuring code quality.

Practice this question →

11

MCQhard

Your Azure Pipeline is configured as shown in the exhibit. A developer pushes a commit to a feature branch named 'feature/new-login' and creates a pull request targeting the main branch. Which pipeline runs will be triggered?

A.No pipeline runs

B.Only a PR build

C.Only a CI build on the feature branch

D.Both a CI build on the feature branch and a PR build

AnswerB

PR trigger matches main branch.

Why this answer

The pipeline is configured with a PR trigger that activates on pull requests targeting the main branch. When a developer pushes a commit to 'feature/new-login' and creates a PR to main, only the PR build is triggered. The CI trigger is not configured for the feature branch (only for main), so no CI build runs on the feature branch itself.

Exam trap

The trap here is that candidates often assume a push to a feature branch automatically triggers a CI build, but the CI trigger's branch filter must explicitly include the branch; otherwise, only the PR trigger (if configured) will fire.

How to eliminate wrong answers

Option A is wrong because a PR trigger is configured, so a pipeline run does occur. Option C is wrong because the CI trigger is set to only trigger on the main branch, not on feature branches like 'feature/new-login'. Option D is wrong because the CI trigger does not apply to the feature branch, so only the PR build runs, not both.

Practice this question →

12

MCQhard

Your organization uses Azure Repos and requires that all code changes pass a security scan before merging. The scan is run as a build validation policy. However, the scan takes 30 minutes and developers often bypass it by pushing directly to main. How can you enforce the policy for all changes?

A.Turn off direct push permissions for all users and force all changes through pull requests

B.Delete the main branch and recreate it as a protected branch

C.Set a branch policy on main that requires a build validation with the security scan

D.Use a service hook to run the scan on every push to main

AnswerC

Branch policies enforce the scan on every push; protecting main prevents bypasses.

Why this answer

Option C is correct because setting a branch policy on main that requires a build validation with the security scan enforces the scan as a mandatory gate for all pull requests targeting main. This prevents developers from bypassing the scan by pushing directly, as the policy blocks direct pushes and only allows changes through pull requests that must pass the configured build validation.

Exam trap

The trap here is that candidates may think a service hook or simply disabling direct pushes is sufficient, but they fail to recognize that only a branch policy with a required build validation can enforce the scan as a gate for all changes.

How to eliminate wrong answers

Option A is wrong because turning off direct push permissions for all users does not by itself enforce the security scan; it only prevents direct pushes, but changes could still be merged via pull requests without the scan if no policy requires it. Option B is wrong because deleting and recreating the main branch as a protected branch does not enforce the security scan; it only resets branch protections, and without a build validation policy, the scan is not required. Option D is wrong because using a service hook to run the scan on every push to main does not block the push if the scan fails; service hooks are asynchronous and cannot enforce policy, so developers can still push directly and bypass the scan.

Practice this question →

13

MCQhard

Your company uses GitHub for source control. The security team requires that all commits to the main branch be signed with an approved GPG key. Additionally, developers must use their corporate email for commits. You need to configure branch protection rules and repository settings to enforce these requirements. Which combination of settings should you use?

A.Configure repository to require commit signature verification via SSH keys.

B.Enable 'Require signed commits' in branch protection rules and use a pre-receive hook to validate email domain.

C.Use a GitHub Actions workflow that checks commit signatures and email and rejects if invalid.

D.Enable 'Require signed commits' in branch protection and use a required status check that runs a custom action to verify commit author email.

AnswerD

Branch protection can require signed commits; a status check can validate email.

Why this answer

Option D is correct because GitHub branch protection rules can require signed commits, but they only verify that a commit is signed with any GPG key, not that the signer's email matches a corporate domain. To enforce the corporate email requirement, you must add a required status check that runs a custom action (e.g., using `actions-ecosystem/action-check-commit-email`) to verify the commit author email matches the corporate domain. This combination satisfies both the GPG signature and email domain requirements.

Exam trap

The trap here is that candidates assume 'Require signed commits' alone enforces both signature and email domain, but it only ensures the commit is signed with a verified GPG key—it does not restrict the email domain, so an additional status check is needed.

How to eliminate wrong answers

Option A is wrong because GitHub requires GPG keys, not SSH keys, for commit signature verification; SSH keys are used for authentication, not signing. Option B is wrong because pre-receive hooks are only available in GitHub Enterprise Server (self-hosted), not in GitHub.com (SaaS), and the question does not specify an on-premises environment. Option C is wrong because while a GitHub Actions workflow could check signatures and email, it cannot reject commits at the push level; it can only add a failing status check, which must be configured as a required status check in branch protection to block merges.

Practice this question →

14

Multi-Selectmedium

Which TWO benefits does using Git LFS (Large File Storage) provide? (Select TWO.)

Select 2 answers

A.Automatically compresses all files in the repository

B.Prevents large files from being stored in the Git history

C.Replaces .gitignore for excluding large files

D.Speeds up diff operations for binary files

E.Reduces the size of Git repositories by storing large files as pointers

AnswersB, E

Large files are stored on the LFS server, not in history.

Why this answer

Git LFS (Large File Storage) prevents large files from being stored directly in the Git repository history. Instead, it replaces the large file in the working tree with a small text pointer file, while the actual binary content is stored on a remote LFS server. This keeps the repository lightweight and avoids bloating the Git object database with large blobs.

Exam trap

The trap here is that candidates often confuse Git LFS with general compression or diff optimization, but LFS specifically addresses repository bloat by externalizing large binary storage, not by compressing or speeding up diffs.

Practice this question →

15

MCQhard

Your organization uses GitHub Advanced Security. A developer accidentally committed a file containing production database connection strings to a feature branch. The push was not yet merged into main. What is the best way to remove the secrets from the branch history while minimizing disruption?

A.Use git filter-repo to remove the file from the branch's history, then force push the branch.

B.Use BFG Repo-Cleaner to delete the file from the branch's history, then force push.

C.Delete the feature branch and have the developer recreate the branch without the secret file.

D.Revert the commit that added the file, then push the revert.

AnswerA

git filter-repo completely removes the file from all commits, and force push updates the remote.

Why this answer

Option A is correct because `git filter-repo` is the recommended modern tool for rewriting Git history, including removing a specific file from all commits in a branch. After rewriting the branch's history to exclude the file, a force push (`git push --force`) overwrites the remote branch, effectively purging the secret from the branch's history. This approach minimizes disruption by preserving the branch's other commits and avoiding the need to recreate the branch or lose work.

Exam trap

The trap here is that candidates often confuse reverting a commit (which only adds a new commit and does not remove the secret from history) with rewriting history (which actually purges the secret), leading them to choose the revert option despite its failure to address the security concern.

How to eliminate wrong answers

Option B is wrong because BFG Repo-Cleaner is a Java-based tool that operates on a cloned repository's entire history, but it is less precise for a single branch and requires additional steps to avoid affecting other branches; it also does not natively support branch-specific rewrites as cleanly as `git filter-repo`. Option C is wrong because deleting the feature branch and recreating it loses all commits and work on that branch, causing significant disruption and potential loss of unmerged changes. Option D is wrong because reverting the commit only adds a new commit that undoes the changes, but the secret remains in the commit history and is still accessible via `git log` or direct commit inspection, failing to remove the secret from the branch's history.

Practice this question →

16

MCQeasy

Your team uses GitHub and wants to automate the creation of a new release branch (e.g., release/v1.2.3) whenever a tag starting with 'v' is pushed. Which GitHub Actions trigger should you use?

A.on: release: types: [published]

B.on: create: tags: ['v*']

C.on: push: branches: ['v*']

D.on: workflow_dispatch: inputs: tag

AnswerB

Fires when a tag matching the pattern is created.

Why this answer

Option B is correct because the `on: create` trigger fires when a Git tag or branch is created, and the `tags: ['v*']` filter ensures it only activates for tags starting with 'v'. This directly matches the requirement to automate branch creation upon pushing a version tag, without relying on a GitHub Release event or a branch push.

Exam trap

The trap here is that candidates confuse the `release` trigger (which requires a GitHub Release object) with a simple Git tag push, or mistakenly use `branches` instead of `tags` under the `push` event, not realizing that tags are matched via the `tags` key, not `branches`.

How to eliminate wrong answers

Option A is wrong because the `release` trigger only fires when a GitHub Release is published via the UI or API, not when a Git tag is pushed; it requires an explicit release object, not just a tag. Option C is wrong because `on: push: branches: ['v*']` triggers on pushes to branches matching 'v*', not tags; tags are matched using `tags` under `push`, not `branches`. Option D is wrong because `workflow_dispatch` requires manual triggering via the GitHub UI or API with an input parameter, not an automatic trigger on tag push.

Practice this question →

17

MCQeasy

Your team is using Git with Azure Repos. A developer accidentally committed a large binary file to the main branch. What is the recommended way to permanently remove it from the repository history?

A.Delete the file and commit the deletion

B.Ignore the file using .gitignore

C.Revert the commit using 'git revert'

D.Use 'git filter-branch' to remove the file from history

AnswerD

This rewrites history to remove the file entirely.

Why this answer

Option D is correct because `git filter-branch` (or its modern replacement `git filter-repo`) rewrites the entire repository history to permanently remove a file from all commits. This is the recommended approach when a large binary file has been committed to the main branch and must be expunged from history to reduce repository size and prevent it from being cloned by others.

Exam trap

The trap here is that candidates often confuse `git revert` (which creates a new commit that undoes changes but preserves history) with `git filter-branch` (which rewrites history to permanently remove content), leading them to choose option C despite it leaving the large file accessible in the commit log.

How to eliminate wrong answers

Option A is wrong because simply deleting the file and committing the deletion only removes it from the current commit; the file remains in the Git history, meaning it can still be accessed and the repository size is not reduced. Option B is wrong because adding the file to `.gitignore` only prevents future tracking of the file; it does nothing to remove the file from existing commits or history. Option C is wrong because `git revert` creates a new commit that undoes the changes of a previous commit, but the original commit with the large binary file remains in the history, so the file is still present in the repository's commit log.

Practice this question →

18

Multi-Selectmedium

Which TWO options are benefits of using Git LFS (Large File Storage) in a team environment? (Select TWO.)

Select 2 answers

A.Prevents large files from being stored in the Git history

B.Automatically detects and tracks all binary files in the repository

C.Reduces the size of Git repository clones and fetches for team members

D.Works only with GitHub and Azure Repos

E.Eliminates the need for Git when working with large binary files

AnswersA, C

LFS stores large files separately.

Why this answer

Option A is correct because Git LFS replaces large files in the repository with text pointer files, while the actual file content is stored in a separate remote store. This prevents the large files from bloating the Git history, which would otherwise permanently increase repository size for all clones and fetches.

Exam trap

The trap here is that candidates may assume Git LFS automatically handles all binary files (Option B) or that it works only with specific platforms (Option D), when in fact it requires explicit configuration and is widely supported across providers.

Practice this question →

19

MCQhard

Refer to the exhibit. You are reviewing a branch protection rule for the main branch of a GitHub repository. A developer complains that after pushing new commits to an existing pull request, the existing approvals from two reviewers are dismissed, and the pull request cannot be merged even though the CI checks pass. What is the most likely cause?

A.The 'dismiss_stale_reviews' setting is enabled, which dismisses approvals when new commits are pushed.

B.The 'strict' setting requires the branch to be up to date with the base branch, which is not the case.

C.The code owner review is required but no code owner has reviewed.

D.The CI check 'continuous-integration/jenkins/pr-merge' failed.

AnswerA

This is the direct cause of the behavior described.

Why this answer

Option A is correct because the 'dismiss_stale_reviews' setting in GitHub branch protection rules automatically dismisses existing pull request approvals when new commits are pushed to the branch. This explains why the developer sees approvals removed after pushing new commits, even though CI checks pass. The setting is designed to ensure that reviewers re-evaluate changes after updates.

Exam trap

The trap here is that candidates may confuse the 'dismiss_stale_reviews' behavior with the 'strict' branch requirement, thinking that being out of date causes approval dismissal, when in fact 'strict' only blocks the merge button without affecting existing approvals.

How to eliminate wrong answers

Option B is wrong because the 'strict' setting (require branches to be up to date) would block merging if the branch is behind the base branch, but it does not dismiss existing approvals; it only prevents merge until the branch is updated. Option C is wrong because code owner review requirement would block merging if no code owner has approved, but it does not dismiss existing approvals from other reviewers; the complaint specifically mentions existing approvals being dismissed. Option D is wrong because the CI check 'continuous-integration/jenkins/pr-merge' passing is stated in the scenario, so a failed check is not the cause of dismissed approvals.

Practice this question →

20

MCQhard

Your organization has multiple GitHub repositories that use shared workflows. You want to centrally manage these workflows and ensure they are always up to date. What is the recommended approach?

A.Create a central repository with reusable workflows and reference them using the 'uses' keyword in your workflows.

B.Use the GitHub API to push workflow files to each repository on a schedule.

C.Download the workflows from a central blob storage and include them as inline scripts.

D.Store the workflows in a separate repository and use Git submodules to include them.

AnswerA

Reusable workflows are the official pattern.

Why this answer

Option B is correct because GitHub Actions allows you to reference workflows from other repositories using the 'uses' keyword with a path to a workflow file in another repo. Option A is wrong because submodules are for code, not workflows. Option C is wrong because you cannot directly reference a zip file.

Option D is wrong because there is no 'workflow templates' API in GitHub.

Practice this question →

21

MCQhard

You are debugging a recent issue introduced in the main branch. Based on the exhibit, which command would you run to revert the 'Fix login bug' commit while preserving the merge commit?

A.git revert -m 1 HEAD

B.git reset --hard HEAD~1

C.git revert HEAD

D.git revert c3a2b1e -m 2

AnswerC

Creates a new commit reverting the top commit.

Why this answer

Option C is correct because `git revert HEAD` creates a new commit that undoes the changes introduced by the most recent commit (the merge commit), without altering the existing commit history. This preserves the merge commit and its parent relationships, which is essential when reverting a merge commit while keeping the branch structure intact.

Exam trap

The trap here is that candidates often confuse `git revert` with `git reset`, assuming a revert removes history, or they incorrectly apply the `-m` flag without understanding that the default behavior already handles merge commits by reverting the entire merge's changes.

How to eliminate wrong answers

Option A is wrong because `git revert -m 1 HEAD` reverts the merge commit but keeps the changes from the first parent (the main branch), effectively undoing the entire merge and discarding the 'Fix login bug' commit's changes from the merged branch, which is not a simple revert of the commit itself. Option B is wrong because `git reset --hard HEAD~1` removes the merge commit and all its changes from history, which is destructive and does not preserve the merge commit as required. Option D is wrong because `git revert c3a2b1e -m 2` reverts the merge commit while keeping the changes from the second parent (the feature branch), which would undo the merge but retain the 'Fix login bug' commit's changes, contrary to the goal of reverting that specific commit.

Practice this question →

22

MCQmedium

You are reviewing a webhook payload from Azure Repos. The payload indicates that a new branch named 'feature-123' was created. Which event type triggered this webhook?

A.A new branch creation.

B.A push to an existing branch.

C.A branch deletion.

D.A pull request update.

AnswerA

All zeros in 'before' indicates a new branch.

Why this answer

The webhook payload explicitly indicates that a new branch named 'feature-123' was created. In Azure Repos, the event type that corresponds to this action is 'New branch creation' (also known as 'Push' with a new ref). This event fires when a new branch reference is pushed to the remote repository, which is exactly what happened here.

Exam trap

The trap here is that candidates often confuse the 'Push' event type with 'New branch creation', not realizing that Azure Repos uses the same 'Push' event for both, but the payload's 'refUpdates' array contains a 'created' flag that distinguishes them.

How to eliminate wrong answers

Option B is wrong because a push to an existing branch would trigger a 'Push' event with an update to an existing ref, not a new ref creation. Option C is wrong because a branch deletion would trigger a 'Delete' event, which removes a ref entirely. Option D is wrong because a pull request update triggers a 'Pull request updated' event, which is unrelated to branch creation.

Practice this question →

23

Multi-Selecthard

Which THREE practices are recommended for managing secrets in a Git repository? (Select THREE.)

Select 3 answers

A.Use tools like GitLeaks to scan for accidentally committed secrets

B.Store secrets in a separate encrypted file committed to the repository

C.Use GitHub Secrets or Azure Pipelines secret variables

D.Use Azure Key Vault to store and retrieve secrets at build/release time

E.Commit a .env file with default values to the repository

AnswersA, C, D

Scanning helps detect leaks early.

Why this answer

Options B, D, and E are correct. Using Azure Key Vault (B), GitHub Secrets (D), and scanning with tools (E) are best practices. Option A is wrong because storing encrypted secrets in Git is risky.

Option C is wrong because committing .env files is dangerous.

Practice this question →

24

Multi-Selecteasy

Your team uses Git for source control. You want to maintain a clean commit history on the main branch by avoiding merge commits. Which TWO merge strategies in a pull request achieve this?

Select 2 answers

A.Rebase merge

B.Merge commit

C.Squash merge

D.Three-way merge

E.Fast-forward merge

AnswersA, C

Rebase merge applies commits linearly without a merge commit.

Why this answer

A rebase merge (option A) rewrites the commit history of the feature branch onto the tip of the target branch, creating a linear sequence of commits without any merge commits. This maintains a clean, linear history on the main branch. A squash merge (option C) combines all commits from the feature branch into a single new commit on the target branch, also avoiding merge commits and keeping the history clean.

Exam trap

The trap here is that candidates often confuse 'fast-forward merge' with a clean history strategy, but fast-forward merges only avoid merge commits when the branches haven't diverged; they do not rewrite or consolidate commits, so they fail to maintain a clean history in the general case.

Practice this question →

25

MCQhard

Your team uses GitHub and wants to automatically label pull requests based on the content of the changes (e.g., 'frontend' for changes in /frontend folder, 'backend' for /backend). Which approach should you use?

A.Use branch protection rules to require specific labels based on branch name patterns.

B.Set up a webhook that triggers an Azure Function to parse the pull request diff and add labels.

C.Create a GitHub Actions workflow that runs on pull_request events and uses an action like 'actions/labeler' to add labels based on path patterns.

D.Use a CODEOWNERS file to assign labels based on file paths.

AnswerC

The labeler action is designed for this purpose and is easy to configure.

Why this answer

Option C is correct because GitHub Actions provides a native, event-driven way to automate labeling based on pull request changes. The 'actions/labeler' action specifically inspects file paths in the diff and applies labels defined in a configuration file, making it the simplest and most maintainable solution for path-based labeling.

Exam trap

The trap here is confusing CODEOWNERS (which assigns reviewers) with label automation, leading candidates to pick option D despite it having no labeling functionality.

How to eliminate wrong answers

Option A is wrong because branch protection rules enforce policies on merging (e.g., required status checks, number of reviewers) but cannot automatically add labels based on branch name patterns. Option B is wrong because while a webhook plus Azure Function could technically work, it introduces unnecessary complexity and external dependencies when a built-in GitHub Actions workflow is available and simpler. Option D is wrong because CODEOWNERS files define who is responsible for code reviews based on file paths, not for automatically applying labels to pull requests.

Practice this question →

26

MCQmedium

Your team uses GitHub and wants to automatically close stale branches that have not been updated in 90 days. Which GitHub feature should you configure?

A.Create a scheduled GitHub Actions workflow that deletes branches older than 90 days

B.Auto-merge feature

C.Stale bot (GitHub Actions)

D.GitHub Discussions

AnswerA

Automates branch cleanup.

Why this answer

A is correct because GitHub Actions can be scheduled using cron syntax to run a workflow that identifies branches with no commits in the last 90 days and deletes them via the GitHub API. This gives you full control over the deletion logic, logging, and notifications, unlike a simple bot. The workflow can use actions like `actions/github-script` or `stale` to enumerate branches and filter by `committer.date`.

Exam trap

The trap here is that candidates confuse the Stale bot (which handles issues/PRs) with branch management, assuming it can also delete branches, but it has no branch deletion capability.

How to eliminate wrong answers

Option B is wrong because the auto-merge feature automatically merges a pull request when required checks pass, but it does not delete stale branches. Option C is wrong because the Stale bot (GitHub Actions) is designed to mark issues and pull requests as stale and close them, not to delete branches. Option D is wrong because GitHub Discussions is a forum for conversations and does not provide any branch management or deletion capabilities.

Practice this question →

27

MCQmedium

Refer to the exhibit. You have a branch policy JSON for Azure Repos. Which statement about this policy is correct?

A.The last person who pushed can approve the pull request.

B.At least two reviewers must approve the pull request.

C.Pull requests to main are automatically squash-merged.

D.Approvals are reset when the source branch is updated.

AnswerB

requireApprovalCount is 2.

Why this answer

The branch policy JSON specifies `minimumApproverCount: 2`, which enforces that at least two distinct reviewers must approve the pull request before it can be completed. This is a standard Azure Repos branch policy setting that controls the required number of approvals, not the identity of the approvers or the merge strategy.

Exam trap

The trap here is that candidates assume the last person who pushed can always approve, but Azure Repos defaults to blocking that unless explicitly overridden, and the policy JSON shown does not include the override setting.

How to eliminate wrong answers

Option A is wrong because Azure Repos branch policies do not automatically allow the last pusher to approve; unless explicitly allowed via the 'Allow approvers to approve their own changes' setting, the last person who pushed is typically blocked from approving. Option C is wrong because the JSON does not set a merge strategy; squash-merge is a separate policy option not shown here. Option D is wrong because the policy does not include `resetOnSourcePush: true`; without that setting, approvals are not automatically reset when the source branch is updated.

Practice this question →

28

MCQeasy

Your team uses Azure DevOps and wants to enforce that all changes to the main branch go through a pull request process with at least two approvals. They also want to prevent contributors from approving their own pull requests. Which branch policy settings should they use?

A.Enable 'Check for linked work items' and 'Require a minimum number of reviewers' set to 2, and enable 'Reset code reviewer votes when new changes are pushed'.

B.Add the 'main' branch to the 'Required reviewers' list and add all developers as required reviewers.

C.Enable 'Require a minimum number of reviewers' set to 2, and enable 'Build validation' with a required build.

D.Enable 'Require a minimum number of reviewers' set to 2, and enable 'Allow users to approve their own changes' unchecked (or set to false).

AnswerD

This enforces two approvals and prevents self-approval.

Why this answer

Option D is correct because it directly addresses both requirements: setting 'Require a minimum number of reviewers' to 2 enforces at least two approvals, and unchecking 'Allow users to approve their own changes' prevents contributors from approving their own pull requests. These are branch policy settings within Azure Repos that control the pull request workflow on the main branch.

Exam trap

The trap here is that candidates often confuse 'Require a minimum number of reviewers' with 'Required reviewers' (a static list) or think that build validation alone satisfies the approval requirement, missing the need to explicitly disable self-approval.

How to eliminate wrong answers

Option A is wrong because 'Check for linked work items' ensures traceability but does not enforce the number of approvals or prevent self-approval; 'Reset code reviewer votes when new changes are pushed' is unrelated to the approval count or self-approval restriction. Option B is wrong because adding the 'main' branch to 'Required reviewers' and listing all developers as required reviewers would force every developer to be a reviewer on every PR, which is impractical and does not enforce a minimum of two approvals or prevent self-approval. Option C is wrong because 'Build validation' ensures code quality via automated builds but does not control the number of human approvals or self-approval behavior.

Practice this question →

29

MCQmedium

Your team uses GitHub Flow. A developer pushes a feature branch to origin and creates a pull request to main. After review and approval, the pull request is merged. Which branch should the developer delete after the merge to maintain a clean repository?

A.Delete the feature branch

B.Keep both branches indefinitely

C.Delete the main branch

D.Delete the remote main branch and recreate it

AnswerA

Feature branches are temporary and should be deleted after merge.

Why this answer

In GitHub Flow, feature branches are temporary and should be deleted after their pull request is merged into main. Deleting the feature branch keeps the repository clean by removing stale branches that are no longer needed, reducing clutter and preventing confusion. This practice aligns with the principle of short-lived branches in trunk-based development workflows.

Exam trap

The trap here is that candidates may think keeping feature branches is harmless or that deleting main is acceptable for cleanup, but GitHub Flow explicitly requires deleting feature branches after merge to maintain a clean, linear history and avoid repository clutter.

How to eliminate wrong answers

Option B is wrong because keeping both branches indefinitely violates the GitHub Flow convention of deleting feature branches after merge, leading to repository bloat and potential confusion about active work. Option C is wrong because deleting the main branch would break the repository's default branch and disrupt all future development, as main is the stable integration branch. Option D is wrong because deleting and recreating the remote main branch is unnecessary and destructive; it would require force-pushing and could cause loss of commit history or break CI/CD pipelines that depend on the existing branch.

Practice this question →

30

MCQmedium

Your team uses Azure Repos and has a repository with a large number of binary files (e.g., images, compiled libraries) that bloat the repository size. You want to reduce clone times and storage usage while still maintaining version history for those files. Which approach should you recommend?

A.Split the repository into two: one for code and one for binaries.

B.Use git annex to manage large files with a separate store.

C.Use git submodules to reference the large files from another repository.

D.Use Git Large File Storage (LFS) to track large files with pointers.

AnswerD

Git LFS is supported and reduces clone size.

Why this answer

Git LFS (Large File Storage) replaces large binary files in the repository with text pointers, while storing the actual file content in a separate remote store. This keeps the repository lightweight for cloning and fetching, but still preserves the full version history of the binary files because each pointer references a specific version in the LFS store. It integrates natively with Azure Repos and requires minimal workflow changes.

Exam trap

The trap here is that candidates often confuse git submodules or repo splitting as valid solutions for large files, but they fail to realize that those approaches do not actually reduce clone times or storage usage for the binary files themselves—they only reorganize the problem.

How to eliminate wrong answers

Option A is wrong because splitting the repository does not reduce the total storage or clone time for the binary files—they still exist in a separate repo and must be cloned separately, and maintaining version history across two repos adds complexity. Option B is wrong because git annex is not a native Azure Repos feature; it requires a separate external store and manual configuration, and it does not integrate seamlessly with Azure DevOps pipelines or pull requests. Option C is wrong because git submodules only link to a specific commit in another repository; they do not reduce clone times for the large files (the submodule must still be cloned in full) and they complicate version management by requiring explicit submodule updates.

Practice this question →

31

MCQeasy

You have a GitHub repository with a GitHub Actions workflow that builds a .NET application. The workflow should only run when changes are pushed to the main branch, but it currently runs on every push to any branch. How should you fix the workflow trigger?

A.Add 'on: push: branch: [main]' to the workflow.

B.Add 'on: push: paths: [main]' to the workflow.

C.Add 'on: pull_request: branches: [main]' to the workflow.

D.Add 'on: push: branches: [main]' to the workflow.

AnswerD

This restricts the trigger to pushes on main.

Why this answer

Option D is correct because the GitHub Actions workflow syntax to restrict a push trigger to a specific branch uses `on: push: branches: [main]`. This ensures the workflow only executes when commits are pushed to the main branch, not on pushes to any other branch.

Exam trap

The trap here is that candidates often confuse the singular `branch` with the plural `branches` or mix up `paths` with `branches`, leading them to select options that either use invalid syntax or apply the wrong filter entirely.

How to eliminate wrong answers

Option A is wrong because `branch` is not a valid key under `push`; the correct key is `branches` (plural). Option B is wrong because `paths` filters by file paths changed in the push, not by branch name, so it would not restrict the trigger to the main branch. Option C is wrong because it defines a `pull_request` trigger, not a `push` trigger, so the workflow would run on pull request events instead of push events.

Practice this question →

32

MCQmedium

Your team uses Azure Repos and needs to prevent secrets from being committed to the repository. Which built-in feature should you enable?

A.Enable GitHub secret scanning

B.Enable Azure Policy to scan repositories

C.Configure a pre-commit hook with a secret scanning tool

D.Enable push protection in Azure Repos

AnswerD

Blocks commits with secrets.

Why this answer

Push protection in Azure Repos is a built-in feature that scans commits for high-confidence secrets (e.g., Azure service connection strings, SSH keys, and other credential patterns) and blocks the push if a secret is detected. This prevents secrets from ever reaching the remote repository, enforcing security at the server side without requiring client-side configuration.

Exam trap

The trap here is that candidates confuse client-side pre-commit hooks (Option C) with a built-in server-side solution, overlooking that hooks can be bypassed and are not enforced, while push protection in Azure Repos is a native, unbypassable guard.

How to eliminate wrong answers

Option A is wrong because GitHub secret scanning is a feature of GitHub, not Azure Repos, and the question specifies the team uses Azure Repos. Option B is wrong because Azure Policy is used for governance and compliance of Azure resources (e.g., VM SKUs, resource locations), not for scanning repository contents for secrets. Option C is wrong because configuring a pre-commit hook is a client-side solution that can be bypassed by developers (e.g., by using --no-verify) and requires manual setup per machine, whereas Azure Repos push protection is a server-side, enforced feature.

Practice this question →

33

MCQmedium

Your team uses Git with Azure Repos. You notice that the commit history on the main branch contains many merge commits and commit messages like 'fix merge conflict'. You want a linear history for better traceability. What should you change?

A.Configure the repository to use rebase when pulling

B.Set the branch policy to require a clean fast-forward merge

C.Use rebase merge when completing pull requests

D.Use squash merge when completing pull requests

AnswerD

Squash merge condenses all commits into one, allowing a clean commit message and linear history.

Why this answer

Option D is correct because squash merge collapses all feature branch commits into a single commit on the main branch, eliminating merge commits and preserving a linear history. This directly addresses the problem of cluttered commit messages like 'fix merge conflict' by discarding intermediate commits and their messages. Squash merge is configured in the Azure Repos branch policy for pull request completion.

Exam trap

The trap here is that candidates confuse 'rebase merge' (which preserves individual commits) with 'squash merge' (which collapses them), or mistakenly think that requiring fast-forward merges alone eliminates merge commits, when in fact it only prevents non-linear merges but still allows merge commits from out-of-date branches.

How to eliminate wrong answers

Option A is wrong because configuring 'rebase when pulling' affects local developer workflows (git pull --rebase) but does not enforce a linear history on the remote main branch; merge commits can still be introduced via pull requests. Option B is wrong because requiring a clean fast-forward merge only prevents non-fast-forward merges but still allows merge commits if the feature branch is not up to date; it does not eliminate merge commits or clean up commit messages. Option C is wrong because rebase merge replays each individual commit from the feature branch onto main, preserving all intermediate commits and their messages, including 'fix merge conflict' commits, thus failing to achieve a clean linear history.

Practice this question →

34

Multi-Selectmedium

Which THREE practices are recommended for effective source control in a GitHub monorepo? (Choose three.)

Select 3 answers

A.Store large binary files directly in the repository

B.Use branch protection rules to enforce CI checks

C.Use a single build definition for all projects

D.Use code owners to automatically request reviewers

E.Use path filters to trigger only relevant CI workflows

AnswersB, D, E

Maintains quality.

Why this answer

Options A, B, and E are correct. Option C is wrong because it reduces performance. Option D is wrong because it is not specific to monorepos.

Practice this question →

35

MCQmedium

You are reviewing the branch protection policy for the main branch in an Azure DevOps repository. Based on the exhibit, what happens when a stale review exists on a pull request after new changes are pushed?

A.Admins are exempt from the review requirement

B.The stale review is automatically dismissed, and the PR requires new approvals

C.The PR still requires only 2 approvals, but stale reviews are not dismissed

D.The PR can be merged even without the required reviews

AnswerB

dismissStaleReviews: true.

Why this answer

The branch protection policy for the main branch has 'Reset code reviewer votes when there are new changes' enabled. When a stale review exists after new changes are pushed, Azure DevOps automatically dismisses the previous approval(s) and requires new approvals to meet the minimum number of reviewers (2). This ensures that reviewers re-evaluate the latest code changes before the pull request can be merged.

Exam trap

The trap here is that candidates may confuse 'stale reviews are not dismissed' with the default behavior of Azure DevOps, but the exhibit explicitly shows the 'Reset code reviewer votes when there are new changes' checkbox is enabled, which forces dismissal.

How to eliminate wrong answers

Option A is wrong because the exhibit does not show any exemption for admins from the review requirement; the policy applies equally to all users unless explicitly configured otherwise. Option C is wrong because when 'Reset code reviewer votes when there are new changes' is enabled, stale reviews are dismissed, not retained. Option D is wrong because the policy still requires the minimum number of approvals (2) to be met; the PR cannot be merged without the required reviews.

Practice this question →

36

Multi-Selecthard

Which TWO actions should you take to implement Git-based source control for a large enterprise with multiple teams and a single repository (monorepo)? (Select TWO.)

Select 2 answers

A.Require all teams to work on a single branch

B.Use Git submodules to separate team code

C.Use forking workflow for each team

D.Configure path-based branch policies

E.Use sparse checkout to reduce clone time

AnswersD, E

Path-based policies enforce reviews per team area.

Why this answer

Using sparse checkout reduces clone size. Path-based branch policies enforce team-specific reviews. Forking is not typical for monorepos.

Submodules introduce complexity. Single branch for all teams causes conflicts.

Practice this question →

37

MCQmedium

Your team uses a monorepo in Azure Repos containing multiple projects. You want to set up CI/CD so that only the projects affected by a commit are built and deployed. Which approach should you use?

A.Use Git hooks to detect changes and run only the relevant build scripts locally.

B.Create separate Azure Pipelines for each project, each configured to trigger on changes to that project's folder.

C.Use a single YAML pipeline that includes all projects, and use the 'condition' keyword to skip steps based on changed files.

D.Use a single YAML pipeline with path-based triggers and path filters in the 'trigger' section for each project's folder.

AnswerD

Path filters ensure the pipeline only triggers when files in specific paths are changed.

Why this answer

Option D is correct because Azure Pipelines supports path-based triggers in the `trigger` section of a YAML pipeline, allowing you to specify include/exclude patterns for folders. When a commit changes files only under a specific project's folder, only that project's pipeline is triggered, ensuring efficient CI/CD by building and deploying only affected projects.

Exam trap

The trap here is that candidates often confuse path-based triggers (which control when a pipeline runs) with conditions (which control whether steps run after the pipeline has already started), leading them to choose option C incorrectly.

How to eliminate wrong answers

Option A is wrong because Git hooks are client-side scripts that run locally on a developer's machine, not in the CI/CD pipeline, and they cannot enforce centralized build triggers or deployment automation. Option B is wrong because creating separate pipelines for each project is a valid approach but is not the single YAML pipeline approach described in the question; the question asks for a single pipeline solution, and separate pipelines would require managing multiple pipeline definitions. Option C is wrong because the `condition` keyword in YAML pipelines evaluates at runtime based on variables or expressions, not directly on changed files; it cannot skip steps based on which files changed in a commit without additional logic like `git diff` commands, making it less efficient and more complex than path-based triggers.

Practice this question →

38

MCQmedium

Your company is a startup developing a mobile application with a small team of 5 developers. You use GitHub Free and want to implement a simple but effective branching strategy that supports continuous delivery. The team wants to release new features every week and be able to hotfix critical bugs quickly. They currently have a main branch and feature branches, but sometimes features are merged to main before they are fully tested, causing issues. You need to recommend a strategy that minimizes risk while keeping the process lightweight. The team does not want to use long-lived branches. What should you recommend?

A.Use a single main branch and create release branches for each weekly release; features are merged to release branches, then release branches are merged to main after testing.

B.Use GitHub Flow: developers create feature branches from main, open pull requests with required CI and at least one review, then merge to main. Hotfixes follow the same process.

C.Allow developers to commit directly to main but require all commits to pass CI and be reviewed by at least one other developer after the fact.

D.Adopt GitFlow with develop and release branches.

AnswerB

GitHub Flow is lightweight, supports CI, and allows quick hotfixes.

Why this answer

GitHub Flow is the simplest and most effective strategy for a small team using GitHub Free that wants continuous delivery without long-lived branches. By requiring feature branches, pull requests with CI checks, and at least one review before merging to main, it ensures that all code is tested and reviewed before integration, preventing untested features from breaking main. Hotfixes follow the same lightweight process, allowing quick, safe patches without additional branch overhead.

Exam trap

The trap here is that candidates often overcomplicate branching strategies for small teams, mistakenly choosing GitFlow (Option D) or release branches (Option A) when GitHub Flow's simplicity and built-in CI/review gates perfectly address the need for risk mitigation without long-lived branches.

How to eliminate wrong answers

Option A is wrong because creating release branches for each weekly release adds unnecessary complexity and long-lived branches, contradicting the team's desire to avoid them; merging features to release branches before testing still risks untested code reaching production. Option C is wrong because allowing direct commits to main with post-hoc review violates the principle of protecting main from broken code; CI and review must happen before merge to prevent issues, not after. Option D is wrong because GitFlow introduces develop and release branches that are long-lived and overly complex for a 5-person startup doing weekly releases, adding overhead that contradicts the lightweight requirement.

Practice this question →

39

MCQeasy

Your team uses Git and wants to ensure that all commits follow a consistent message format. Which approach should you use?

A.Add a step in Azure Pipelines to validate commit messages

B.Use a client-side Git hook (commit-msg) to validate the message

C.Create a GitHub Actions workflow that checks commit messages on push

D.Configure a branch policy in Azure Repos to enforce commit message format

AnswerB

Client-side hooks enforce locally before commit.

Why this answer

A client-side Git hook, specifically the commit-msg hook, runs locally on the developer's machine before the commit is finalized, allowing immediate validation of the commit message format. This ensures that every commit adheres to the team's convention at the point of creation, without relying on server-side enforcement or pipeline execution.

Exam trap

The trap here is that candidates often assume server-side enforcement (branch policies or pipeline validation) is the only way to enforce commit message standards, overlooking the fact that client-side hooks provide immediate, local validation before the commit is ever recorded.

How to eliminate wrong answers

Option A is wrong because adding a step in Azure Pipelines validates commit messages only after the code is pushed to the remote repository, which is too late to prevent non-compliant commits from being created locally and pushed. Option C is wrong because a GitHub Actions workflow that checks commit messages on push also runs after the push event, meaning non-compliant commits can still be pushed before the workflow detects the issue. Option D is wrong because branch policies in Azure Repos can enforce certain conditions (e.g., required reviewers, build validation) but do not natively support validating commit message format; they cannot inspect or reject commits based on message content.

Practice this question →

40

MCQmedium

Your team is using GitHub Flow for a web application. Developers create feature branches from main, make changes, and open pull requests. Recently, several pull requests were merged without required reviews because the branch protection rules were not enforced on the main branch. What should you do to ensure all pull requests to main require at least one reviewer?

A.Enable the 'Require a pull request before merging' rule in branch protection for main, and set 'Required approvals' to 1.

B.Configure the repository to automatically delete head branches after pull requests are merged.

C.Enable the 'Require branches to be up to date' rule in branch protection for main.

D.Add a CODEOWNERS file and configure it so that every file has at least one owner.

AnswerA

This enforces that pull requests require at least one approval before merging.

Why this answer

Option B is correct because branch protection rules in GitHub can enforce required pull request reviews before merging. Option A is incorrect because deleting the branch after merge does not enforce reviews. Option C is incorrect because require branches to be up to date is not the same as requiring reviews.

Option D is incorrect because code owners are optional, not mandatory.

Practice this question →

41

MCQhard

Your organization uses GitHub and wants to implement a monorepo strategy for multiple related projects. Which approach best optimizes CI/CD pipeline performance by only building projects that have changed?

A.Use a single workflow that builds all projects on every push

B.Use submodules to separate projects

C.Use workflow templates and composite actions

D.Use path filters in GitHub Actions workflows

AnswerD

Triggers only for changed paths.

Why this answer

Option D is correct because GitHub Actions path filters (using `on.push.paths` or `on.pull_request.paths`) allow you to trigger workflows only when changes are made to specific directories or files. In a monorepo, this ensures that CI/CD pipelines run exclusively for the projects that have been modified, avoiding unnecessary builds and significantly improving performance.

Exam trap

The trap here is that candidates confuse workflow reuse mechanisms (templates, composite actions) with conditional execution, or assume submodules are the standard monorepo approach, when in fact path filters are the native and efficient way to achieve selective builds in GitHub Actions.

How to eliminate wrong answers

Option A is wrong because a single workflow that builds all projects on every push ignores the monorepo optimization goal—it would rebuild unchanged projects, wasting compute time and slowing feedback loops. Option B is wrong because submodules are designed for managing external dependencies or separate repositories, not for optimizing CI/CD within a monorepo; they add complexity and do not inherently provide path-based build skipping. Option C is wrong because workflow templates and composite actions are reuse and abstraction mechanisms, not a solution for conditional execution based on changed paths; they help reduce duplication but do not control which projects are built.

Practice this question →

42

MCQeasy

Your organization is adopting a trunk-based development strategy with short-lived feature branches. Which branch policy should you enforce to ensure that code is integrated frequently and conflicts are minimized?

A.Allow direct pushes to main branch for senior developers

B.Require a minimum number of reviewers and enforce a squash merge strategy

C.Create release branches for each production deployment

D.Require all merges to be fast-forward only

AnswerB

Squash merges keep history linear and reviews ensure quality.

Why this answer

In a trunk-based development strategy with short-lived feature branches, the goal is to integrate code frequently and minimize merge conflicts. Requiring a minimum number of reviewers ensures code quality and team awareness, while enforcing a squash merge strategy collapses all feature branch commits into a single commit on the main branch, keeping the history linear and clean. This approach reduces the risk of complex merge conflicts and supports continuous integration by encouraging small, frequent merges.

Exam trap

The trap here is that candidates often confuse trunk-based development with GitFlow and choose option C (release branches), or they mistakenly think fast-forward-only merges (option D) are required for trunk-based strategies, when in fact squash merges are the recommended approach to maintain a clean, linear history.

How to eliminate wrong answers

Option A is wrong because allowing direct pushes to the main branch bypasses pull request reviews and branch policies, which undermines the trunk-based strategy's need for controlled, frequent integration and can lead to untested code and conflicts. Option C is wrong because creating release branches for each production deployment is a practice for GitFlow or release-based strategies, not trunk-based development, which focuses on keeping the main branch always deployable and avoids long-lived branches. Option D is wrong because requiring all merges to be fast-forward only would prevent merge commits entirely, making it impossible to enforce squash merges or maintain a clear history of feature integration; fast-forward merges are typically used with rebase strategies, not trunk-based development with short-lived branches.

Practice this question →

43

Multi-Selecteasy

Which THREE are common Git branching strategies used by development teams? (Select THREE.)

Select 3 answers

A.GitFlow

B.Trunk-based development

C.Feature branching

D.Monorepo

E.Centralized version control

AnswersA, B, C

GitFlow uses develop and feature branches.

Why this answer

GitFlow, Trunk-based development, and Feature branching are common strategies. Centralized version control is not a Git branching strategy. Monorepo is a repository structure, not a branching strategy.

Practice this question →

44

MCQhard

Your team is migrating from TFVC to Git in Azure Repos. Developers frequently work on the same files simultaneously. Which Git workflow should you recommend to minimize merge conflicts?

A.GitFlow

B.Forking workflow

C.Feature branch workflow

D.Centralized workflow

AnswerC

Short-lived feature branches merged frequently reduce conflicts.

Why this answer

The feature branch workflow is ideal for minimizing merge conflicts when developers work on the same files simultaneously because each developer creates a short-lived branch off the main branch for their specific feature or fix, commits frequently, and merges back via pull requests. This isolates changes until they are ready, reducing the surface area for conflicts compared to long-lived branches. Git's merge or rebase strategies within this workflow allow for incremental conflict resolution, which is more manageable than resolving large conflicts from divergent histories.

Exam trap

The trap here is that candidates often confuse GitFlow's structured branching model with being conflict-minimizing, when in fact its long-lived branches increase conflict risk, while the simpler feature branch workflow with frequent integration is more effective for simultaneous edits.

How to eliminate wrong answers

Option A is wrong because GitFlow introduces long-lived branches (develop, release, hotfix) that can diverge significantly, increasing the likelihood of merge conflicts when multiple developers work on the same files simultaneously. Option B is wrong because the forking workflow is designed for open-source contributions where contributors don't have direct repository access; it adds overhead of managing forks and cross-repo synchronization, which doesn't inherently minimize merge conflicts for a team with direct access. Option D is wrong because the centralized workflow mimics TFVC by having all developers commit directly to a single branch (e.g., main), which maximizes the chance of merge conflicts when multiple people edit the same files concurrently, as there is no isolation of changes.

Practice this question →

45

Multi-Selecthard

Which THREE practices are recommended when implementing a Git branching strategy for a team using Azure Repos?

Select 3 answers

A.Delete branches after they are merged.

B.Allow force pushes to shared branches to clean up history.

C.Use short-lived feature branches that are merged within a day.

D.Keep feature branches alive for the entire sprint.

E.Require build validation on pull requests to the main branch.

AnswersA, C, E

Keeps repository clean and avoids confusion.

Why this answer

Options A, B, and D are correct. A: Short-lived branches reduce merge conflicts. B: Build validation in branch policies ensures quality.

D: Deleting branches after merge keeps repository clean. C is wrong because long-lived feature branches increase complexity. E is wrong because force pushing can rewrite history and disrupt collaboration.

Practice this question →

46

MCQmedium

You receive a webhook notification from Azure Pipelines with the above payload. The build for the 'feature/logging' branch failed. You want to automatically create a work item to track the fix. What should you configure in Azure DevOps?

A.Add a branch policy on 'feature/logging' to require a successful build before merging.

B.Enable the 'Create work item on failure' option in the pipeline settings.

C.Use a GitHub Actions workflow to create an issue on failure.

D.Create a service hook subscription to listen for build failures and call Azure Boards API.

AnswerB

Automatically creates a work item when a build fails.

Why this answer

Option B is correct because Azure Pipelines provides a built-in setting called 'Create work item on failure' that automatically generates a work item (e.g., a bug or task) in Azure Boards whenever a pipeline run fails. This directly meets the requirement to track the fix for the failed build on the 'feature/logging' branch without requiring external integrations or manual steps.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing a manual or external integration (like service hooks or GitHub Actions) when Azure Pipelines already provides a simple, built-in configuration option for automatic work item creation on failure.

How to eliminate wrong answers

Option A is wrong because adding a branch policy to require a successful build before merging is a preventative measure that blocks merging if the build fails, but it does not automatically create a work item to track the fix. Option C is wrong because the scenario uses Azure Pipelines, not GitHub Actions; while a GitHub Actions workflow could create an issue, it is not applicable to an Azure Pipelines webhook notification. Option D is wrong because creating a service hook subscription to listen for build failures and call the Azure Boards API is a valid but unnecessarily complex approach; the built-in 'Create work item on failure' option achieves the same result with less configuration and is the recommended method.

Practice this question →

47

Multi-Selecthard

Which THREE are best practices for managing secrets in GitHub Actions workflows?

Select 3 answers

A.Pass secrets as environment variables to actions.

B.Use environment secrets to restrict access to specific workflows.

C.Store the same secret in multiple repositories for consistency.

D.Enable secret scanning and push protection in the repository settings.

E.Store secrets as GitHub Actions secrets instead of hardcoding them in the workflow file.

AnswersB, D, E

Environment secrets allow granular control.

Why this answer

Option A is correct because secrets should be stored as Actions secrets, not in YAML. Option B is correct because access can be limited to specific workflows. Option C is correct because secrets should be masked in logs.

Option D is wrong because secrets should not be shared across repositories unless necessary. Option E is wrong because environment variables are visible in logs.

Practice this question →

48

MCQhard

Your company has multiple teams working on a monorepo in Azure Repos. You need to enforce that changes to the /src/api folder require approval from the API team, while changes to /src/web require approval from the Web team. Which branch policy feature should you use?

A.Require a minimum number of reviewers

B.Automatically include code reviewers

C.Path filters in branch policy

D.Use separate repositories for each team

AnswerC

Path filters allow scoping policy to specific file paths.

Why this answer

Path filters in branch policy allow you to define conditions that trigger specific policy requirements based on the files changed in a pull request. By configuring a path filter for /src/api, you can require approval from the API team only when files in that folder are modified, and a separate path filter for /src/web can require approval from the Web team. This ensures that each team's approval is enforced only for their respective code areas within the monorepo.

Exam trap

The trap here is that candidates often confuse 'automatically include code reviewers' (which just adds reviewers to all PRs) with the ability to conditionally enforce approval based on file paths, leading them to choose option B instead of the correct path filter feature.

How to eliminate wrong answers

Option A is wrong because 'Require a minimum number of reviewers' enforces a blanket number of approvals for all pull requests, without any ability to differentiate based on which files are changed. Option B is wrong because 'Automatically include code reviewers' adds specific reviewers to all pull requests but does not conditionally enforce their approval based on file paths. Option D is wrong because using separate repositories for each team would break the monorepo structure, which is explicitly stated as a requirement, and would introduce additional overhead for cross-team dependencies and integration.

Practice this question →

49

MCQeasy

Your development team uses GitHub Enterprise and wants to automatically synchronize code from a public GitHub repository to their private repository every morning. What feature should they use?

A.Webhooks from the public repository to trigger a sync pipeline.

B.A scheduled GitHub Actions workflow that fetches from the public repo and pushes to the private repo.

C.Git submodules to link the public repository as a subdirectory.

D.GitHub repository mirroring to automatically mirror the public repo.

AnswerB

Scheduled workflows can run at a specified time using cron syntax.

Why this answer

B is correct because a scheduled GitHub Actions workflow can periodically fetch changes from the public repository (using `git fetch` or `git pull`) and push them to the private repository. This approach avoids the need for external triggers and works even when the public repo does not send webhooks to your private environment. The schedule is defined using cron syntax in the workflow YAML, ensuring automatic daily synchronization.

Exam trap

The trap here is that candidates often assume webhooks (Option A) are the only way to trigger automation, forgetting that webhooks require external network access and cannot be sent from a public repo to a private GitHub Enterprise instance without a proxy or custom relay.

How to eliminate wrong answers

Option A is wrong because webhooks from a public repository cannot be configured to target a private GitHub Enterprise instance—webhooks require a publicly accessible endpoint, and the private repo's Actions runner would not receive the event directly. Option C is wrong because git submodules only link a specific commit from the public repo as a subdirectory; they do not automatically synchronize changes on a schedule and require manual updates. Option D is wrong because GitHub repository mirroring is a one-time or manual setup that mirrors an entire repository, but it does not support scheduled synchronization and is typically used for migrating repos, not for ongoing daily syncs from a public source.

Practice this question →

50

MCQhard

Your company is migrating from TFVC to Git in Azure Repos. The repository contains a large number of binary files (e.g., .dll, .exe) that are frequently updated. You need to minimize repository size and clone time. What should you include in your migration plan?

A.Perform a shallow clone of the last commit only.

B.Use Git LFS to track binary files.

C.Use sparse checkout to exclude binary files from the working tree.

D.Use TFVC to Git converter with default settings.

AnswerB

Git LFS replaces large files with pointers, keeping the repo lean.

Why this answer

Option B is correct because Git LFS (Large File Storage) replaces large binary files in the repository with lightweight text pointers, storing the actual binary content in external storage. This prevents the repository from bloating with frequently updated binaries, reducing clone time and repository size since only the pointers are cloned.

Exam trap

The trap here is that candidates often confuse sparse checkout (which only affects the working tree) with a solution for repository size, or assume a shallow clone is sufficient without realizing it does not prevent binary bloat from accumulating in the repository history.

How to eliminate wrong answers

Option A is wrong because a shallow clone of the last commit only reduces clone time initially but does not address the underlying issue of binary files bloating the repository; future fetches and pushes will still transfer the full binary history. Option C is wrong because sparse checkout only controls which files appear in the working tree, but the binary files remain in the repository history and are still cloned, so it does not reduce repository size or clone time. Option D is wrong because using a TFVC-to-Git converter with default settings will convert all history including binary files as-is, leading to a large Git repository without any optimization for binary files.

Practice this question →

51

MCQmedium

Your team uses a monorepo in Azure Repos. Developers frequently commit directly to the main branch, causing build failures. You need to enforce a policy that requires all changes to go through pull requests with at least one reviewer. What should you configure?

A.Configure a repository policy to require a pull request for all branches.

B.Create a service hook to reject commits to main that are not from pull requests.

C.Configure a branch policy on the main branch to require a minimum number of reviewers.

D.Enable the 'Require a minimum number of reviewers' setting in the project settings.

AnswerC

Branch policies on main can enforce pull request requirements and reviewer count.

Why this answer

Option C is correct because Azure Repos allows you to configure branch policies on specific branches (like main) to enforce that all changes must come through pull requests and require a minimum number of reviewers. This directly addresses the need to prevent direct commits to main and ensure code review before merging.

Exam trap

The trap here is that candidates often confuse project-level settings with branch-level policies, or mistakenly think service hooks can enforce commit restrictions, when in fact Azure Repos requires explicit branch policy configuration on the target branch to enforce pull request requirements and reviewer counts.

How to eliminate wrong answers

Option A is wrong because configuring a repository policy to require a pull request for all branches would apply the restriction to every branch, including feature branches, which is overly broad and not the specific requirement to protect only the main branch. Option B is wrong because service hooks are used to trigger external events (e.g., webhooks) based on repository actions, not to reject commits; they cannot enforce branch policies or block direct commits. Option D is wrong because the 'Require a minimum number of reviewers' setting is not available in project settings; it is a branch policy configuration that must be applied at the branch level within the repository settings.

Practice this question →

52

Multi-Selecteasy

Which TWO Git operations are considered dangerous and should be used with caution because they rewrite history? (Select TWO.)

Select 2 answers

A.git fetch

B.git push --force

C.git merge

D.git rebase

E.git revert

AnswersB, D

Force push can overwrite remote history.

Why this answer

Option B is correct because `git push --force` overwrites the remote branch history with the local branch, discarding any commits on the remote that are not in the local history. This can cause other collaborators to lose work if they have based changes on the overwritten commits, making it a history-rewriting operation that must be used with caution.

Exam trap

The trap here is that candidates often confuse `git revert` with `git reset` or think `git merge` rewrites history, but the key distinction is that only operations that change existing commit SHAs (like rebase and force push) are considered history-rewriting and dangerous.

Practice this question →

53

MCQeasy

Your team uses Git with a trunk-based development strategy. They want to ensure that all code changes are integrated into the main branch at least once a day, and that branch lifetimes are short. Which practice best supports this?

A.Developers use GitFlow with develop and feature branches, merging to develop daily and to main at release.

B.Developers commit directly to a release branch, and then the release branch is merged to main at the end of the sprint.

C.Developers work on long-lived feature branches and merge to main only after all features are complete.

D.Developers work on short-lived feature branches (less than a day) and merge to main via pull requests after successful CI.

AnswerD

Short-lived branches and frequent merges align with trunk-based development.

Why this answer

Option D is correct because trunk-based development emphasizes short-lived feature branches (typically less than a day) that are merged into the main branch via pull requests after passing continuous integration (CI) checks. This ensures all code changes are integrated at least daily, keeping branch lifetimes short and reducing merge conflicts.

Exam trap

The trap here is that candidates may confuse GitFlow (option A) with trunk-based development, but GitFlow's long-lived develop and feature branches directly contradict the requirement for daily integration into main and short branch lifetimes.

How to eliminate wrong answers

Option A is wrong because GitFlow uses long-lived develop and feature branches, with merges to main only at release, which violates the trunk-based requirement of daily integration into main. Option B is wrong because committing directly to a release branch and merging only at sprint end creates long-lived branches and delays integration, contradicting the need for daily main branch updates. Option C is wrong because long-lived feature branches delay integration until all features are complete, which is the opposite of trunk-based development's short-lived branch and frequent merge strategy.

Practice this question →

54

Multi-Selectmedium

Your team uses Azure Repos with a Git branching strategy. You need to ensure that all changes to the release branch are reviewed by at least two approvers and that builds succeed before merging. Which TWO branch policy settings should you enable?

Select 2 answers

A.Build validation

B.Work item linking

C.Minimum number of reviewers (set to 2)

D.Require a clean fast-forward merge

E.Require a merge commit

AnswersA, C

Ensures builds succeed before merging.

Why this answer

Option B (minimum number of reviewers) and Option C (build validation) are correct. Option A is wrong because it's not a standard policy. Option D is wrong because it's for linear history.

Option E is wrong because it's not a policy setting.

Practice this question →

55

MCQmedium

Your organization needs to enforce that every commit to the main branch in Azure Repos is associated with a work item from Azure Boards. What should you configure?

A.Add a branch policy on main that requires a linked work item for all pushes.

B.Create a pre-receive hook in the repository to reject commits without a work item.

C.Enable the 'Gated check-in' option in the branch policy for main.

D.Configure a pull request policy that requires a linked work item, and enforce that all merges to main are via pull request.

AnswerA

Azure Repos branch policies can require linked work items for any push to the branch.

Why this answer

Option A is correct because Azure Repos branch policies include a specific policy to 'Require a linked work item' for all pushes to a branch. This policy enforces that every commit pushed directly to the main branch must be associated with a work item from Azure Boards, ensuring traceability and compliance with your organization's requirements.

Exam trap

The trap here is that candidates often confuse 'Require a linked work item' branch policy with pull request policies, but the question explicitly asks for enforcement on 'every commit to the main branch,' which includes direct pushes, so the correct answer is the branch policy that applies to all pushes, not just pull request merges.

How to eliminate wrong answers

Option B is wrong because Azure Repos does not support pre-receive hooks; that feature is specific to GitHub or on-premises Git servers. Option C is wrong because 'Gated check-in' (also known as 'Build validation') is a branch policy that triggers a build before accepting a push, but it does not enforce work item association. Option D is wrong because while a pull request policy requiring a linked work item can enforce work item association for PR merges, it does not cover direct pushes to main; to enforce the requirement for all commits, you must also restrict direct pushes by requiring pull requests, which is not stated in the option.

Practice this question →

56

MCQmedium

Your team uses GitHub and wants to automatically link pull requests to work items in Azure Boards. What should you configure?

A.Add a repository secret with Azure Boards connection string

B.Install the Azure Boards app for GitHub and configure the integration

C.Configure branch protection rules to require a linked work item

D.Create a GitHub Actions workflow that posts comments to Azure Boards

AnswerB

This integration provides automatic linking.

Why this answer

The Azure Boards app for GitHub is the official integration that synchronizes work items with GitHub commits, branches, and pull requests. Once installed and configured, it automatically links pull requests to Azure Boards work items based on mention patterns (e.g., 'AB#123') in the PR description or commit messages, enabling traceability without custom scripting.

Exam trap

The trap here is that candidates confuse 'requiring a linked work item' (a branch protection rule) with 'automatically linking work items' (the integration), leading them to pick Option C, which enforces a precondition rather than establishing the actual linking mechanism.

How to eliminate wrong answers

Option A is wrong because repository secrets are used for storing sensitive tokens or credentials (e.g., for GitHub Actions), not for establishing a cross-service integration like Azure Boards; there is no 'Azure Boards connection string' concept. Option C is wrong because branch protection rules can require a linked work item for PRs, but they do not automatically link PRs to work items—they only enforce that a link already exists, which requires the integration from Option B to be in place first. Option D is wrong because while a GitHub Actions workflow could theoretically post comments to Azure Boards, this is a brittle, custom workaround that duplicates the purpose-built Azure Boards app, which handles bidirectional linking, status updates, and automation natively.

Practice this question →

57

MCQmedium

Your team uses a monorepo in Azure Repos with multiple microservices. Developers frequently report merge conflicts due to long-lived feature branches. Which branching strategy minimizes merge conflicts while supporting continuous integration?

A.Use release branches for all development work and merge to main only at release time

B.Use GitFlow with separate develop and main branches, and long-lived feature branches

C.Use a forking workflow where each developer works in a personal fork and submits pull requests

D.Use trunk-based development with short-lived feature branches and frequent merges to main

AnswerD

Trunk-based development minimizes conflicts by integrating small changes often.

Why this answer

Trunk-based development with short-lived feature branches (typically lasting less than a day) minimizes merge conflicts by ensuring that changes are integrated into the main branch frequently, often multiple times per day. This approach reduces the divergence between branches, making conflicts less likely and easier to resolve. It also supports continuous integration by triggering automated builds and tests on every merge to main, aligning with the team's need for rapid feedback and reduced integration overhead.

Exam trap

The trap here is that candidates often associate GitFlow (Option B) with structured branching and mistakenly believe it reduces conflicts, but in reality, its long-lived feature branches increase conflict frequency and hinder continuous integration, making trunk-based development (Option D) the correct choice for minimizing conflicts and supporting CI.

How to eliminate wrong answers

Option A is wrong because using release branches for all development work and merging only at release time creates long-lived branches that accumulate significant divergence, leading to frequent and complex merge conflicts, and it violates CI principles by delaying integration. Option B is wrong because GitFlow with separate develop and main branches and long-lived feature branches encourages prolonged branch lifetimes, increasing the risk of merge conflicts and making continuous integration difficult due to infrequent merges to the main integration branch. Option C is wrong because a forking workflow, while useful for open-source projects with external contributors, introduces additional overhead in synchronizing forks and does not inherently reduce merge conflicts; it can actually increase them if forks diverge significantly before submitting pull requests.

Practice this question →

58

MCQhard

Your company uses Azure Repos with a Git branching strategy that includes a main branch, a develop branch, and feature branches. You need to enforce that only designated release managers can merge changes from develop into main, while developers can create feature branches off develop and merge pull requests into develop. What is the best way to implement this?

A.Configure branch policies on main to require a minimum number of reviewers from the release manager group, and set the 'Allow users to create pull requests' permission to only include release managers.

B.Use GitHub branch protection rules to require pull request reviews from release managers on main.

C.Set the main branch to read-only for all users except release managers using the 'Security' tab in repository settings.

D.Require a successful build for all branches and set the build pipeline to only run for release manager commits.

AnswerA

This allows only release managers to create pull requests into main, enforcing the desired control.

Why this answer

Option C is correct because branch policies in Azure Repos can restrict who can push or merge to a branch, and you can set different policies for main and develop. Option A is incorrect because restricting all users except release managers from creating pull requests into main is not sufficient if developers can push directly. Option B is incorrect because branch protection is a GitHub concept, not Azure Repos.

Option D is incorrect because requiring a successful build is good practice but does not restrict who can merge.

Practice this question →

59

MCQmedium

Your team uses GitHub and wants to prevent direct pushes to the main branch. Only pull requests with at least one approval should be allowed to merge. Which GitHub feature should you use?

A.Repository rulesets

B.Branch protection rules

C.CODEOWNERS file

D.GitHub Actions

AnswerB

Branch protection rules can require pull request reviews and block direct pushes.

Why this answer

Branch protection rules are the correct GitHub feature to enforce that direct pushes to the main branch are blocked and that only pull requests with at least one approval can merge. This is configured under the repository's Settings > Branches, where you can require pull request reviews before merging and restrict who can push directly.

Exam trap

The trap here is that candidates often confuse CODEOWNERS (which only requests reviews) with branch protection rules (which enforce mandatory reviews and block direct pushes), leading them to pick the wrong option when the question explicitly requires enforcement.

How to eliminate wrong answers

Option A is wrong because repository rulesets (a newer GitHub feature) can enforce similar restrictions but are designed for more granular, organization-wide policy management and are not the classic, straightforward solution for branch-specific push and PR approval requirements. Option C is wrong because the CODEOWNERS file defines individuals or teams that are automatically requested for review when certain files are changed, but it does not block direct pushes or enforce approval requirements. Option D is wrong because GitHub Actions is a CI/CD automation platform for workflows like testing and deployment, not a mechanism to enforce branch policies or merge requirements.

Practice this question →

60

MCQmedium

Refer to the exhibit. An Azure DevOps pipeline has the YAML configuration shown. A developer creates a pull request from a feature branch to the develop branch. What will happen?

A.The pipeline runs only if the PR is merged

B.The pipeline runs as a CI build on the feature branch

C.The pipeline runs as a PR validation build

D.The pipeline does not run automatically

AnswerD

Neither CI nor PR triggers match.

Why this answer

Option C is correct. The pipeline trigger includes develop branch, but the pr trigger only includes main. Since the PR target is develop (not main), the pr trigger does not fire.

The CI trigger fires on push to develop, but the PR is from feature to develop, so the CI trigger (on push to develop) would run only after the PR is merged. Option A is wrong because the PR trigger is for main only. Option B is wrong because the CI trigger is for main and develop, but the PR push is not to develop directly.

Option D is wrong because the pipeline does not run.

Practice this question →

61

MCQeasy

Your team uses GitHub and wants to enforce that all commits to the main branch are signed with a GPG key. Which branch protection rule should you configure?

A.Require pull request reviews before merging.

B.Require status checks to pass before merging.

C.Require linear history.

D.Require signed commits.

AnswerD

Enforces GPG or S/MIME signing on every commit.

Why this answer

Option D is correct because the 'Require signed commits' branch protection rule enforces that every commit pushed to the protected branch must be signed with a GPG key. This ensures cryptographic verification of the commit author's identity, directly addressing the requirement to enforce signed commits on the main branch.

Exam trap

The trap here is that candidates confuse 'Require signed commits' with 'Require status checks to pass before merging', mistakenly thinking a CI status check can enforce signing, but GitHub's built-in rule is the only way to natively reject unsigned commits at the server level.

How to eliminate wrong answers

Option A is wrong because requiring pull request reviews before merging enforces code review, not commit signing. Option B is wrong because requiring status checks to pass before merging enforces CI/CD pipeline checks (e.g., tests, builds), not cryptographic signing of commits. Option C is wrong because requiring linear history enforces a linear commit graph (no merge commits), but does not require commits to be signed with a GPG key.

Practice this question →

62

MCQeasy

Your organization uses GitHub for source control. You need to enforce that all pull requests require at least one approval and that branches must be up to date with the base branch before merging. Which branch protection rule settings should you enable?

A.Require branches to be up to date only

B.Require a pull request before merging only

C.Require status checks to pass before merging only

D.Require a pull request before merging and require branches to be up to date

AnswerD

Both settings enforce the required policies.

Why this answer

Option D is correct because GitHub branch protection rules allow you to enforce both that pull requests require at least one approval and that branches are up to date with the base branch before merging. The 'Require a pull request before merging' setting ensures that changes cannot be pushed directly to the protected branch and must go through a PR with required approvals. The 'Require branches to be up to date' setting (under 'Require status checks to pass before merging') ensures that the branch is tested against the latest base branch code, preventing stale merges.

Exam trap

The trap here is that candidates often think 'Require status checks to pass before merging' alone covers both the approval and up-to-date requirements, but it does not enforce the pull request workflow or the branch freshness check unless those specific status checks are explicitly configured.

How to eliminate wrong answers

Option A is wrong because 'Require branches to be up to date only' does not enforce that pull requests require approval; it only ensures the branch is current, leaving the repository vulnerable to direct pushes without review. Option B is wrong because 'Require a pull request before merging only' does not enforce that the branch is up to date with the base branch, allowing merges from outdated branches that may break the build. Option C is wrong because 'Require status checks to pass before merging only' does not inherently require a pull request or an approval; it only mandates that defined status checks (e.g., CI tests) succeed, which can be bypassed by direct pushes if no PR requirement is set.

Practice this question →

63

Multi-Selectmedium

Which TWO actions help reduce the size of a Git repository over time?

Select 2 answers

A.Use Git LFS for large binary files.

B.Squash commits before pushing to the remote.

C.Perform shallow clones when cloning the repository.

D.Regularly run 'git gc' to compress objects.

E.Use 'git filter-branch' or 'git filter-repo' to remove obsolete files from history.

AnswersA, E

Git LFS replaces large files with pointers, reducing repo size.

Why this answer

Option A is correct because Git LFS (Large File Storage) replaces large binary files with text pointers in the repository, storing the actual binary content in an external server. This prevents the repository from bloating with large files that are stored in full in every commit, significantly reducing the repository size over time.

Exam trap

The trap here is that candidates often confuse 'reducing repository size' with 'improving performance' or 'reducing clone time', leading them to select shallow clones or commit squashing as valid answers, when in fact only actions that remove or externalize file content (like LFS or history rewriting) actually shrink the repository size.

Practice this question →

64

MCQmedium

Refer to the exhibit. An Azure DevOps administrator has configured the branch policy for the main branch as shown. A developer attempts to push a commit directly to the main branch. What will happen?

A.The push triggers the build validation pipeline

B.The push is allowed because allowForcePush is false

C.The push is rejected because branch policies require a pull request

D.The push is allowed because requireLinearHistory is false

AnswerC

Branch policies enforce pull request requirement.

Why this answer

Option D is correct. The policy has 'requireLinearHistory' false, but 'allowForcePush' is false, and there is no branch policy that allows direct pushes. By default, branch policies require pull requests.

Option A is wrong because allowForcePush false prevents force pushes. Option B is wrong because requireLinearHistory false does not allow direct pushes. Option C is wrong because build validation does not block the push; it is part of PR policy.

Practice this question →

65

MCQmedium

Your team uses a monorepo in Azure Repos with multiple feature branches. You notice that merge conflicts frequently occur because developers are working on the same files. You want to reduce conflicts and improve collaboration. Which branching strategy should you recommend?

A.Use release branches for each deployment and cherry-pick commits from main.

B.Use trunk-based development with feature flags to merge small, frequent changes.

C.Use a single main branch and require all changes to be committed directly.

D.Use GitFlow with separate develop and release branches.

AnswerB

Short-lived branches and feature flags reduce conflicts.

Why this answer

Option C is correct because feature flags allow developers to merge incomplete features into the main branch without affecting users, reducing long-lived branches and conflicts. Option A is wrong because GitFlow has long-lived branches that increase conflict risk. Option B is wrong because trunk-based development with short-lived branches is the recommended approach.

Option D is wrong because release branches do not reduce conflicts on the main branch.

Practice this question →

66

MCQmedium

Your organization uses Azure Repos and has multiple Git repositories that share common code. You want to enable code reuse across these repositories without duplicating code. Which strategy should you use?

A.Use Git subtrees to merge the shared code into each repository

B.Publish the shared code as a NuGet package

C.Reference the shared repository as a Git submodule

D.Add the shared repository as an upstream source in Azure Artifacts

AnswerC

Submodules reference a specific commit.

Why this answer

Git submodules allow you to include a specific commit of a shared repository as a subdirectory within multiple parent repositories, enabling code reuse without duplication. When the shared code is updated, you can pull the latest commit into each parent repository, maintaining a clear link between the parent and the shared codebase. This is the native Git mechanism for referencing external repositories while preserving version control history.

Exam trap

The trap here is confusing package management (NuGet, Azure Artifacts) with source control strategies, leading candidates to choose options that distribute compiled artifacts rather than shared source code.

How to eliminate wrong answers

Option A is wrong because Git subtrees merge the entire history of the shared repository into the parent repository, duplicating the code and history, which defeats the goal of avoiding duplication. Option B is wrong because publishing shared code as a NuGet package is a binary distribution mechanism for .NET libraries, not a source control strategy for sharing live Git repository code across multiple repos. Option D is wrong because adding a shared repository as an upstream source in Azure Artifacts is used for package management (e.g., NuGet, npm), not for direct source code sharing via Git.

Practice this question →

67

MCQeasy

You need to enforce that every commit in your repository is associated with a work item in Azure Boards. Which mechanism should you use?

A.Use commit messages with work item IDs

B.Deploy a custom Git hook on the server

C.Configure a branch policy to require linked work items

D.Use the 'Require status checks' policy

AnswerC

Enforced in pull requests.

Why this answer

Option C is correct because Azure Repos branch policies include a setting to 'Require linked work items', which enforces that every pull request (and by extension, every commit merged through that PR) is associated with a work item in Azure Boards. This policy is enforced server-side at merge time, ensuring no commit can be merged without a linked work item, regardless of how the commit message is formatted.

Exam trap

The trap here is that candidates confuse a voluntary convention (commit message IDs) with an enforced policy, or they incorrectly assume that custom Git hooks are available in Azure Repos as they are in self-hosted Git servers.

How to eliminate wrong answers

Option A is wrong because commit messages with work item IDs are a convention, not an enforcement mechanism; they can be omitted or faked, and Azure Repos does not natively validate commit message content to block commits. Option B is wrong because custom Git hooks on the server are not supported in Azure Repos (which uses a managed Git service); hooks would need to be implemented via Azure DevOps service hooks or policies, not arbitrary server-side scripts. Option D is wrong because 'Require status checks' policy validates external CI/CD pipeline results (e.g., build validation), not work item association; it does not inspect commit-to-work-item links.

Practice this question →

68

Multi-Selecthard

Your GitHub organization has multiple repositories that share common CI/CD workflows. You want to centralize these workflows to reduce duplication. Which TWO approaches are valid?

Select 2 answers

A.Create reusable workflows in a central repository and use the 'uses' keyword in each repository's workflow to reference them.

B.Store the workflows in a central repository and use Git submodules to include them in each repository.

C.Create a template repository containing the workflows and use it as a template for new repositories.

D.Use branch protection rules to enforce that all workflows must be reviewed by a central team.

E.Publish the workflows as a GitHub Actions workflow library and install it in each repository.

AnswersA, C

Reusable workflows allow centralized maintenance.

Why this answer

Option A is correct because GitHub Actions supports reusable workflows that can be stored in a central repository and referenced from other repositories using the 'uses' keyword with the syntax 'owner/repo/.github/workflows/workflow.yml@ref'. This allows teams to define common CI/CD logic once and invoke it across multiple repositories, reducing duplication and simplifying maintenance.

Exam trap

The trap here is that candidates may confuse Git submodules or template repositories as valid methods for sharing live, updatable workflows, when in fact only reusable workflows (Option A) and template repositories (Option C, for initial setup) are officially supported approaches for centralizing CI/CD workflows in GitHub Actions.

Practice this question →

69

MCQhard

Your team uses GitHub and wants to enforce a policy that all commits to the main branch must be signed with a GPG key that is associated with the author's GitHub account. Which method should you use to enforce this?

A.Create a GitHub Actions workflow that runs a signature check after push

B.Use a commit status check to verify signatures

C.Add a branch protection rule that requires signed commits

D.Configure a repository ruleset that requires signed commits

AnswerC

Branch protection rules can enforce signed commits.

Why this answer

Option C is correct because branch protection rules in GitHub include a 'Require signed commits' setting that enforces GPG or S/MIME signature verification on all commits pushed to the protected branch. This policy is enforced server-side before the commit is accepted, ensuring that only commits signed with a key associated with the author's GitHub account are allowed into the main branch.

Exam trap

The trap here is that candidates confuse post-push checks (like Actions workflows or status checks) with pre-push enforcement, or they overcomplicate the solution by choosing repository rulesets when a simple branch protection rule is the intended answer for a standard GitHub team scenario.

How to eliminate wrong answers

Option A is wrong because a GitHub Actions workflow triggered after push cannot prevent the commit from being accepted; it can only react to the commit, not enforce a pre-commit policy. Option B is wrong because a commit status check is a post-push validation that reports a status (e.g., success/failure) but does not block the push itself; it can be used with branch protection, but the question asks for the method to enforce the policy, and the status check alone does not enforce it. Option D is wrong because repository rulesets are a feature for enterprise-managed repositories and are not the standard method for enforcing signed commits in a typical GitHub team workflow; the correct and simplest approach is a branch protection rule.

Practice this question →

70

Multi-Selecteasy

Which TWO actions should you take to proactively protect your repository from accidentally committing secrets? (Choose two.)

Select 2 answers

A.Enable branch protection rules

B.Use pre-commit hooks with tools like detect-secrets

C.Enable push protection in secret scanning

D.Use signed commits

E.Configure secret scanning alerts

AnswersB, C

Prevents committing secrets.

Why this answer

Option B is correct because pre-commit hooks, such as those using the detect-secrets tool, scan staged changes before a commit is finalized. This prevents secrets from ever entering the repository history, providing a proactive, client-side guard. Option C is correct because push protection in secret scanning blocks pushes that contain known secret patterns at the server side, preventing the secret from being stored in the remote repository.

Exam trap

The trap here is confusing reactive security measures (like alerts or branch policies) with proactive, blocking controls (like pre-commit hooks and push protection) that prevent secrets from being stored in the first place.

Practice this question →

71

MCQmedium

Your organization uses GitHub Copilot for pull request summaries. A developer notices that the AI-generated summary is inaccurate. Which step should the developer take to improve the quality of future summaries?

A.Disable Copilot for pull requests

B.Provide a detailed pull request description

C.Edit the description after generation

D.Ignore the inaccuracy

AnswerB

Better input leads to better AI output.

Why this answer

Providing a detailed pull request description helps Copilot generate more accurate summaries. Disabling Copilot is not necessary. Editing the summary once is a workaround but does not improve future generations.

Ignoring the issue does not help.

Practice this question →

72

MCQmedium

You work for a multinational company that uses Azure Repos. The compliance team requires that all code changes include a work item reference in the commit message. What is the most effective way to enforce this?

A.Create a script in the build pipeline that checks the commit message

B.Configure a client-side commit hook that validates the commit message

C.Set a branch policy that requires a linked work item for pull requests

D.Use a custom build task to automatically add the work item ID to the commit message

AnswerC

Branch policies enforce the requirement server-side before merge.

Why this answer

Option C is correct because a branch policy in Azure Repos that requires linked work items for pull requests enforces the compliance requirement at the server side, ensuring that every pull request merge includes a work item reference. This policy is enforced before the merge completes, making it a reliable and auditable method that cannot be bypassed by individual developers. It directly integrates with Azure Boards to validate the link, providing a centralized enforcement mechanism.

Exam trap

The trap here is that candidates often confuse client-side hooks (Option B) with server-side enforcement, not realizing that client-side hooks are optional and can be easily bypassed, whereas branch policies in Azure Repos provide mandatory, centralized enforcement that cannot be overridden by individual developers.

How to eliminate wrong answers

Option A is wrong because a build pipeline script that checks the commit message runs after the code is already pushed, meaning it can only fail the build but cannot prevent non-compliant commits from entering the repository; it also adds overhead and can be bypassed if the build is skipped. Option B is wrong because a client-side commit hook is only enforced locally on the developer's machine and can be easily disabled or bypassed by the developer, providing no centralized or reliable enforcement for the team. Option D is wrong because a custom build task that automatically adds a work item ID to the commit message does not enforce the requirement; it modifies the commit after the fact, which is not a valid approach for commit messages (which are immutable once created), and it does not ensure that the developer actually references a work item.

Practice this question →

73

MCQhard

Your team is adopting GitFlow with a main and develop branch. You need to ensure that hotfix branches are merged into both main and develop, but feature branches only into develop. What branch policy configuration should you implement?

A.Set the main branch to require all merges to come from pull requests, and for develop, allow direct pushes.

B.Use branch policies on main and develop that allow only certain source branches to merge, using branch naming conventions.

C.Configure a global policy that requires all branches to have a minimum number of reviewers.

D.Use a build validation policy to check the branch name and reject merges that do not follow the pattern.

AnswerB

Branch policies can restrict source branches via naming patterns.

Why this answer

Option B is correct because Azure Repos branch policies allow you to restrict which source branches can merge into a target branch using branch naming conventions. By configuring policies on `main` and `develop` that only permit merges from specific source patterns (e.g., `hotfix/*` for `main` and `develop`, and `feature/*` only for `develop`), you enforce the GitFlow workflow without relying on manual oversight or build validation logic.

Exam trap

The trap here is that candidates confuse build validation policies (which run after PR creation) with branch-level source branch restrictions (which prevent PR creation entirely), leading them to choose Option D despite it being a reactive rather than proactive control.

How to eliminate wrong answers

Option A is wrong because allowing direct pushes to `develop` bypasses pull request validation, which is required to enforce merge source restrictions and review requirements; it does not prevent feature branches from merging into `main`. Option C is wrong because a global policy requiring a minimum number of reviewers does not control which source branches can merge into specific target branches; it only adds review overhead without enforcing GitFlow merge rules. Option D is wrong because build validation policies run after a pull request is created and can reject based on branch name, but they cannot prevent the pull request from being created in the first place and are not a native branch policy for restricting source branches; they are more suitable for code quality checks.

Practice this question →

74

MCQhard

Refer to the exhibit. A developer runs 'git log --oneline --graph --decorate' and sees the output. Which Git workflow does this history most closely represent?

A.GitLab Flow

B.Trunk-based development

C.GitHub Flow

D.Git Flow

AnswerD

Git Flow uses feature branches with merge commits.

Why this answer

The output of `git log --oneline --graph --decorate` shows multiple long-lived branches (e.g., `develop`, `feature/*`, `release/*`, `hotfix/*`) with periodic merges back to `develop` and `main`. This branching structure with dedicated branches for features, releases, and hotfixes is the hallmark of Git Flow, which uses a strict branching model to manage releases and maintenance in parallel.

Exam trap

The trap here is that candidates see a graph with multiple branches and assume it represents GitHub Flow or trunk-based development, but the presence of both `develop` and `release` branches specifically indicates Git Flow, not simpler workflows.

How to eliminate wrong answers

Option A is wrong because GitLab Flow typically uses environment branches (e.g., `staging`, `production`) and feature branches that merge directly into `main`, not the multi-tiered `develop`/`release`/`hotfix` structure shown. Option B is wrong because trunk-based development keeps branches extremely short-lived (hours to a day) and merges directly to a single trunk (e.g., `main`), without long-lived `develop` or `release` branches. Option C is wrong because GitHub Flow uses a single `main` branch with short-lived feature branches that are merged via pull requests, lacking the `develop`, `release`, and `hotfix` branches visible in the graph.

Practice this question →

75

MCQmedium

Your team uses Git for source control. A developer accidentally committed a large binary file (500 MB) to the main branch. The push succeeded but other team members are now complaining about slow fetch times. What is the most efficient way to remove the file from the repository history?

A.Use 'git filter-repo' to remove the file from history

B.Add the file to .gitignore and push again

C.Use 'git revert' to undo the commit

D.Use BFG Repo-Cleaner

AnswerA

git filter-repo is the recommended tool for history rewriting.

Why this answer

Option A is correct because 'git filter-repo' is the recommended modern tool for permanently removing large files from Git history. It rewrites the repository's commit graph, eliminating the file from all commits, which reduces repository size and resolves slow fetch times for team members. Unlike BFG Repo-Cleaner, 'git filter-repo' is actively maintained and integrates natively with Git, making it the most efficient and reliable choice for this task.

Exam trap

The trap here is that candidates often confuse 'git revert' (which only adds a new commit to undo changes) with history-rewriting tools like 'git filter-repo' or BFG, not realizing that only history rewriting permanently removes a file from all commits and reduces repository size.

How to eliminate wrong answers

Option B is wrong because adding the file to .gitignore only prevents future tracking of the file; it does not remove the file from existing commits, so the large binary file remains in the repository history and continues to bloat fetch times. Option C is wrong because 'git revert' creates a new commit that undoes the changes of the original commit, but the large binary file remains in the commit history, so the repository size is not reduced and slow fetch times persist. Option D is wrong because BFG Repo-Cleaner is a valid tool for removing large files from history, but it is less efficient than 'git filter-repo' for this specific scenario; BFG is a Java-based tool that requires additional setup and is not as tightly integrated with Git's internals, making 'git filter-repo' the preferred choice in modern Git workflows.

Practice this question →

Page 1 of 2 · 95 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Design and implement a source control strategy questions.

Start 20-question session