Design and implement a source control strategy practice questions

A push to an existing branch.

Why it fails: For an existing branch push, both 'before' and 'after' are non-zero commit hashes because the ref already exists and is updated from a previous commit to a new commit, so an all-zero 'before' is not present.

A branch deletion.

Why it fails: A branch deletion is the opposite pattern: 'after' is all zeros because the ref is removed, while 'before' holds the last commit hash of the deleted branch, so it does not match the all-zero 'before' condition.

A pull request update.

Why it fails: Pull request updates are delivered as a separate webhook event type with a different payload structure (pullRequest and resource objects), not the push event's before/after ref fields, so they cannot indicate a new branch creation.

git merge --squash feature/login

Why it fails: Squash merge creates a single commit but still a merge commit.

git cherry-pick f4e5d6c a7b8c9d

Why it fails: Cherry-pick is for individual commits, not the whole branch.

git merge --no-ff feature/login

Why it fails: Creates a merge commit, breaking linear history.

Pass secrets as environment variables to actions.

Why it fails: GitHub Actions automatically injects secrets as environment variables only when you reference them via `${{ secrets.NAME }}` in the `env:` block; manually assigning a secret to an env var makes it visible to every step in the job, and any step can print it to the logs with `echo` or a malicious action. Plain env vars are not automatically redacted by GitHub, so values can leak in debug logs or custom output. The best practice is to reference secrets directly in the `env:` mapping using the secrets context, which triggers masking for the exact value and keeps the secret out of the workflow file.

Use environment secrets to restrict access to specific workflows.

Why it fails: GitHub Environments provide isolated secret stores tied to a deployable environment (e.g., production); a job can only access those secrets if it explicitly declares `environment: production`. You can attach protection rules like required reviewers or a custom deployment branch, so a workflow triggered from a non-approved branch or pull request cannot use production secrets. This granular scoping contains the impact of a compromised workflow because secrets for other environments remain inaccessible, and rotating one environment's secret does not affect others.

Store the same secret in multiple repositories for consistency.

Why it fails: Duplicating a secret across multiple repositories contradicts the principle of least privilege and creates credential sprawl: a leak in any one repository invalidates the same credential everywhere, and rotation requires finding every copy. Instead, use an organization-level secret and enable repository selection to share a single encrypted value with chosen repos, or centralize with an external vault through OIDC so workflows fetch ephemeral credentials. Manual duplication also obscures access history, making it impossible to audit which repo actually used the secret.

on: release: types: [published]

Why it fails: The `release` event with `types: [published]` triggers only when a GitHub Release is published, not when a tag is pushed. Since your goal is to automate on tag creation, this workflow would not run from a simple `git push --tags` unless a release is also manually published.

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

Why it fails: The `push` event with `branches: ['v*']` filters branch names, not tag names; GitHub Actions does not apply the `branches` filter to tags. To trigger on tag creation, you must use `tags` on the `push` event or use the `create` event as shown.

on: workflow_dispatch: inputs: tag

Why it fails: The `workflow_dispatch` event enables a manual trigger via the GitHub UI or API, requiring a user to select the `tag` input each time. It does not automatically respond to tag creation, so it cannot fulfill the requirement for automated workflow execution on tag pushes.

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

Why it fails: A GitHub Actions workflow triggered by a push event runs only after the commit has already been accepted onto the branch, so it cannot prevent unsigned commits from entering; it can only report or flag them post-hoc, which fails to enforce a pre-push policy.

Use a commit status check to verify signatures

Why it fails: Commit status checks are attached to commits after they are pushed and are primarily used for CI results; they do not execute before the push is received by GitHub, so they cannot block an unsigned commit from being added to a branch.

Require a minimum number of reviewers

Why it fails: This applies to the entire branch, not specific paths.

Automatically include code reviewers

Why it fails: This adds reviewers but does not enforce mandatory approval.

Use separate repositories for each team

Why it fails: The requirement is to use a monorepo, not separate repos.

Repository rulesets

Why it fails: Rulesets can enforce various policies, but push protection is the specific feature for secrets.

GitHub Advanced Security secret scanning

Why it fails: Secret scanning detects secrets after they are committed, but does not block pushes.

Branch protection rules requiring signed commits

Why it fails: Signed commits verify identity but do not block secrets.

Repository rulesets

