Knowledge + Practice

CCNA Source Control Strategy Questions

75 of 83 questions · Page 1/2 · Source Control Strategy topic · Answers revealed

Practice these questions Exam hub 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

GitHub secret scanning is the correct feature because it automatically scans repositories for known patterns of secrets, including connection strings, API keys, and authentication tokens. It alerts on detected secrets and can partner with secret providers to help prevent exposure, directly addressing the need to ensure secrets are not left in source control.

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

3

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

Combining 'Require a minimum number of reviewers' and 'Build validation' enforces both peer review and a successful build pipeline. This ensures that changes are approved by the required reviewers and meet the build quality gate before merging, delivering comprehensive branch protection.

Why this answer

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 →

4

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

A pre-receive hook in GitHub executes on the server for every push and can reject commits with invalid message formats before they are accepted, providing a hard enforcement point that developers cannot bypass locally. This centralizes policy and guarantees consistent commit message history across all contributions.

Why this answer

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. Similarly, Azure Repos branch policies can include a commit message pattern check, which validates commit messages against a regex and rejects pushes with non-conforming messages. Both approaches enforce the standard on the server side, 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 →

5

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

This is correct because the branch policy has two relevant settings: 'Reset approvals on new push' is enabled, so existing approvals are invalidated when new commits are pushed, and the build validation policy has 'Queue new build on source update only' set to true, so a new build is automatically queued. Both actions occur as a direct result of the new push to the PR source branch.

Why this answer

The branch policy has 'Reset code review votes when new changes are pushed' enabled (resetOnSourcePush: true) and 'Build validation' with 'Automatically queue a new build when new changes are pushed' enabled (queueOnSourceUpdateOnly: true). When a new commit is pushed to an existing pull request, the existing approvals are reset, and a new build is automatically queued. Therefore, option C is correct.

Practice this question →

6

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

AnswerB

CODEOWNERS is repository-specific; GitHub does not support an organization-level CODEOWNERS file that applies across repositories. Placing it at the organization level would have no effect on individual repository's code review ownership, so each repo must still contain its own file.

Why this answer

In GitHub Enterprise, you can create a special repository named `.github` at the organization level. A CODEOWNERS file stored in that repository is applied as a default to all repositories in the organization, providing centralized management. Repository rulesets cannot require that a file exists; they enforce branch/tag rules such as required reviews and status checks, but not file existence.

Exam trap

The trap is that candidates assume organization-level CODEOWNERS does not exist, or believe rulesets can enforce file existence. In reality, a .github repository with a CODEOWNERS file serves as the organization-wide default, while rulesets are not designed for this.

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 →

7

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

Configure branch protection rules to require status checks to pass, so pull requests cannot be merged unless the specified CI checks (e.g., tests, builds, and linting) succeed. This enforces code quality gates automatically, ensuring that only code meeting defined criteria is integrated into the main branch.

Why this answer

Branch protection rules enforce required status checks (e.g., CI builds, code reviews) before merging, ensuring only validated changes enter protected branches—this supports code quality. GitHub secret scanning automatically detects known types of secrets in repositories and alerts on exposure, directly preventing secret leaks. Pre-commit hooks scan code for secrets before a commit is created, blocking accidental commits of credentials or tokens.

Together, A, D, and E address both secret prevention and code quality. Commit signing (C) verifies authorship but does not prevent secret exposure or enforce code quality checks.

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 →

8

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 →

9

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

Setting a branch policy on main that requires a build validation is the correct approach because Azure DevOps will run the specified security scan pipeline for every pull request targeting main and block the merge if the scan fails. Additionally, branch policies enforce the scan on every push to main and prevent bypasses, ensuring all code that enters the protected branch has passed the mandatory security validation.

Why this answer

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 →

10

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 rules can require signed commits, and a required status check can run a custom GitHub Action that verifies the commit author's email against an allowed domain. This combination successfully enforces both signature and email constraints during pulls.

Why this answer

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 →

11

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

With Git LFS, the large file's content is never committed into the local repository or pushed to the remote Git server; instead only a lightweight pointer file is tracked in history. This prevents the large binary from bloating every clone, fetch, and push, keeping the Git history lean and manageable.

Why this answer

Git LFS (Large File Storage) prevents large files from being stored directly in the Git repository history (option B). Instead, it stores a small pointer file in the repo while the actual large file content is stored externally, which reduces the size of the Git repository (option E). Options A, C, and D are incorrect because LFS does not automatically compress all files, replace .gitignore, or speed up diff operations for binary files.

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 →

12

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

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

13

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

git filter-branch rewrites the commit history by applying a filter (e.g., --index-filter or --tree-filter) to remove the file from every commit, making it as if the file never existed. This permanently removes the file from history, but it rewrites commit SHAs and requires force-pushing and coordination with all collaborators to avoid reintroducing the file.

Why this answer

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

14

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 replaces large files with small text pointers in the repository, while the actual binary content is stored in a separate external store. This keeps the Git history lightweight and avoids bloating the .git directory with large objects.

Why this answer

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 →

15

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

The 'dismiss_stale_reviews' setting is enabled, which automatically invalidates prior pull request approvals whenever new commits are pushed to the branch. This directly explains why previously granted approvals no longer count, forcing re-review after each update.

Why this answer

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 →

