CCNA Source Control Strategy Questions — Page 2 of 2

MCQhard

Your organization is migrating from Azure Repos to GitHub. You have 200 repositories with complex branching strategies and build policies. You need to preserve the commit history and branch policies. What is the best migration approach?

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

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

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

D.Use git push --force to push all branches to GitHub and recreate policies manually

AnswerD

Using `git push --force` migrates all commit history, and then recreating policies manually or via API ensures both history and policies are preserved.

Why this answer

The GitHub Importer tool does not preserve branch policies; it only migrates repository history and code. To keep commit history and then recreate branch policies, the best approach is to use `git push --force` to push all branches from Azure Repos to GitHub, then recreate branch policies manually or via the GitHub API. This ensures complete history is preserved while policies are re-established separately.

Exam trap

Candidates often assume the GitHub Importer tool can also migrate branch policies, but it only migrates repository code and history. Platform-specific policies like branch protection must be recreated manually or via API.

How to eliminate wrong answers

Option A is wrong because manually recreating repositories and copying code loses commit history and branch policies, which is inefficient and error-prone for 200 repositories. Option B is wrong because a third-party mirror clone only copies the repository data (commits, branches) but does not migrate branch policies or build policies, which are critical for compliance and CI/CD. Option D is wrong because git push --force pushes all branches but does not preserve branch policies, and recreating them manually for 200 repositories is impractical and risks misconfiguration.

Practice this question →

MCQeasy

Your Azure DevOps repository contains a large binary file that is slowing down clone operations. Which Git feature should you use to reduce the clone time?

A.Shallow clone

B.Git LFS (Large File Storage)

C.Depth parameter in clone command

D.Sparse checkout

AnswerB

Git LFS replaces large binary files with text pointers in the Git repository, storing the actual file content in a separate remote LFS store. On clone/checkout, pointers are swapped for the real files, which keeps the Git database small and prevents repository bloat.

Why this answer

Git LFS (Large File Storage) is the correct solution because it replaces large binary files in the repository with lightweight text pointers, storing the actual binary content in external remote storage. This prevents the large file from being downloaded during every clone, significantly reducing clone time and repository size on disk.

Exam trap

The trap here is that candidates confuse shallow clones or sparse checkouts as solutions for large files, when in fact those features address history depth or working tree scope, not the fundamental problem of large binary objects being stored and transferred in the repository.

How to eliminate wrong answers

Option A is wrong because a shallow clone (using --depth 1) limits the commit history but still downloads the current version of all files, including the large binary, so it does not address the root cause of the large file slowing clones. Option C is wrong because the depth parameter is simply the mechanism to perform a shallow clone; it has the same limitation as option A and does not exclude the large binary from being downloaded. Option D is wrong because sparse checkout limits which directories or files are populated in the working tree, but the entire repository object data (including the large binary) is still downloaded during clone; it only affects checkout, not the transfer size.

Practice this question →

MCQeasy

Your development team uses GitHub for source control. You want to automatically run a set of tests every time a pull request is opened against the main branch. What should you configure?

A.Create a GitHub Actions workflow triggered by pull_request events to main

B.Use the GitHub API to trigger tests when a PR is opened

C.Set up a webhook to trigger an external CI system

D.Configure a branch protection rule to require status checks

AnswerA

A GitHub Actions workflow with a `pull_request` trigger to `main` is the native, built-in CI/CD solution: it automatically runs any defined test jobs on every PR, and its resulting status checks integrate directly with GitHub’s branch protection and PR UI. This is the correct approach because no external service or custom listener is needed.

Why this answer

GitHub Actions natively supports the `pull_request` event trigger, which can be configured to run workflows automatically when a pull request is opened against a specific branch (e.g., `main`). This allows you to define a YAML-based workflow in the `.github/workflows` directory that executes tests on every PR event, providing immediate feedback to developers without requiring external services or manual API calls.

Exam trap

The trap here is that candidates often confuse branch protection rules (which enforce status checks) with the actual mechanism that triggers the tests, leading them to select Option D, but protection rules only block merges without initiating any automated testing.