Why it fails: Repository rulesets in GitHub are a newer, flexible policy layer that can target branches, tags, or entire repositories, and they can enforce required status checks, merge restrictions, and even path-based requirements. However, for the precise scenario of blocking direct pushes to a specific branch while still allowing pull request merges, branch protection rules are the more targeted, conventional mechanism. Rulesets are broader in scope and introduce precedence semantics when combined with branch protection rules, making them less clear-cut for this simple branch-guard need.

CODEOWNERS file

Why it fails: CODEOWNERS only automatically assigns review requests to designated users or teams when a PR modifies matching files. It does not enforce any push restrictions or prevent contributors from pushing directly; it is purely a review-assignment mechanism, not an access control or branch policy.

GitHub Actions

Why it fails: GitHub Actions is a CI/CD and workflow automation system used to build, test, and deploy code, often triggered by pushes or pull requests. It cannot restrict direct pushes by itself; branch protection rules (or repository rulesets) are the mechanisms that enforce push permissions and required reviews.

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

Why it fails: Migrating to TFVC would not reduce build times because the compiler still processes the full solution; it only changes the source control protocol used to fetch and commit files. Centralized version control requires developers to be continuously connected and often uses exclusive locks for binary files, making parallel branch work and offline development significantly harder for a global team. TFVC also scales poorly for large numbers of concurrent users and lacks the distributed collaboration features that Git-based Azure Repos provides.

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

Why it fails: Path filters only gate which jobs or triggers execute; they do not reduce the actual compilation, testing, or packaging work for components that must be rebuilt because of shared dependencies. In a monorepo, a change to a common library still cascades to many downstream builds, and each pipeline run must check out and evaluate the entire repository. This approach adds YAML condition complexity without delivering the build isolation that independent repositories provide.

Keep the monorepo and disable continuous integration builds to reduce load

Why it fails: Disabling continuous integration does not make the build pipeline faster; the same compile, test, and package steps still execute whenever a developer manually triggers a build. It simply removes the automated feedback loop, so integration errors surface later and developers must wait for a manual queue instead of getting immediate results. Agent load may drop between manual runs, but build duration itself is not improved and the original bottleneck remains.

Configure the repository to use rebase when pulling

Why it fails: This is a Git client configuration option (`git config pull.rebase true`) that affects only a developer's local `git pull` behavior by replaying local commits on top of fetched commits. It does not alter any server-side PR completion policy or how Azure Repos integrates the source branch into a pull request. Even if every developer pulled with rebase, the PR completion merge strategy remains whatever the repository policy specifies, so the shared commit history is unchanged. Therefore, this setting has no effect on messy or low-quality PR commit messages.

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

Why it fails: Requiring a clean fast-forward merge through branch policy means the target branch ref is simply advanced to the source branch's final commit, with no merge commit being created. This enforces that the source branch is up to date with the target, but it does not rewrite, combine, or clean any of the commits coming in. Every original commit, with its original message, is preserved exactly in the target's history, so poor message quality remains fully intact. It is a topology constraint, not a history-quality tool, and therefore does not address the team's concern.

Use rebase merge when completing pull requests

Why it fails: Selecting 'Rebase merge' when completing a PR makes Azure Repos replay each source-branch commit onto the tip of the target branch, producing a linear history without an explicit merge commit. However, this strategy preserves all individual commits and their original messages, so WIP commits, fixups, and poorly worded messages survive unchanged. It aggregates nothing and edits nothing, which means the history may be linear yet still full of meaningless or repetitive entries. This is why rebase merge does not solve the problem of poor commit message quality.

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

Why it fails: The script can be bypassed if the build is skipped.

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

Why it fails: Client-side hooks can be disabled by developers.

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

Why it fails: Automatically adding IDs doesn't enforce that developers include them.

Manually recreate each repository in GitHub and copy the code from Azure Repos

Why it fails: Manually recreating repositories is error-prone and does not preserve commit history or policies efficiently.

Use a third-party tool to perform a mirror clone and then push to GitHub

Why it fails: A mirror clone copies commits and refs, but GitHub branch protection rules and required status checks are not Git objects, so they cannot be transferred this way; they must be recreated in GitHub. Mirroring suits preserving full history when policies need not survive, not this scenario.

Use the GitHub Importer tool with a custom mapping script to migrate repositories and policies

Why it fails: The GitHub Importer tool migrates repository history and code but does NOT preserve branch policies, so it fails to meet the requirement of preserving policies.