16

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 GitHub Actions pattern: you store a workflow file in a central repository and invoke it from other repositories using the `uses` keyword with a path like `owner/repo/.github/workflows/reusable.yml@ref`. This approach supports inputs, secrets, and version pinning, and is the recommended way to avoid duplicating CI/CD logic across many GitHub repositories.

Why this answer

The recommended approach is to create a central repository with reusable workflows and reference them using the 'uses' keyword. This is a native GitHub Actions feature that allows you to define shared workflow files in one repository and call them from any other repository in your organization. This ensures all workflows stay up to date centrally.

The other options are not recommended: B uses API scheduling which is unnecessary and harder to manage; C downloads workflows from blob storage as inline scripts which loses the benefits of shared workflow versioning; D uses Git submodules which are designed for code dependencies and do not integrate well with GitHub Actions workflow execution.

Practice this question →

17

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

AnswerA

git revert -m 1 HEAD is the correct approach because the -m 1 flag specifies the first parent (the mainline) as the baseline against which to reverse the changes brought in by the merge commit. This creates a new commit that undoes the merge's net effect on the main branch while preserving the original merge commit and the full branch history, making it a safe, non-destructive reversal for an already-integrated merge.

Why this answer

The 'Fix login bug' commit is a merge commit. To revert a merge commit while preserving its merge parent (i.e., the mainline), you must use `git revert -m 1 HEAD`. The `-m 1` flag specifies that the first parent (the main branch) should be kept, effectively reverting the changes brought by the merge.

Option C, `git revert HEAD`, would fail because Git requires the `-m` flag when reverting a merge commit. Option B destroys history, which is not desired. Option D uses `-m 2`, which would revert the changes from the secondary parent (the feature branch), not the merge itself.

Exam trap

The trap is that candidates assume `git revert HEAD` works for any commit, but reverting a merge commit requires the `-m` flag to specify which parent to keep. Without it, Git returns an error. Also, using `-m 2` would revert the wrong set of 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 →

18

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

GitLeaks and similar secret-scanning tools inspect repository history, staging areas, and CI/CD diffs for high-entropy strings and known provider patterns (e.g., AWS Access Key IDs, GitHub tokens). They are typically run as a pre-commit hook or a separate pipeline stage, so leaks are caught early before they propagate to forks or downstream branches. This is a detection control, not a prevention control; it complements secure storage options by providing visibility and enforcing policy on legacy codebases.

Why this answer

The recommended practices for managing secrets in a Git repository include using tools like GitLeaks to scan for accidentally committed secrets (Option A), using GitHub Secrets or Azure Pipelines secret variables (Option C), and using Azure Key Vault to store and retrieve secrets at build/release time (Option D). These approaches help avoid storing secrets directly in the repository. Option B is incorrect because storing secrets in an encrypted file committed to the repository still exposes them to anyone who can access the repo and the decryption key.

Option E is incorrect because committing a .env file with default values risks including sensitive data and is not a secure practice.

Practice this question →

19

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 is the correct choice when you want linear history: it takes each commit from the source branch and applies it onto the latest target branch tip, creating a straight-line history with no merge commit while preserving individual commits.

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 →

20

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 actions/labeler GitHub Action runs on the pull_request event and uses a declarative configuration file (typically .github/labeler.yml) to map file path patterns to labels. When a PR modifies files matching a pattern, the action automatically adds the corresponding label, making this the purpose-built, native GitHub solution for path-based auto-labeling.

Why this answer

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 →

21

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

A scheduled GitHub Actions workflow using the `schedule` event (cron) can run `git branch -d` commands or call the GitHub API to list branches filtered by `committer.date` older than 90 days, then delete them, automating branch cleanup at the repository level.

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

22

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

The branch policy sets requireApprovalCount to 2, meaning that two distinct reviewers (excluding those blocked by policy) must independently approve the PR before it can be completed. This is the correct interpretation of the policy.

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 →

23

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

Setting the minimum reviewers to two forces at least two approvals, while unchecking 'Allow users to approve their own changes' prevents the author from counting as one of them, thereby enforcing authentic peer review from two distinct eligible reviewers.

Why this answer

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 →

24

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

Delete the feature branch. In GitHub Flow, feature branches are ephemeral and should be deleted after their pull request is merged, because the merge already integrates all commits into main; leaving the branch creates stale references and confusion for future work.

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 →

25

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 →

26

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 correctly configures the 'push' trigger with the 'branches' filter set to 'main', using the proper plural key. As a result, the workflow will execute only when commits are pushed directly to the 'main' branch, ignoring pushes to other branches.

Why this answer

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 →

27

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

Push protection in Azure Repos is a built-in server-side feature that scans incoming commits for known secrets (such as connection strings, passwords, and API keys) and blocks the push if a secret is detected. This provides centralized, enforced protection that prevents secrets from ever entering the repository, directly addressing the need.

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 →

28

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

Branch protection rules prevent direct pushes to main and require pull requests to pass required status checks (e.g., CI pipeline) before merging, enforcing quality gates and reducing regressions.

Why this answer

Branch protection rules (B) enforce required status checks like CI builds and tests before merging, maintaining stability in a monorepo with many contributors. Code owners (D) automatically request reviewers from the responsible teams for changes in their respective paths, ensuring proper review and accountability. Path filters (E) trigger only the CI workflows relevant to the changed code, avoiding unnecessary builds and reducing feedback loops.

Storing large binaries in the repo (A) is poor practice, and a single build definition for all projects (C) is inefficient because it forces full builds on every change.

Exam trap

