Design and implement source control practice questions

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: The exhibit shows the repository has a default branch 'develop', but main may still exist. The error is not about missing branch.

The pipeline agent pool is misconfigured.

Why wrong: 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 wrong: 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 wrong: 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.

Automatically include work items in pull request descriptions

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: Requiring a PR comment is a manual process that depends on developer honesty and can be easily forgotten or bypassed.

Use branch security to restrict who can create forks

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Use a shallow clone with depth 1

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

Use sparse checkout to limit files in working directory

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

Configure git lfs prune to run automatically

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

Delete the file from the repository and commit the deletion

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Configure a branch policy that requires commit messages to follow a specific pattern.

Why wrong: While enforcing a commit message pattern can improve commit history readability and traceability, it does not require any human peer review of the code changes. Automated checks on commit messages validate formatting but do not involve another developer evaluating the code content, so it does not satisfy the requirement for peer review.

Configure a branch policy that requires a successful build.

Why wrong: A successful build validates that the code compiles and passes automated tests, providing a quality gate but not human review. CI build results do not constitute peer review because no other developer manually inspects the changes for logic, design, or maintainability.

Configure a branch policy that requires linked work items.

Why wrong: Linking work items ensures traceability between code changes and backlog items, but it does not involve any code review process. A developer can link a work item and still push unreviewed code, so this policy does not enforce peer review.

Check out the latest version from TFVC, initialize a new Git repo, and push.

Why wrong: Checking out the latest version only captures a snapshot of the current code without any revision history. Initializing a new Git repository from that snapshot creates a single commit, losing all previous changesets, branches, and merge history, which defeats the purpose of a true migration.

Use the Azure Repos import repository feature to import from TFVC.

Why wrong: The Azure Repos 'Import repository' feature is designed to import from external Git repositories (e.g., GitHub, GitLab) by cloning an existing Git repo URL. It does not support TFVC as a source, so it cannot be used to migrate TFVC history directly.

Clone the TFVC repository using Git and push to Azure Repos.

Why wrong: The native Git client does not understand TFVC's server-based version control model; attempting to clone a TFVC repository using git commands will fail because TFVC is not a Git remote. Tools like git-tfs are required to translate TFVC's changesets into Git history.

Configure branch policy to require signed commits and have developers add their SSH public key to Azure Repos.

Why wrong: SSH public keys in Azure Repos are used for SSH authentication and identify the developer for git operations, but Azure Repos branch policies that require signed commits verify GPG or S/MIME signatures, not SSH keys. SSH keys do not provide the cryptographic commit signature that the policy checks for, so this configuration would not satisfy the requirement.

Configure repository settings to require a personal access token (PAT) for each commit.

Why wrong: A personal access token (PAT) is an authentication mechanism for Azure DevOps REST APIs and git HTTPS operations; it is not a signing key and cannot be used to create cryptographic commit signatures. Requiring a PAT for each commit only enforces authentication, not integrity or non-repudiation, and Azure Repos branch policies do not support PAT-based commit signing validation.

Use Azure Key Vault to store signing keys and configure Azure Repos to automatically sign commits.

Why wrong: Azure Key Vault can store signing keys, but Azure Repos does not provide any automatic commit-signing service that would use those keys to sign commits on a developer's behalf. Commit signing must happen locally in the Git client using a private key accessible to the developer; the branch policy can only verify signatures after they are pushed, it cannot generate signatures server-side.

Use a manual trigger and have developers specify which folder to build.

Why wrong: Using a manual trigger defeats the purpose of an automated build validation policy. It requires manual intervention and does not automatically trigger based on code changes. This is not efficient for continuous integration.

Create separate YAML pipelines for each folder and configure branch policies to require all pipelines.

Why wrong: Creating separate YAML pipelines for each folder increases complexity and maintenance overhead. Branch policies would then need to require all pipelines, which could lead to unnecessary builds and doesn't leverage path filtering to reduce build times effectively.

Configure path filters in the pipeline trigger to include only the changed folder.

Why wrong: Configuring path filters in the pipeline trigger using the `paths` keyword in the YAML pipeline file is the recommended approach. It allows you to specify include and exclude patterns so that the pipeline only triggers when changes are made to the specified folders, directly reducing unnecessary builds for any trigger type (push, PR, etc.).