Use pre-commit hooks to scan for secrets

Why it fails: Client-side, not integrated with Copilot.

Disable GitHub Copilot for the organization

Why it fails: Overly restrictive.

Enable secret scanning for the repository

Why it fails: Detects after commit.

Auto-merge feature

Why it fails: Auto-merge is a GitHub feature that automatically merges a pull request when all required checks pass and approvals are satisfied; it does not inspect or delete branches, so it cannot address stale branches older than 90 days.

Stale bot (GitHub Actions)

Why it fails: Stale bot (e.g., `actions/stale`) is designed to mark and close stale issues and pull requests after a period of inactivity, but it never operates on git branches, making it ineffective for deleting old branches.

GitHub Discussions

Why it fails: GitHub Discussions is a collaborative space for community Q&A and conversations, not a branch management tool; it provides no mechanism to list or delete git branches, so it is irrelevant to the stale branch requirement.

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

Why it fails: Azure Repos uses branch policies, not GitHub branch protection.

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

Why it fails: This only prevents direct pushes but does not prevent developers from creating pull requests into main.

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

Why it fails: Build requirements do not restrict who can merge.

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

Why it fails: Git hooks execute on a developer's local machine, not on the Azure Pipelines agent, so they can be bypassed (e.g., with --no-verify) and offer no server-side enforcement. For CI/CD, builds must run centrally and deterministically on every commit; relying on local hooks cannot guarantee that changes are built or that the pipeline reflects repository state.

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

Why it fails: A single YAML pipeline with conditions on changed files still triggers the pipeline for every push to the branch, causing unnecessary pipeline runs, resource consumption, and potential queuing delays. The condition only skips steps after the pipeline has already started; path filters in the trigger section prevent the pipeline from running in the first place when unrelated folders change.

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

Why it fails: Configuring path filters under the trigger section (e.g., trigger: paths: include: ['projectA/**']) ensures Azure Pipelines only starts a run when files under the specified project folder are changed. This provides efficient, server-side filtering that avoids entire builds for unrelated monorepo changes, keeping the pipeline focused and minimizing wasted CI minutes.

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

Why it fails: BFG is effective but git filter-repo is the recommended modern tool.

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

Why it fails: This loses all commits on the branch, not just the secret.

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

Why it fails: Reverting leaves the secret in the history, accessible via git log.

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

Why it fails: Incorrect because the 'Require a linked work item' branch policy in Azure Repos applies only to pull requests, not to direct pushes. It cannot enforce linked work items on commits pushed directly to main.

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

Why it fails: Azure Repos does not support custom pre-receive hooks; that server-side mechanism belongs to Git platforms such as GitLab, so nothing would execute to reject the commit. It is tempting because pre-receive hooks are the right tool for enforcing commit-message or metadata rules on those other platforms.

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

Why it fails: Gated check-in queues a build that must succeed before changes are committed; it validates compilation and tests, not the presence of a linked Azure Boards work item. It is tempting because gated check-in is the correct policy when you must block commits that fail a build.

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

Why it fails: The Azure DevOps Migration Tool (and Azure Repos' native TFVC import) migrates version control artifacts such as changesets and files, but it does not convert TFVC's path-based ACLs into Git permissions. TFVC security is applied to hierarchical folders and branches via inherited access control lists, whereas Git in Azure Repos governs permissions at the repository and branch level through security groups and branch policies (e.g., requiring pull request reviewers). Since these permission models are structurally incompatible, any security or approval rules must be manually recreated in the new Git environment — the tool cannot 'map' them directly. Attempting to rely on it for permission migration would leave gaps in access control and policy enforcement.

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

Why it fails: TFVC branches are path-based folders within the repository, while Git branches are lightweight pointers to commits; simply recreating TFVC folders as Git branches loses the folder structure and may create a confusing, non-standard layout. Instead, design a Git branching strategy (like feature branching or GitFlow) that fits your team.

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

Why it fails: Git LFS (Large File Storage) is used to manage large binary files by storing them outside the Git repository, but it is not a tool for migrating from TFVC; it should be considered after the migration to optimize repository size, and enabling it prematurely does not aid in the historical conversion of TFVC data.

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

Why it fails: Git submodules are for code, not for workflows.

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

Why it fails: Branch protection rules do not centralize workflow definitions.

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

Why it fails: There is no 'workflow library' feature in GitHub.