The trap here is that candidates confuse 'monorepo best practices' with 'single repo simplicity' and incorrectly assume a single build definition is efficient, when in reality path-filtered, modular CI is essential to avoid unnecessary builds and long feedback loops.

Practice this question →

29

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

Because `dismissStaleReviews` is enabled, any approval given before a new commit that changes the code is automatically dismissed, and the PR must obtain fresh approvals from the required number of reviewers before it can be completed.

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 →

30

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

Configuring path-based branch policies in Azure DevOps lets you assign specific reviewers and required checks to changes under particular directories (e.g., src/teamA), so each team enforces its own quality gates while still integrating into a shared trunk. This targets code review and CI to the relevant parts of the monorepo, improving both safety and development velocity.

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 →

31

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.

AnswerB

This can work but is harder to maintain than a single pipeline with path filters.

Why this answer

In a monorepo, to build and deploy only affected projects, create one Azure Pipeline per project and configure each with path-based triggers that include only that project's folder. This way, a commit touching a specific project triggers only that project's pipeline. While a single pipeline can use path filters and conditions to skip steps, the straightforward and recommended approach is separate pipelines.

Exam trap

Candidates often pick a single pipeline with path triggers (option D) thinking it will run only affected projects, but path triggers only decide whether the whole pipeline starts; to limit execution within a single pipeline, you need additional conditions. Separate pipelines per project are a cleaner solution.

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 →

32

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 a lightweight, trunk-based model where main is always releasable: short-lived feature branches, mandatory CI and pull-request reviews enforce quality before integration, and hotfixes follow the identical pull-request path so fixes reach production quickly without long-lived branches or complex release processes.

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 →

33

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

A client-side commit-msg hook executes on the developer's machine before the commit is finalized, allowing the message to be validated against a pattern and abort the commit if it does not conform. This is the only mechanism that prevents an invalid commit from ever existing in the local repository.

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 →

34

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

Enabling 'Require a pull request before merging' in branch protection forces every commit to main to be introduced via a pull request, which is the foundational mechanism for mandatory code review. When combined with 'Required approvals' set to 1, the merge is blocked until at least one reviewer has explicitly approved the changes, providing a hard enforcement of the team's review policy.

Why this answer

Branch protection rules in GitHub can enforce required pull request reviews before merging. By enabling 'Require a pull request before merging' and setting 'Required approvals' to 1, any pull request to main must have at least one reviewer approve before merging. Option B is incorrect because deleting head branches after merge does not enforce reviews.

Option C is incorrect because requiring branches to be up to date is about ensuring the branch is current with the base branch, not about requiring reviews. Option D is incorrect because CODEOWNERS are optional and do not enforce mandatory reviews unless branch protection rules are set accordingly.

Practice this question →

35

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

Path filters in GitHub Actions, using `on.push.paths` or `pull_request.paths`, allow workflows to trigger only when specific files or directories change, so only the affected projects are built and tested. This is a best practice for monorepos because it reduces CI resource usage and provides faster, targeted feedback.

Why this answer

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 →

36

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

Requiring a minimum number of reviewers ensures every change is verified before merging to main, while squash merging compresses the feature branch's commit history into a single linear commit on the trunk. This maintains a coherent, reversible history and avoids merge noise, making main always deployable.

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 →

37

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 is a branching model that maintains a long-lived develop branch alongside main, with feature branches for new work, release branches for staging, and hotfix branches for urgent fixes, providing strict release management and clear role separation.

Why this answer

GitFlow is a common branching strategy that uses a main branch (master/main) alongside develop, feature, release, and hotfix branches. It provides a structured model for managing releases, hotfixes, and parallel development, making it suitable for projects with scheduled release cycles.

Exam trap

The trap here is confusing repository management strategies (like monorepo) or version control system types (like centralized VCS) with actual Git branching strategies, leading candidates to select options that describe storage or system architecture rather than branch workflows.

Practice this question →

38

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 →

39

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

Deleting feature branches immediately after their merge keeps the repository's branch list focused on active work and prevents stale refs from persisting indefinitely. Stale branches can drift from the latest main, causing confusion about which code is still in use and potentially leading to accidental reverts or conflicting fixes.

Why this answer

The three recommended practices are: A) Delete branches after they are merged to keep the repository clean; C) Use short-lived feature branches that are merged within a day to reduce merge conflicts and promote continuous integration; E) Require build validation on pull requests to the main branch to ensure code quality. B is incorrect because force pushes should be avoided on shared branches as they can rewrite history and disrupt collaboration. D is incorrect because keeping feature branches alive for the entire sprint increases complexity and delays integration.

Practice this question →

40

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

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 →

41

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 →

42

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

A scheduled GitHub Actions workflow uses the `on: schedule` event with cron syntax to run at specified intervals. The workflow can fetch the latest commits from the public repository and then push them to the private repository, providing a fully automated and time-controlled sync mechanism.

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 →

43

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 stores binary files in a separate remote store and replaces them in Git with small text pointers, so cloning fetches only the pointers and downloads actual binaries on demand (via `git lfs fetch` or by checking out the working tree). This keeps the .git directory and clone time small, and Azure Repos fully supports Git LFS for repos, making it the correct solution for large binary files.

Why this answer

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 →

44

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

This is correct because Azure Repos branch polices on the main branch can require that all changes come through a pull request and specify a minimum number of reviewer approvals. This enforcement happens before merge, blocking direct pushes and insufficiently reviewed PRs, thus protecting the main branch.

