Design and implement source control practice questions

Automatically include work items in pull request descriptions

Why it fails: This is not a branch policy; it's a repository setting that auto-links work items based on commit messages.

Require a work item linking policy in branch policies

Why it fails: Require a work item linking policy in branch policies is a native Azure DevOps branch policy that blocks pull request completion until at least one work item is linked to the PR. This directly enforces traceability from code changes to backlog items, making it the correct mechanism for a monorepo where multiple projects share one repository.

Configure a minimum number of reviewers policy

Why it fails: Configuring a minimum number of reviewers policy only enforces that a specified number of people approve the pull request; it has no mechanism to validate or require linked work items. Thus, it can be used alongside a work item linking policy but does not by itself ensure any work item is associated with the change.

Apply a label to PRs that touch certain files and require review

Why it fails: Applying labels to PRs does not enforce README updates; it only adds a visual indicator and requires manual review, which can be overlooked.

Use a repository template with a mandatory README file structure

Why it fails: Using a repository template ensures a README exists at repository creation, but it does not guarantee updates after subsequent changes, so it fails to address the ongoing maintenance issue.

Require a pull request comment that confirms README update

Why it fails: Requiring a PR comment is a manual process that depends on developer honesty and can be easily forgotten or bypassed.

Use a shallow clone with depth 1

Why it fails: Shallow clone reduces commit history but still downloads LFS files for the single commit.

Use sparse checkout to limit files in working directory

Why it fails: Sparse checkout limits checked-out files but LFS is still downloaded for all files.

Configure git lfs prune to run automatically

Why it fails: Prune removes local LFS cache but does not affect clone time.

Configure a self-hosted agent with pre-installed dependencies and a larger disk for faster I/O.

Why it fails: Self-hosted agents require maintenance and may not solve the caching or analysis scope issues.

Remove the code analysis step from feature branch builds and only run it on main branch builds.

Why it fails: This compromises code quality on feature branches.

Increase the agent VM size to a more powerful SKU for feature branch builds.

Why it fails: This increases cost and may not address the root causes of cache misses and full code analysis.

Configure shallow clone (depth=1) for all operations and disable CI triggers on feature branches.

Why it fails: A shallow clone with depth=1 reduces commit history but still materializes the entire filesystem tree at the current commit, so every microservice agent downloads all files in the monorepo—the size problem remains. Disabling CI triggers on feature branches removes early validation and lets broken changes land on main before anyone notices, undermining the goal of per-service fast feedback. While path-based triggers could still work, shallow clone does not address the download bottleneck and depth=1 can break tooling that relies on history.

Break the monorepo into multiple smaller repositories and use Git submodules to manage dependencies.

Why it fails: Splitting the monorepo into multiple repositories and chaining them with submodules reverses the requirement to keep a monorepo, and introduces severe operational friction. Every cross-service change requires committing a new submodule pointer plus the parent reference, making atomic multi-service commits impossible and forcing fragile synchronization between repositories. Sparse checkout solves the same size problem without dismantling the monorepo, which is exactly why the other options are unnecessary and wrong.

Implement Git Virtual File System (GVFS) for the repository and use CI triggers only on the main branch.

Why it fails: GVFS (Git Virtual File System) is an older Microsoft tool that requires a virtual filesystem filter driver and is primarily supported on Windows; Azure Repos does not provide GVFS server support, so it cannot be used with a cloud-hosted Git repository. Even if it were available, restricting CI triggers to only the main branch removes all pre-integration feedback from feature branches, so broken code is only discovered after merging. The correct technique is to use sparse checkout plus path-based triggers, which works natively in Azure Pipelines without proprietary clients.

The developer tried to push to the wrong remote URL.

Why it fails: The exhibit does not indicate any URL mismatch; the error is likely due to policy.

The FabrikamWeb repository has a minimum number of reviewers policy set to 1, which blocks direct pushes.

Why it fails: The MinimumNumberOfReviewers policy is shown as enabled and blocking, but it applies to pull requests, not direct pushes. However, it could still block pushes if the policy is configured to require reviews on push, but typically such policies are for PRs.

The main branch does not exist in the FabrikamWeb repository.

Why it fails: The exhibit shows the repository has a default branch 'develop', but main may still exist. The error is not about missing branch.

git rebase --abort

Why it fails: There is no rebase in progress; this command would be invalid.