How to eliminate wrong answers

Option B is wrong because using the GitHub API to trigger tests when a PR is opened would require custom polling or event handling logic, which is inefficient and not a built-in automation mechanism; GitHub Actions already provides a declarative event-driven trigger. Option C is wrong because setting up a webhook to trigger an external CI system is an alternative approach, but the question asks what you should configure, and GitHub Actions is the native, recommended solution for GitHub-hosted repositories, making this option less direct and more complex. Option D is wrong because configuring a branch protection rule to require status checks only enforces that checks must pass before merging, but it does not automatically trigger the tests; it is a policy enforcement mechanism, not a trigger mechanism.

Practice this question →

MCQeasy

Your team uses Azure Pipelines to build and test code. You want to automatically trigger a pipeline when a pull request is created targeting the main branch. Which trigger should you configure?

A.PR trigger

B.Scheduled trigger

C.CI trigger

D.Manual trigger

AnswerA

PR trigger is the correct answer because Azure Pipelines automatically runs a pipeline when a pull request is created or updated in a branch, allowing validation of proposed changes before merge. It is ideal for verifying code in a feature branch that is the source of a pull request, ensuring the target branch remains stable.

Why this answer

A PR trigger is the correct choice because Azure Pipelines supports a 'pr' trigger that automatically starts a pipeline when a pull request is created targeting a specified branch (e.g., main). This is distinct from a CI trigger, which runs on commits to a branch, and is essential for validating changes before merging.

Exam trap

The trap here is that candidates often confuse CI triggers with PR triggers, assuming a CI trigger on the target branch will run for PRs, but CI triggers only fire on direct pushes, not on PR creation events.

How to eliminate wrong answers

Option B is wrong because a scheduled trigger runs pipelines on a time-based schedule (e.g., nightly), not in response to pull request creation. Option C is wrong because a CI trigger runs when code is pushed to a branch, not when a pull request is created; it does not differentiate between direct commits and PRs. Option D is wrong because a manual trigger requires a user to explicitly start the pipeline via the Azure DevOps UI or API, providing no automation for PR events.

Practice this question →

Multi-Selecteasy

Which TWO are valid reasons to use a monorepo?

Select 2 answers

A.Smaller clone size compared to multiple repositories.

B.Simplifies code sharing and reuse across multiple projects.

C.Allows independent CI/CD pipelines for each project.

D.Improves security by isolating each project.

E.Simplifies dependency management and versioning.

AnswersB, E

Because all code lives in a single repository, projects can share internal libraries and components directly without needing to publish and consume separate packages from an external registry. This enables immediate reuse and atomic, cross-project changes in the same commit, which simplifies refactoring and speeds up development.

Why this answer

A monorepo centralizes all code in a single repository, making it straightforward to share common libraries, utilities, and components across multiple projects without needing separate package feeds or submodule references. Option E is correct because with all projects in one repo, dependency versions are unified and managed in a single set of manifest files (e.g., package.json, requirements.txt), eliminating cross-repo version drift and simplifying coordinated updates.

Exam trap

The trap here is that candidates confuse the theoretical benefits of isolation (C and D) with the practical reality of monorepos, which trade isolation for simplified sharing and unified versioning, while clone size (A) is actually larger, not smaller.

Practice this question →

MCQmedium

Your team is migrating from TFVC to Git in Azure Repos. They want to preserve the history of all branches. Which migration tool should you use?

A.GitHub Importer

B.Azure DevOps Migration Tools

C.git-tfs tool

D.git-svn

AnswerC

Preserves history and branches.

Why this answer

The git-tfs tool is specifically designed to migrate TFVC repositories to Git while preserving full branch history, including changesets, branch relationships, and merge history. It bridges the gap between TFVC and Git by converting TFVC changesets into Git commits and mapping TFVC branches to Git branches, making it the correct choice for this migration scenario.

Exam trap

The trap here is that candidates often confuse git-tfs with git-svn, assuming both are interchangeable for any centralized-to-distributed migration, but git-tfs is TFVC-specific while git-svn is for Subversion, and Azure DevOps Migration Tools are for organizational data migration, not source control conversion.