Why this answer

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 →

45

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

git push --force is dangerous because it replaces the remote branch's ref, forcibly overwriting the remote history and potentially discarding commits that other team members have already based work on. This rewrites shared history and can permanently destroy others' changes; --force-with-lease provides a safer alternative by refusing to overwrite if the remote has moved.

Why this answer

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

46

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

Trunk-based development relies on short-lived feature branches that are typically less than a day old, with developers merging to main via pull requests only after successful continuous integration; this keeps main in a releasable state and enables rapid, small-batch integration.

Why this answer

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 →

47

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

Build validation (A) ensures that a pull request cannot be merged unless the source branch compiles successfully and passes all configured automated tests, which directly enforces the requirement that builds succeed before merging. Minimum number of reviewers (C) set to 2 enforces the policy that at least two distinct approvers must approve the pull request before it can be completed. Together, these two settings satisfy both conditions: successful builds and two-reviewer approval.

Exam trap

The trap here is that candidates often confuse 'minimum number of reviewers' with 'required reviewers' or mistakenly think 'work item linking' or 'merge strategy' policies can enforce approval counts or build success, when in fact they address completely different concerns.

Practice this question →

48

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.

AnswerD

Correct because by requiring all merges to main to be done via pull requests and enabling the 'Require a linked work item' policy on those pull requests, every commit to main will be associated with a work item.

Why this answer

In Azure Repos, the 'Require a linked work item' branch policy applies only to pull requests, not to direct pushes. To enforce that every commit to main is associated with a work item, you must require that all changes come through pull requests (via a branch policy requiring PRs) and then enable the 'Require a linked work item' policy on pull requests. This ensures that every commit merged into main via a PR has a linked work item.

Option A is incorrect because the 'Require a linked work item' branch policy does not apply to direct pushes; it only applies to pull request completions.

Exam trap

The trap is that candidates assume the 'Require a linked work item' branch policy applies to all pushes, but in Azure Repos it only applies to pull request completions. To enforce linked work items on every commit, you must first require pull requests for all changes to main.

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 →

49

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 →

50

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 →

51

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

By configuring branch policies on the main branch to require a minimum number of reviewers from the release manager group, you ensure that any changes to main are reviewed by designated release managers. Additionally, setting the 'Allow users to create pull requests' permission to only include release managers controls who can initiate pull requests into main. Option B is incorrect because branch protection rules are a GitHub feature, not available in Azure Repos.

Option C is incorrect because setting the main branch to read-only would prevent all pushes, including those from release managers, unless they are granted write permissions; however, this approach does not enforce pull request reviews and is less granular. Option D is incorrect because requiring a successful build does not restrict who can merge; it only ensures code quality.

Practice this question →

52

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

The CI trigger only includes `develop` and `main`, while the PR trigger only includes `main`; the exhibited feature-branch push/PR matches neither branch filter. Consequently, the pipeline has no automatic trigger event and will not run on its own.

Why this answer

The YAML configuration does not include a `trigger` or `pr` trigger, so by default the pipeline only runs on pushes to branches that have a pipeline configured, not on pull requests. Since the developer creates a PR from a feature branch to develop, and no trigger is defined for the feature branch or PR validation, the pipeline does not run automatically.

Exam trap

The trap here is that candidates assume a pull request automatically triggers a pipeline, but Azure DevOps requires an explicit `pr` trigger for PR validation builds, and without it, no automatic execution occurs.

How to eliminate wrong answers

Option A is wrong because the pipeline does not run on merge unless a trigger is defined for the target branch (develop) or the PR is configured to trigger on completion; without a trigger, no automatic run occurs. Option B is wrong because a CI build on the feature branch would require a `trigger` (e.g., `trigger: branches: include: ['feature/*']`) which is absent in the YAML. Option C is wrong because a PR validation build requires a `pr` trigger (e.g., `pr: branches: include: ['develop']`) which is not present in the configuration.

Practice this question →

53

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

Requiring signed commits is a branch protection rule that rejects any commit not cryptographically signed with a verified GPG or S/MIME key, authenticating the committer and ensuring content integrity. This directly enforces that every commit must be signed, exactly as the requirement demands.

Why this answer

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 →

54

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

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 →

55

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

The branch policy for the main branch requires that all changes be submitted via a pull request. When a developer attempts to push a commit directly to main, Azure Repos enforces this policy by rejecting the push. The push is blocked at the server level before any build validation or other checks occur.

Exam trap

The trap here is that candidates assume build validation or other policies are the primary gate, when in fact the 'Require a pull request before merging' setting is the first and most restrictive policy that blocks direct pushes regardless of other policy states.

How to eliminate wrong answers

Option A is wrong because the push is rejected before any build validation pipeline can be triggered; build validation only runs on pull request creation or updates, not on rejected direct pushes. Option B is wrong because allowForcePush being false only prevents force pushes, but the standard push is still blocked by the pull request requirement. Option D is wrong because requireLinearHistory being false does not affect the push rejection; linear history is a separate policy that controls merge commit types, not the ability to push directly.

Practice this question →

56

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

Trunk-based development with feature flags enables developers to merge small, frequent changes directly into the trunk behind a flag, keeping branches short-lived and integration burden low, which minimizes merge conflicts and supports continuous integration and delivery.

Why this answer