git merge main

Why it fails: While this would merge main again, it would create an extra merge commit. The developer already has a merge from main, but main has advanced. Rebasing is cleaner.

git push origin feature/login

Why it fails: Pushing will not incorporate the latest main changes; it will just push the current state.

The pipeline will trigger and run all steps because the branch name does not match any exclude pattern.

Why it fails: This is incorrect because the branch name starts with 'feature/', which directly matches the exclude pattern 'feature/*' defined in the pipeline trigger. As a result, the pipeline is explicitly prevented from triggering on this branch, regardless of any include patterns or step definitions. The exclude rule takes precedence and suppresses all pipeline runs for matching branches.

The pipeline will trigger only the restore and build steps, skipping tests.

Why it fails: This is incorrect because the pipeline is not triggered at all, so no steps, including restore, build, or test, will run. The exclude pattern 'feature/*' causes the pipeline to skip the entire execution for this branch, not just a subset of steps. The step visibility is irrelevant since the pipeline never starts.

The pipeline will trigger but fail with an error because the branch is not in the include list.

Why it fails: This is incorrect because the exclude rule takes precedence over include rules; the branch is explicitly excluded, so the pipeline will not trigger. There is no error or failure during execution because the pipeline is never initiated. The absence from an include list is irrelevant when an exclude pattern matches the branch name.

The pipeline agent pool is misconfigured.

Why it fails: A misconfigured agent pool would typically produce errors like 'No agent found in pool' or 'Agent Pool could not be found,' not a parallelism error. The error you see is strictly about the absence of parallel job capacity, which is independent of the agent pool's agent count, permissions, or target type.

The pipeline YAML file has a syntax error.

Why it fails: A YAML syntax error would be reported during pipeline validation as a parse error, with details like 'Failed to parse yaml' and a line/column reference. This error message instead indicates a resource capacity issue—parallelism—meaning the YAML was accepted and the failure occurred at the job scheduling stage, before any code execution.

The Azure subscription is not linked to the Azure DevOps organization.

Why it fails: If the Azure subscription were not linked to the Azure DevOps organization, you would see errors related to authentication, service connection failures, or 'The service principal does not have permission to access Microsoft Azure.' This parallelism error is unrelated to subscription linkage because parallel job capacity is a setting on the Azure DevOps organization itself, not on any Azure subscription, and applies across all pipelines regardless of their cloud connections.

Create a branch policy that requires a minimum number of reviewers on all branches.

Why it fails: A minimum reviewer policy increases review requirements but does not scan for or remove secrets. Reviewers might catch some secrets, but the policy provides no automated detection or history rewriting. It also does not prevent a determined developer from merging a secret after approvals, so it fails to satisfy either the removal or the prevention requirement.

Add the secret file paths to .gitignore and commit the change.

Why it fails: .gitignore only prevents untracked files from being added in future commits; it has no effect on files already committed or on historical commits. The secrets would remain in the repository history and could still be accessed. This action also does not block a developer from force-adding a secret file or committing secrets in other files.

Rotate the exposed secrets and add them as secret variables in an Azure Pipelines variable group.

Why it fails: Rotating secrets is a necessary security step, but storing them in a variable group does not remove them from Git history or prevent future commits from including secrets. The audit requirement is to purge history and stop new secret pushes; variable groups address pipeline secret management, not repository history hygiene.

Use branch security to restrict who can create forks

Why it fails: Branch security in Azure Repos controls what users can do with branches that already exist, such as Contribute, Edit Policies, Bypass Policies when completing pull requests, and Force Push. There is no 'Create Fork' permission within branch security settings, and those permissions are scoped to a branch rather than to the repository, so they cannot affect whether someone can create a full copy of the entire repository. Modifying branch security on main or any other branch will therefore not restrict fork creation.

Set branch policies on the main branch to prevent forks

Why it fails: Branch policies in Azure Repos are evaluation rules applied to pull requests and direct pushes—such as required reviewers, build validation, and work item linking—and are scoped to a specific branch like main. They do not include any permission that prevents a user from creating a fork, because fork creation is a repository-level security action independent of branch state. Even if you set all available policies on main, any user with the 'Create Fork' permission can still fork the repository without affecting the main branch.

Configure the repository to disable forks globally

