Design and implement source control practice questions

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.

Configure a minimum number of reviewers policy

Why wrong: This enforces review count, not work item linking.

Use a build validation policy to check commit messages

Why wrong: Build validation runs a pipeline but does not enforce work item linking directly.

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

Why wrong: Labels do not enforce updates to README.

Add a task in the CI pipeline that checks if the README was modified

Why wrong: The pipeline can check but cannot prevent merging; it can only fail the build.

Require a pull request comment that confirms README update

Why wrong: Comments are not enforceable automatically.

Set branch policies on the main branch to prevent forks

Why wrong: Branch policies do not control fork creation.

Configure the repository to disable forks globally

Why wrong: Disabling forks is all or nothing; cannot restrict to specific users.

Remove the 'Create Fork' permission from all users except the required group

Why wrong: There is no explicit 'Create Fork' permission in Azure Repos.

Rebase and fast-forward

Why wrong: Rebases commits onto target but keeps individual commits.

Merge commit (no fast-forward)

Why wrong: Preserves all commits in a merge commit.

Semi-linear merge

Why wrong: Rebases then creates a merge commit; commits are not squashed.

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

Why wrong: Does not enforce two reviewers.

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

Why wrong: Resetting votes doesn't allow single reviewer.

Configure a build validation policy that checks number of approvals

Why wrong: Build validation cannot enforce approvals.

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 does not remove the password from previous commits.

Revert the commit that introduced the password

Why wrong: Reverting adds a new commit but the password remains in history.

Immediately notify the security team and rotate the password

Why wrong: Important but not the first step to remove the secret from source control.

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

Why wrong: Loses all history.

Use the Git-TF tool to clone the TFVC repository

Why wrong: Git-TF is deprecated; git-tfs is recommended.

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

Why wrong: Bundles are for Git-to-Git, not TFVC.

Comment requirements

Why wrong: Enforces commit message formats, not code quality.

Work item linking

Why wrong: Enforces linking to work items, not code quality.

Merge strategy

Why wrong: Controls how merges are performed, not quality.

Reduced risk of configuration drift

Why wrong: Multiple repos can also have configuration management; monorepo doesn't inherently reduce drift.

Faster clone times due to smaller repository size

Why wrong: Monorepos are typically larger, leading to slower clones.

Fast-forward only

Why wrong: Not available as a PR merge option in Azure Repos.

Squash merge

Why wrong: Called 'Squash commit' in Azure Repos.

Rebase only

Why wrong: Not a PR merge strategy; rebase is done manually.

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

Why wrong: Similar to A, doesn't solve coordination overhead.

Keep separate repositories but use Git submodules to share code

Why wrong: Submodules introduce complexity and still require multiple pull requests for cross-repo changes.

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

Why wrong: Increases build times and reduces independence.

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

Why wrong: Can work but requires a build agent; status check is simpler.

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

Why wrong: Azure Repos does not support server-side hooks.

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

Why wrong: Not enforceable; developers can bypass.

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

Why wrong: This does not enforce review.

Configure a branch policy that requires a successful build.

Why wrong: This validates build quality but not code review.

Configure a branch policy that requires linked work items.

Why wrong: This ensures traceability but not review.

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

Why wrong: This loses all history.

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

Why wrong: Import repository feature imports from Git, not TFVC.

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

Why wrong: Git does not natively clone TFVC history.

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

Why wrong: SSH is for authentication, not signing.

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

Why wrong: PAT is for authentication, not signing.

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

Why wrong: Azure Repos does not automatically sign commits with Key Vault keys.

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

Why wrong: Manual triggers defeat automation and are error-prone.

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

Why wrong: This increases complexity and maintenance.

Configure the build policy in Azure Repos with a path filter to limit which folders trigger the policy.

Why wrong: Path filters in build policies affect only the policy evaluation, not the build trigger.

Store large binary files directly in the repository.

Why wrong: Large binaries bloat the repo.

Keep all branches indefinitely to preserve history.

Why wrong: Unused branches increase clone overhead.

Encourage developers to commit all changes in a single commit per day.

Why wrong: Large commits make history hard to navigate.

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

Why wrong: 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 wrong: This compromises code quality on feature branches.

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

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

Use squash merge when completing pull requests to main.

Why wrong: Squash merge is optional; it simplifies history but is not required for build validation.

Create feature branches from main and keep them long-lived for stability.

Why wrong: Long-lived branches contradict the short-lived branch strategy.

Allow developers to commit directly to main for urgent fixes.

Why wrong: Direct commits bypass the pull request process and branch policy.