Trunk-based development with feature flags is the correct approach because it encourages developers to merge small, frequent changes into the main branch, reducing the surface area for conflicts. Feature flags allow incomplete features to be hidden in production, enabling continuous integration without requiring long-lived feature branches. This strategy directly addresses the problem of frequent merge conflicts by minimizing divergence between branches.

Exam trap

The trap here is that candidates often choose GitFlow (Option D) because it is a well-known structured model, but they fail to recognize that its long-lived feature branches directly cause the merge conflicts described in the scenario.

How to eliminate wrong answers

Option A is wrong because using release branches with cherry-picking from main does not reduce merge conflicts; it introduces additional complexity and potential for missed commits, and it does not address the root cause of developers working on the same files simultaneously. Option C is wrong because requiring all changes to be committed directly to a single main branch without any branching strategy or feature flags would lead to even more conflicts and instability, as developers would be forced to coordinate manually without isolation. Option D is wrong because GitFlow with separate develop and release branches encourages long-lived feature branches, which exacerbates merge conflicts when multiple developers work on the same files; it is designed for scheduled releases, not for reducing conflict frequency.

Practice this question →

57

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

A Git submodule references a specific commit from the shared repository, allowing the parent repository to track that exact version without copying the code; this keeps a single canonical source, enables atomic checkout, and lets you update the shared code deliberately by moving the submodule pointer—making it the correct choice for sharing source across multiple Git repos.

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 →

58

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

Configuring a branch policy to require linked work items is the native, server-enforced solution: when a pull request is created, the policy checks that at least one work item is linked, and the merge is blocked until that requirement is satisfied. This directly ensures every commit merged into the branch is traceable to a work item, and it is the only option that is both enforced and work-item-specific.

Why this answer

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 →

59

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

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 →

60

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

Pre-commit hooks run locally before a commit is finalized, allowing tools like detect-secrets to scan staged files and reject the commit if a potential secret is found. This shifts security left, stopping credentials from ever entering the Git history, which is a proactive measure because it prevents secret exposure before the commit is created.

Why this answer

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 →

61

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

A detailed pull request description provides structured context—such as motivation, scope, and testing—that Copilot uses alongside the diff to generate summaries; richer, clearer input directly improves the relevance and factual accuracy of the AI-generated output.

Why this answer

Providing a detailed pull request description gives GitHub Copilot more context and structured input, which directly improves the accuracy of AI-generated summaries. Copilot's PR summary feature relies on the diff and any existing description to infer intent; a richer description reduces ambiguity and enhances the quality of the generated output.

Exam trap

The trap here is that candidates may confuse reactive fixes (editing after generation) with proactive improvements (providing better input), leading them to choose option C instead of recognizing that the quality of AI-generated output is fundamentally driven by the quality of the input context.

How to eliminate wrong answers

Option A is wrong because disabling Copilot for pull requests eliminates the feature entirely rather than improving its accuracy, and it does not address the root cause of inaccurate summaries. Option C is wrong because editing the description after generation only fixes the current inaccuracy but does not improve the quality of future summaries, as Copilot does not learn from post-generation edits. Option D is wrong because ignoring the inaccuracy fails to provide any corrective feedback or additional context, leaving the underlying issue unresolved and likely to recur.

Practice this question →

62

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

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 →

63

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 explicitly uses feature branches cut from a development branch and merges them with `--no-ff` (no fast-forward) merge commits to preserve the feature branch context. This produces a non-linear history with multiple merge points and a visible branch structure, precisely matching the exhibit. That characteristic merge-commit topology is the definitive signature of Git Flow.

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 →

64

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 official Git tool for history rewriting; it removes the file from every commit in the repository, thereby eliminating the sensitive data from all historical versions. It rewrites commit hashes and requires force-pushing to update remote references, but it is the recommended and safest approach for this task.

Why this answer

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

65

MCQeasy

Your team uses GitHub Flow and wants to ensure that every pull request is reviewed by at least one team member. Which branch protection rule should you enable?

A.Require a pull request before merging and set required number of reviewers to 1

B.Require signed commits

C.Require status checks to pass before merging

D.Require conversation resolution before merging

AnswerA

Requiring a pull request before merging and setting the required number of reviewers to 1 ensures every change is proposed via a PR and must receive at least one human approval before merge. This directly enforces the code review requirement by blocking merges until a reviewer explicitly approves the pull request.

Why this answer

GitHub Flow relies on pull requests for collaboration, and the 'Require a pull request before merging' rule with a required number of reviewers set to 1 enforces that every PR must be reviewed by at least one team member before it can be merged. This directly satisfies the requirement of ensuring code review for all changes.

Exam trap

The trap here is that candidates may confuse 'requiring status checks' (automated validation) with 'requiring pull request reviews' (human validation), leading them to select option C instead of A.

How to eliminate wrong answers

Option B is wrong because requiring signed commits ensures commit authenticity and integrity via GPG or S/MIME signatures, but it does not enforce any review process. Option C is wrong because requiring status checks to pass before merging ensures that CI/CD checks (e.g., tests, builds) succeed, but it does not mandate human review. Option D is wrong because requiring conversation resolution before merging ensures that all comments on a PR are marked as resolved, but it does not guarantee that a specific number of reviewers have approved the changes.

Practice this question →

66

MCQmedium

Your team uses GitHub for source control and wants to enforce that all pull requests into the main branch require at least two reviewers and must pass a status check from a CI pipeline. Which branch protection rule configurations should you apply?

A.Require a minimum of 2 reviewers, require status checks to pass before merging