How to eliminate wrong answers

Option A is wrong because GitHub Importer is used to import repositories from other Git hosts (like SVN, Mercurial, or another Git server) into GitHub, not from TFVC to Azure Repos. Option B is wrong because Azure DevOps Migration Tools are designed for migrating work items, test plans, and other Azure DevOps artifacts between organizations, not for converting TFVC source control history to Git. Option D is wrong because git-svn is a tool for bidirectional operation between Git and Subversion (SVN), not for TFVC migration.

Practice this question →

MCQmedium

Your team uses GitHub with a monorepo containing frontend and backend code. You need to implement a strategy where changes to the frontend folder trigger a frontend CI pipeline, changes to the backend folder trigger a backend CI pipeline, and changes to both trigger both. You also want to ensure that pull requests include changes only to one area to reduce complexity. What should you do?

A.Use CODEOWNERS to assign different reviewers for frontend and backend, and rely on manual pipeline triggers.

B.Configure separate CI pipelines with path filters so that each pipeline triggers only on changes to its respective folder.

C.Create branch policies that require specific builds based on the branch name.

D.Use a single pipeline that runs all tests on every change.

AnswerB

Path filters allow conditional triggering.

Why this answer

GitHub Actions and Azure Pipelines support path filters (e.g., `paths` in YAML triggers) that allow you to define separate CI pipelines for frontend and backend folders. When a pull request includes changes to both folders, both pipelines automatically trigger, satisfying the requirement. This approach ensures that each pipeline runs only when its relevant code changes, reducing unnecessary builds and complexity.

Exam trap

The trap here is that candidates may think branch policies or CODEOWNERS can control pipeline triggers, but only path filters in the pipeline YAML definition can conditionally start a pipeline based on which files changed.

How to eliminate wrong answers

Option A is wrong because CODEOWNERS only assigns reviewers based on file paths, not pipeline triggers, and relying on manual pipeline triggers defeats the purpose of CI automation. Option C is wrong because branch policies that require specific builds based on branch name cannot differentiate between frontend and backend changes within the same branch; they apply to all changes on that branch. Option D is wrong because a single pipeline that runs all tests on every change would not differentiate between frontend and backend changes, violating the requirement to trigger separate pipelines based on the changed folder.

Practice this question →

MCQhard

Your company uses Azure DevOps and has a large monorepo with multiple teams. Developers report that Git operations are slow due to the repository size. Which approach should you recommend to improve performance while maintaining a single repository?

A.Use Git LFS to store all files

B.Split the monorepo into multiple smaller repositories

C.Add a .gitattributes file with filter directives

D.Enable sparse checkout and shallow fetch

AnswerD

Sparse checkout restricts the working tree to only the directories or files you actually need, reducing checkout time and disk usage. Shallow fetch with a depth limit downloads only the most recent commits, drastically reducing the number of objects transferred; combined, these are the standard Git techniques to speed up work with a large monorepo.

Why this answer

Sparse checkout and shallow fetch are designed to improve Git performance in large monorepos by limiting the working tree to specific directories (sparse checkout) and reducing the history depth (shallow fetch). This keeps the repository intact as a single unit while significantly reducing the amount of data transferred and stored locally, directly addressing the slow Git operations without breaking the monorepo structure.

Exam trap

The trap here is that candidates often confuse performance improvements with repository restructuring, assuming that splitting the repo (Option B) is the only way to speed up Git, when Azure DevOps supports native Git features like sparse checkout and shallow fetch that preserve the monorepo architecture.

How to eliminate wrong answers

Option A is wrong because Git LFS is intended for large binary files, not for improving general Git performance on a large monorepo; storing all files in LFS would introduce overhead and break normal Git workflows. Option B is wrong because splitting the monorepo into multiple smaller repositories violates the requirement to maintain a single repository. Option C is wrong because .gitattributes with filter directives is used for custom smudge/clean filters (e.g., for Git LFS or keyword expansion), not for reducing the size or history of the repository to speed up operations.

Practice this question →