Why it fails: Disabling forks globally would prevent everyone—including the group that should be allowed to create forks—from forking the repository, which does not satisfy the requirement. Azure DevOps does not expose a repository-level 'disable forks' toggle; the actual enforcement is done through the 'Create Fork' permission at the repository level. A global disable would block the required group too, and it also fails to map to a real configurable control in the forking workflow, unlike granular permission management.

Rebase and fast-forward

Why it fails: Rebase and fast-forward is incorrect because it rewrites the feature branch commits onto the tip of the target branch and then fast-forwards, resulting in a linear history that preserves each individual commit. Since all original commits remain intact, this approach does not combine changes into a single commit as required.

Merge commit (no fast-forward)

Why it fails: Merge commit (no fast-forward) is incorrect because it creates a new merge commit while preserving all the individual commits from both branches. This results in a non-linear history with the feature branch's commits intact, failing to consolidate them into a single commit.

Semi-linear merge

Why it fails: Semi-linear merge is incorrect because it first rebases the feature branch onto the target branch and then creates a merge commit, producing a linear history but keeping all original commits. Since the commits are not squashed, this approach does not meet the requirement to reduce the feature branch to a single commit.

Set minimum number of reviewers to 1 and require a separate approval from a manager

Why it fails: This setting requires one reviewer and a separate manager approval, but the manager approval is not a code review and does not count toward the two-reviewer requirement, so the change could still be merged with only a single reviewer providing code feedback.

Set minimum number of reviewers to 2 and allow resetting code review votes on new pushes

Why it fails: Requiring two reviewers and resetting votes on new pushes enforces that the two selected reviewers must re-approve the latest changes, but it does not reduce the required number of distinct reviewers to one; it only ensures approvals are valid against the updated code.

Configure a build validation policy that checks number of approvals

Why it fails: A build validation policy runs a build as a pre-merge check, but it cannot inspect or enforce human approval counts; it has no access to the review/vote data and cannot block a PR based on the number of reviewers.

Delete the file from the repository and commit the deletion

Why it fails: Deleting the file from the repository and committing the deletion only removes the file from the latest commit; the password remains in all earlier commits in Git history, so anyone with repository access can still retrieve it. Git history is immutable unless rewritten, making this approach ineffective for secret removal.

Remove the password from the file, amend the commit, and force push

Why it fails: Amending the commit rewrites the latest commit by replacing it with a new one that no longer contains the password, and force pushing updates the remote branch to discard the old commit. This effectively removes the sensitive data from the visible history, provided you act before the commit is widely shared and you coordinate with any collaborators who may have pulled it.

Revert the commit that introduced the password

Why it fails: Reverting the commit creates a new commit that reverses the changes, but the original commit remains intact in the repository's history, meaning the password is still accessible to anyone who clones or browses the history. The secret must be considered compromised, so this alone does not solve the problem.

Copy the latest version of the code to a new Git repository and start fresh

Why it fails: This approach creates a brand-new Git repository containing only the current workspace snapshot, so every TFVC changeset, label, branch, and historical audit record is permanently discarded. It also destroys the ability to trace code lineage, compare past versions, or understand why specific changes were made — a critical loss for compliance and debugging. Unlike a true migration that replays history, this is effectively a re-baseline, not a conversion, and would be unacceptable for any organization that requires an immutable audit trail or reproducible build provenance.

Use the Git-TF tool to clone the TFVC repository

Why it fails: Git-TF is a deprecated Microsoft tool that lacks the robust, actively maintained changeset conversion and branch/tag mapping provided by git-tfs, so using it would create an incomplete or brittle migration artifact with potential data loss.

Export TFVC as a Git bundle and import with --no-metadata

Why it fails: A Git bundle is a Git-specific archive format that TFVC cannot produce, and --no-metadata is not a conversion mechanism for TFVC history; this approach is technically invalid and would not bring any TFVC changesets into Git.

Comment requirements

Why it fails: Comment requirements are not a configurable branch policy in Azure Repos; they enforce that commit messages follow a specified regex pattern, not code quality or review processes. The existing note correctly identifies that this is about commit message formats, and since the question asks about branch policies that enforce quality, this option is incorrect.

Work item linking

Why it fails: Work item linking is a branch policy that requires at least one work item to be associated with the PR, but it does not enforce code quality. The existing note correctly points out that it enforces linking to work items, not code quality, making it an incorrect choice for a quality-based policy.