B.Require signed commits and status checks

C.Require status checks to pass, but do not require reviewers

D.Require a minimum of 2 reviewers, but do not require status checks

AnswerA

This branch protection configuration enforces both mandatory peer review and automated quality gates: at least two reviewers must approve the pull request, and all required status checks (e.g., CI build and test jobs) must pass before merging. This is the correct combination to meet the stated requirements.

Why this answer

GitHub branch protection rules allow you to require a minimum number of reviewers before merging and to require status checks to pass. By setting 'Require a minimum number of reviewers' to 2 and enabling 'Require status checks to pass before merging', you enforce that every pull request into the main branch must be approved by at least two reviewers and must pass the CI pipeline status check, meeting the stated requirements.

Exam trap

The trap here is that candidates may think requiring signed commits or only status checks is sufficient, but the question explicitly demands both two reviewers and a CI status check, which only option A satisfies.

How to eliminate wrong answers

Option B is wrong because requiring signed commits ensures commit authenticity but does not enforce the required two reviewers or the CI status check. Option C is wrong because it omits the requirement for at least two reviewers, which is explicitly needed. Option D is wrong because it omits the requirement for status checks to pass, leaving the CI pipeline result unenforced.

Practice this question →

67

MCQhard

You are designing a Git branching strategy for a large enterprise with multiple Azure DevOps projects. The strategy must support hotfixes for production releases, feature development in isolated branches, and release branches for stabilization. The team uses CI/CD pipelines that trigger on branch creation. You need to minimize merge conflicts and ensure that hotfix changes are propagated to all active branches. Which branching model should you recommend and how should you configure branch policies?

A.Use GitHub Flow with feature branches merging directly to main. Use a release branch for stabilization. Use pull requests for all merges.

B.Use trunk-based development with short-lived feature branches. Use feature toggles for incomplete work. No separate hotfix branch.

C.Use a forking workflow where each developer forks the repository and submits pull requests. Use branch policies on the upstream main branch.

D.Use GitFlow with main, develop, and hotfix branches. Configure branch policies on main and develop to enforce pull requests with required reviewers. Use a pipeline to automatically merge hotfix branches into both main and develop.

AnswerD

GitFlow supports hotfix propagation; policies enforce quality.

Why this answer

(GitFlow) is the correct recommendation because it provides dedicated hotfix branches that can be merged into both main and develop, ensuring hotfix changes are propagated to all active branches. GitFlow also supports feature branches, release branches for stabilization, and minimizes merge conflicts by isolating work. Branch policies on main and develop enforce pull requests with required reviewers, and a pipeline can automate merging hotfixes into both branches.

Option A (GitHub Flow) lacks dedicated hotfix branches and release branches, making hotfix propagation difficult. Option B (trunk-based) relies on feature toggles and does not isolate hotfixes, increasing risk. Option C (forking) is designed for external contributions, not internal enterprise collaboration, and does not inherently handle hotfix propagation.

Practice this question →

68

MCQmedium

Your organization uses GitHub Enterprise and wants to prevent secrets (e.g., API keys) from being pushed to any repository. Which GitHub feature should you enable?

A.Repository rulesets

B.GitHub Advanced Security secret scanning

C.Push protection for secret scanning

D.Branch protection rules requiring signed commits

AnswerC

Push protection prevents commits with secrets from being pushed.

Why this answer

Push protection for secret scanning (Option C) is the correct answer because it actively blocks pushes that contain known secrets (e.g., API keys, tokens) at the client side, preventing them from ever reaching the remote repository. This is a dedicated feature of GitHub Advanced Security that integrates with pre-receive hooks to scan commits in real time, rejecting the push if a secret pattern is detected. It is specifically designed to prevent secrets from being pushed, unlike passive scanning which only alerts after the fact.

Exam trap

The trap here is that candidates confuse 'secret scanning' (passive detection) with 'push protection' (active prevention), assuming that enabling GitHub Advanced Security secret scanning alone will block pushes, when in fact push protection is a separate toggle that must be explicitly enabled.

How to eliminate wrong answers

Option A is wrong because repository rulesets are used to enforce branch policies (e.g., required status checks, merge restrictions) but do not scan or block secrets in commits. Option B is wrong because GitHub Advanced Security secret scanning alone only detects secrets after they have been pushed (via alerts or pull request comments) and does not prevent the push from succeeding. Option D is wrong because branch protection rules requiring signed commits enforce commit integrity via GPG or S/MIME signatures but have no mechanism to inspect commit content for secrets.

Practice this question →

69

MCQeasy

You are setting up a new GitHub repository for a project that requires strict access control. Only specific team members should be able to push to the main branch, but all team members should be able to create branches and open pull requests. What is the best way to achieve this?

A.Add all team members as administrators of the repository.

B.Remove write permissions for non-core team members and give them read-only access.

C.Use a branch protection rule to restrict pushes to the main branch to specific users or teams.

D.Set the repository to private and invite only core team members.

AnswerC

A branch protection rule on the main branch can restrict direct pushes to specific users or teams, while still allowing branch creation and pull requests. This ensures that only authorized personnel can push to main, and all other changes must go through PR reviews, which directly addresses your requirement.

Why this answer

Branch protection rules in GitHub allow you to enforce restrictions on specific branches, such as requiring pull request reviews or restricting who can push directly. By configuring a rule for the main branch that limits push access to only designated users or teams, you ensure that all team members can create branches and open PRs, but only authorized members can merge into main. This directly meets the requirement without over-provisioning permissions or blocking collaboration.

Exam trap

The trap here is that candidates often confuse restricting push access with removing write permissions entirely, not realizing that branch protection rules allow granular control over specific branches while preserving write-level collaboration on other branches.

How to eliminate wrong answers

Option A is wrong because adding all team members as administrators grants them full control over the repository, including the ability to bypass any restrictions and push directly to main, which violates the strict access control requirement. Option B is wrong because removing write permissions for non-core members and giving them read-only access prevents them from creating branches or opening pull requests, which contradicts the requirement that all team members should be able to do so. Option D is wrong because setting the repository to private and inviting only core team members excludes non-core members entirely, preventing them from creating branches or opening pull requests, which is not the desired outcome.

Practice this question →

70

MCQhard

You are designing a source control strategy for a team that uses GitHub Copilot. The team wants to ensure that code suggestions do not include sensitive data. Which approach should you recommend?

A.Use pre-commit hooks to scan for secrets

B.Disable GitHub Copilot for the organization

C.Enable secret scanning for the repository

D.Configure content exclusions in GitHub Copilot settings to block sensitive data patterns

AnswerD

Prevents suggestions with secrets.

Why this answer

GitHub Copilot's content exclusions allow you to define patterns (e.g., regex for API keys, tokens, or PII) that Copilot will block from being used as context for code suggestions. This directly prevents sensitive data from appearing in suggestions without disabling the tool entirely. It is the most targeted and least disruptive approach to meet the team's goal.

Exam trap

The trap here is confusing reactive scanning (secret scanning or pre-commit hooks) with proactive prevention (content exclusions), leading candidates to choose a post-commit detection method instead of a real-time suggestion filter.

How to eliminate wrong answers

Option A is wrong because pre-commit hooks scan code after it is staged, not during the suggestion phase; they cannot prevent Copilot from generating suggestions containing sensitive data in real time. Option B is wrong because disabling Copilot for the organization is an overreaction that eliminates all productivity benefits, whereas the team only needs to block sensitive data patterns. Option C is wrong because secret scanning detects secrets already committed to the repository (post-commit), not during the suggestion phase; it does not prevent Copilot from suggesting sensitive data.

Practice this question →

71

MCQhard

You see the above git log output. The team has a policy requiring linear history on the main branch. Which command should be used next time to integrate the feature branch?

A.git merge --squash feature/login

B.git cherry-pick f4e5d6c a7b8c9d

C.git merge --no-ff feature/login

D.git rebase main feature/login then git merge --ff-only

AnswerD

Rebase creates linear history; fast-forward merge preserves it.

Why this answer

The team requires a linear history on the main branch. By first rebasing the feature branch onto main (`git rebase main feature/login`), you reapply the feature commits on top of the latest main commit, creating a clean, linear sequence. Then `git merge --ff-only` performs a fast-forward merge, which simply moves the main branch pointer forward without creating a merge commit, preserving the linear history policy.

Exam trap

The trap here is that candidates often confuse `--no-ff` (which preserves history but creates a merge commit) with the requirement for linear history, or they incorrectly think `git cherry-pick` is a valid way to integrate an entire feature branch.

How to eliminate wrong answers

Option A is wrong because `git merge --squash` collapses all feature commits into a single commit, which violates the requirement to integrate the feature branch while preserving its individual commits (the log shows multiple commits). Option B is wrong because `git cherry-pick f4e5d6c a7b8c9d` only applies two specific commits, not the entire feature branch, and it does not integrate the branch in a way that maintains a clean linear history. Option C is wrong because `git merge --no-ff` forces a merge commit even when a fast-forward is possible, which creates a non-linear history (a merge bubble) that violates the linear history policy.

Practice this question →

72

MCQhard

Your organization uses Azure DevOps for a large-scale e-commerce platform. The source code is stored in a single Azure Repos Git repository with over 100 contributors. The current branching strategy is a modified GitFlow with main, develop, release, and hotfix branches. However, the team is experiencing frequent merge conflicts and long integration periods. You have been asked to redesign the branching strategy to support continuous integration and deployment (CI/CD) while ensuring high-quality releases. The new strategy must reduce merge conflicts, enable fast feedback, and support hotfixes. The team uses feature flags to manage incomplete features. Which branching strategy should you recommend?

A.Implement trunk-based development: developers work on short-lived feature branches (less than a day) and merge to main multiple times a day. Use feature flags to control release of incomplete features. Hotfixes are created from main and merged back quickly.

B.Use a single main branch and allow developers to commit directly to main, but require all commits to be small and pass CI. Hotfixes are committed directly to main.

C.Use a single main branch and create release branches from main for each deployment. Feature branches are merged to release branches, and then release branches are merged to main after deployment.

D.Continue using GitFlow but enforce stricter branch policies and require more frequent merges.

AnswerA

Trunk-based development (TBD) with short-lived feature branches merged multiple times per day minimizes merge conflicts because branches diverge for hours, not weeks; feature flags decouple deployment from release, letting incomplete work ship safely behind toggles, and hotfix branches cut from main can be merged and deployed immediately, keeping main always in a releasable state and enabling continuous integration and continuous delivery.

Why this answer

Trunk-based development with short-lived feature branches (less than a day) and frequent merging to main directly addresses the team's merge conflicts and long integration periods. Feature flags allow incomplete features to be merged safely, enabling continuous integration and fast feedback. Hotfixes from main are simple and quick.