Merge strategy

Why it fails: Merge strategy is not a quality-gating branch policy; it controls how commits are merged into the target branch (e.g., squash, rebase, merge commit). The existing note correctly states that it controls how merges are performed, not quality, so it is not one of the correct answers.

Reduced risk of configuration drift

Why it fails: While a monorepo can centralize CI/CD configuration, it does not inherently prevent configuration drift since different projects may still need distinct tooling, versions, or pipeline definitions. Multiple repositories can also enforce configuration consistency through templates and policies, so this is not a guaranteed benefit of a monorepo.

Faster clone times due to smaller repository size

Why it fails: Monorepos are typically much larger than individual repositories because they contain the history and files of all projects, so cloning them generally takes longer, not faster. Even with sparse checkout or shallow clone techniques, the default full clone is slower, making this statement incorrect.

Fast-forward only

Why it fails: Fast-forward only is not exposed as a standalone completion strategy in Azure Repos pull requests. A pure fast-forward simply moves the target branch pointer to the source branch's latest commit, which is only possible when the source branch contains the target branch's history as a subset; otherwise, a merge or rebase step is required. Azure Repos instead offers 'Rebase and fast-forward' as an explicit strategy that first replays source commits onto the latest target before doing the fast-forward, and the semi-linear merge method rebases then creates a merge commit. Because a raw fast-forward option would silently skip an integration record and cannot be applied when branches diverge, it is not offered as a separate pull request completion choice in Azure Repos.

Rebase only

Why it fails: Rebase only is not a valid standalone merge strategy in Azure Repos; rebasing is performed as an internal step within the semi-linear merge strategy. Azure Repos does not offer a separate 'rebase only' completion option for pull requests, so this selection is incorrect.

Keep separate repositories but create a meta-repo that references them as submodules

Why it fails: A meta-repo that references service repositories as submodules does not enable atomic commits across services; each service remains a separate repository with its own history and pull request flow. Whenever a change spans multiple services, you must merge multiple pull requests and update submodule pointers, which can easily leave the meta-repo in a broken intermediate state. The extra layer of indirection adds overhead without resolving the fundamental coordination problem that a monorepo solves.

Keep separate repositories but use Git submodules to share code

Why it fails: Git submodules are designed for pinning a shared dependency to a specific commit, not for coordinating a codebase with multiple independently deployable services. Every shared code update requires a commit in the consuming service, plus a separate submodule pointer update; this creates multiple pull requests and makes atomic cross-service changes impossible. Submodules also complicate CI, as each consumer must check out and authenticate multiple repositories, and the classic "dirty pointer" problem makes branch switching and review unreliable.

Create a single monorepo with all services and a single build pipeline that builds everything

Why it fails: A single pipeline without path filters triggers a full build, test, and deployment sequence for every commit to any service, even when the change is isolated to one component. This couples the release cadence of all services, because a failing build in one service blocks the entire pipeline, and it wastes compute and time as the number of services grows. A change to a utility library would unnecessarily rebuild all services, defeating the independence that microservices are meant to provide.

Create a build pipeline that validates commit messages and fails the build if invalid

Why it fails: A build pipeline validates commit messages only after code is pushed, but the requirement demands validation *before* a merge occurs, meaning invalid commits could already exist in the pull request branch. This approach is tempting because it automates enforcement without additional tooling, and would be correct in a scenario where post-push validation is acceptable, such as a CI pipeline that blocks merging only after a failed build.

Use a server-side pre-receive hook in the Git repository

Why it fails: Azure DevOps Services Git hosting does not expose server-side pre-receive or update hooks; these hooks are only available on self-managed Git servers where you have direct filesystem access to the repository. Because Azure Repos is a managed cloud service, you cannot install or execute arbitrary scripts on the server as part of the push process. Therefore, this option is invalid for enforcing commit-message validation in Azure DevOps.

Install a client-side pre-commit hook on each developer's machine to validate messages

Why it fails: A client-side pre-commit hook runs only on a developer's local repository and can be trivially bypassed by using git commit --no-verify, so it cannot provide enforceable validation. Additionally, hooks are not propagated automatically through git clone; each developer must manually copy and maintain the hook script, which is error-prone and inconsistent across the team. Since the requirement mandates that invalid commit messages must be blocked before a merge, this decentralized approach cannot guarantee compliance and is therefore insufficient.