Option B is wrong because committing directly to main without branches increases risk of breaking the main branch, even with CI, and does not provide isolation for work-in-progress. Option C is wrong because using release branches introduces long-lived branches and delays integration, contrary to the need for fast feedback and continuous deployment. Option D is wrong because GitFlow's long-lived feature and release branches are the root cause of the frequent merge conflicts and integration delays.

Practice this question →

73

MCQhard

Your team uses Azure Repos and wants to enforce that all commits to the release branch must be signed using GPG. Which branch policy should you enable?

A.Limit merge types

B.Check for linked work items

C.Require a minimum number of reviewers

D.Require signed commits

AnswerD

Requiring signed commits is the policy that enforces each commit to be cryptographically signed with GPG or S/MIME, thereby verifying the identity of the committer and ensuring the commit content has not been tampered with. This directly fulfills the goal of enforcing that all commits are signed.

Why this answer

Azure Repos branch policies include a 'Require signed commits' setting that enforces GPG signature verification on all commits pushed to the branch. When enabled, any commit without a valid GPG signature is rejected, ensuring the integrity and authenticity of the commit author.

Exam trap

The trap here is that candidates may confuse 'Require signed commits' with other authentication or authorization policies, such as requiring reviewers or limiting merge types, because all are listed under branch policy settings but serve entirely different security purposes.

How to eliminate wrong answers

Option A is wrong because 'Limit merge types' controls the merge strategies (e.g., squash, rebase, or no-fast-forward) allowed on the branch, not commit signing. Option B is wrong because 'Check for linked work items' enforces that pull requests reference Azure Boards work items, which is unrelated to cryptographic commit signing. Option C is wrong because 'Require a minimum number of reviewers' mandates a certain count of reviewers approve a pull request before merging, but does not enforce that individual commits are signed with GPG.

Practice this question →

74

MCQhard

You are designing a branching strategy for a microservices application with independent deployment cadences. The team wants to support continuous deployment to production from the main branch while allowing feature work to be isolated and tested. Which branching strategy best meets these requirements?

A.One branch per environment (dev, test, prod)

B.GitHub Flow with feature branches merging to main

C.Trunk-based development with short-lived feature branches

D.Git Flow with develop, release, and hotfix branches

AnswerC

Trunk-based development with short-lived feature branches (typically less than a day) ensures that all developers integrate into main frequently, which minimizes merge conflicts, enables continuous integration, and supports rapid, automated deployment of microservices while still isolating work in progress via feature branches that are merged and deleted quickly.

Why this answer

Trunk-based development with short-lived feature branches (C) is correct because it enables continuous deployment from the main branch while isolating feature work in branches that are merged back to main within hours or a day. This approach minimizes merge conflicts and supports independent deployment cadences for microservices, as each service can be deployed from main independently without waiting for release branches.

Exam trap

The trap here is that candidates confuse GitHub Flow with trunk-based development, but GitHub Flow lacks the strict short-lived branch discipline and feature toggle support required for true continuous deployment from main in a microservices context.

How to eliminate wrong answers

Option A is wrong because one branch per environment (dev, test, prod) creates long-lived branches that diverge over time, leading to merge hell and preventing continuous deployment from a single source of truth. Option B is wrong because GitHub Flow with feature branches merging to main does not inherently support independent deployment cadences for microservices; it assumes a single deployment pipeline and can cause blocking if multiple features are merged before validation. Option D is wrong because Git Flow with develop, release, and hotfix branches introduces long-lived branches and release cycles that conflict with continuous deployment to production from main, as releases are staged through develop and release branches rather than directly from main.

Practice this question →

75

MCQeasy

Your team is migrating from TFVC to Git in Azure Repos. You need to preserve the full history of the TFVC repository, including all branches and changesets. The TFVC repository is large (over 10 GB). Which tool should you use to perform the migration?

A.Manually recreate the commits in a new Git repository.

B.Use git-tfs to clone the TFVC repository and then push to Azure Repos.

C.Use git-svn to convert TFVC to Git.

D.Use the Azure DevOps Migration Tools to export TFVC to Git.

AnswerB

git-tfs is a specialized bridge that clones a TFVC repository into a local Git repository while preserving the full history of changesets, branches, and merges. It is designed for large TFVC repos, and after cloning, you can push the Git repository to Azure Repos, making it the correct migration path.

Why this answer

B is correct because git-tfs is specifically designed to bridge TFVC and Git, allowing you to clone a TFVC repository (including all branches, changesets, and history) into a local Git repository, which can then be pushed to Azure Repos. It handles large repositories (over 10 GB) by performing an incremental clone, preserving the full history without manual recreation.

Exam trap

The trap here is that candidates confuse git-tfs with git-svn, assuming any 'git-*' tool works for any version control system, but git-svn only works with Subversion, not TFVC.

How to eliminate wrong answers

Option A is wrong because manually recreating commits in a new Git repository would lose the full history, branches, and changesets, which contradicts the requirement to preserve them. Option C is wrong because git-svn is designed for Subversion (SVN) repositories, not TFVC; it cannot interpret TFVC's changeset structure or branching model. Option D is wrong because the Azure DevOps Migration Tools are primarily for migrating work items, test plans, and other Azure DevOps artifacts between organizations, not for converting TFVC repositories to Git with full history.

Practice this question →

Page 1 of 2 · 83 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Source Control Strategy questions.

Start 20-question session