Courseiva

CCNA Design and implement a source control strategy Questions

20 of 95 questions · Page 2/2 · Design and implement a source control strategy · Answers revealed

Practice these questionsDomain overviewAll questions
76
MCQeasy

Your team uses GitHub Flow and wants to ensure that every pull request is reviewed by at least one team member. Which branch protection rule should you enable?

A.Require a pull request before merging and set required number of reviewers to 1
B.Require signed commits
C.Require status checks to pass before merging
D.Require conversation resolution before merging
AnswerA

This enforces review before merge.

Why this answer

Option A is correct because GitHub Flow relies on pull requests for collaboration, and the 'Require a pull request before merging' rule with a required number of reviewers set to 1 enforces that every PR must be reviewed by at least one team member before it can be merged. This directly satisfies the requirement of ensuring code review for all changes.

Exam trap

The trap here is that candidates may confuse 'requiring status checks' (automated validation) with 'requiring pull request reviews' (human validation), leading them to select option C instead of A.

How to eliminate wrong answers

Option B is wrong because requiring signed commits ensures commit authenticity and integrity via GPG or S/MIME signatures, but it does not enforce any review process. Option C is wrong because requiring status checks to pass before merging ensures that CI/CD checks (e.g., tests, builds) succeed, but it does not mandate human review. Option D is wrong because requiring conversation resolution before merging ensures that all comments on a PR are marked as resolved, but it does not guarantee that a specific number of reviewers have approved the changes.

Practice this question →
77
MCQmedium

Your team uses GitHub for source control and wants to enforce that all pull requests into the main branch require at least two reviewers and must pass a status check from a CI pipeline. Which branch protection rule configurations should you apply?

A.Require a minimum of 2 reviewers, require status checks to pass before merging
B.Require signed commits and status checks
C.Require status checks to pass, but do not require reviewers
D.Require a minimum of 2 reviewers, but do not require status checks
AnswerA

Correctly includes both requirements.

Why this answer

Option A is correct because GitHub branch protection rules allow you to require a minimum number of reviewers before merging and to require status checks to pass. By setting 'Require a minimum number of reviewers' to 2 and enabling 'Require status checks to pass before merging', you enforce that every pull request into the main branch must be approved by at least two reviewers and must pass the CI pipeline status check, meeting the stated requirements.

Exam trap

The trap here is that candidates may think requiring signed commits or only status checks is sufficient, but the question explicitly demands both two reviewers and a CI status check, which only option A satisfies.

How to eliminate wrong answers

Option B is wrong because requiring signed commits ensures commit authenticity but does not enforce the required two reviewers or the CI status check. Option C is wrong because it omits the requirement for at least two reviewers, which is explicitly needed. Option D is wrong because it omits the requirement for status checks to pass, leaving the CI pipeline result unenforced.

Practice this question →
78
MCQhard

You are designing a Git branching strategy for a large enterprise with multiple Azure DevOps projects. The strategy must support hotfixes for production releases, feature development in isolated branches, and release branches for stabilization. The team uses CI/CD pipelines that trigger on branch creation. You need to minimize merge conflicts and ensure that hotfix changes are propagated to all active branches. Which branching model should you recommend and how should you configure branch policies?

A.Use GitHub Flow with feature branches merging directly to main. Use a release branch for stabilization. Use pull requests for all merges.
B.Use trunk-based development with short-lived feature branches. Use feature toggles for incomplete work. No separate hotfix branch.
C.Use a forking workflow where each developer forks the repository and submits pull requests. Use branch policies on the upstream main branch.
D.Use GitFlow with main, develop, and hotfix branches. Configure branch policies on main and develop to enforce pull requests with required reviewers. Use a pipeline to automatically merge hotfix branches into both main and develop.
AnswerD

GitFlow supports hotfix propagation; policies enforce quality.

Why this answer

Option A is correct because GitFlow with branch policies on main and develop that enforce hotfix merges via pull request ensures propagation. Option B (GitHub Flow) does not have dedicated hotfix branches and release branches. Option C (Trunk-Based) lacks hotfix isolation.

Option D (Forking) is for external contributions, not enterprise internal.

Practice this question →
79
MCQmedium

Your organization uses GitHub Enterprise and wants to prevent secrets (e.g., API keys) from being pushed to any repository. Which GitHub feature should you enable?

A.Repository rulesets
B.GitHub Advanced Security secret scanning
C.Push protection for secret scanning
D.Branch protection rules requiring signed commits
AnswerC

Push protection prevents commits with secrets from being pushed.

Why this answer

Push protection for secret scanning (Option C) is the correct answer because it actively blocks pushes that contain known secrets (e.g., API keys, tokens) at the client side, preventing them from ever reaching the remote repository. This is a dedicated feature of GitHub Advanced Security that integrates with pre-receive hooks to scan commits in real time, rejecting the push if a secret pattern is detected. It is specifically designed to prevent secrets from being pushed, unlike passive scanning which only alerts after the fact.

Exam trap

The trap here is that candidates confuse 'secret scanning' (passive detection) with 'push protection' (active prevention), assuming that enabling GitHub Advanced Security secret scanning alone will block pushes, when in fact push protection is a separate toggle that must be explicitly enabled.

How to eliminate wrong answers

Option A is wrong because repository rulesets are used to enforce branch policies (e.g., required status checks, merge restrictions) but do not scan or block secrets in commits. Option B is wrong because GitHub Advanced Security secret scanning alone only detects secrets after they have been pushed (via alerts or pull request comments) and does not prevent the push from succeeding. Option D is wrong because branch protection rules requiring signed commits enforce commit integrity via GPG or S/MIME signatures but have no mechanism to inspect commit content for secrets.

Practice this question →
80
MCQeasy

You are setting up a new GitHub repository for a project that requires strict access control. Only specific team members should be able to push to the main branch, but all team members should be able to create branches and open pull requests. What is the best way to achieve this?

A.Add all team members as administrators of the repository.
B.Remove write permissions for non-core team members and give them read-only access.
C.Use a branch protection rule to restrict pushes to the main branch to specific users or teams.
D.Set the repository to private and invite only core team members.
AnswerC

Allows branch creation but restricts pushes to main.

Why this answer

Branch protection rules in GitHub allow you to enforce restrictions on specific branches, such as requiring pull request reviews or restricting who can push directly. By configuring a rule for the main branch that limits push access to only designated users or teams, you ensure that all team members can create branches and open PRs, but only authorized members can merge into main. This directly meets the requirement without over-provisioning permissions or blocking collaboration.

Exam trap

The trap here is that candidates often confuse restricting push access with removing write permissions entirely, not realizing that branch protection rules allow granular control over specific branches while preserving write-level collaboration on other branches.

How to eliminate wrong answers

Option A is wrong because adding all team members as administrators grants them full control over the repository, including the ability to bypass any restrictions and push directly to main, which violates the strict access control requirement. Option B is wrong because removing write permissions for non-core members and giving them read-only access prevents them from creating branches or opening pull requests, which contradicts the requirement that all team members should be able to do so. Option D is wrong because setting the repository to private and inviting only core team members excludes non-core members entirely, preventing them from creating branches or opening pull requests, which is not the desired outcome.

Practice this question →
81
MCQhard

You are designing a source control strategy for a team that uses GitHub Copilot. The team wants to ensure that code suggestions do not include sensitive data. Which approach should you recommend?

A.Use pre-commit hooks to scan for secrets
B.Disable GitHub Copilot for the organization
C.Enable secret scanning for the repository
D.Configure content exclusions in GitHub Copilot settings to block sensitive data patterns
AnswerD

Prevents suggestions with secrets.

Why this answer

Option C is correct because GitHub Copilot policies can be configured to block suggestions containing secrets. Option A is wrong because it disables Copilot entirely. Option B is wrong because it only alerts, not blocks.

Option D is wrong because it is a post-commit measure.

Practice this question →
82
MCQhard

You see the above git log output. The team has a policy requiring linear history on the main branch. Which command should be used next time to integrate the feature branch?

A.git merge --squash feature/login
B.git cherry-pick f4e5d6c a7b8c9d
C.git merge --no-ff feature/login
D.git rebase main feature/login then git merge --ff-only
AnswerD

Rebase creates linear history; fast-forward merge preserves it.

Why this answer

Option D is correct because the team requires a linear history on the main branch. By first rebasing the feature branch onto main (`git rebase main feature/login`), you reapply the feature commits on top of the latest main commit, creating a clean, linear sequence. Then `git merge --ff-only` performs a fast-forward merge, which simply moves the main branch pointer forward without creating a merge commit, preserving the linear history policy.

Exam trap

The trap here is that candidates often confuse `--no-ff` (which preserves history but creates a merge commit) with the requirement for linear history, or they incorrectly think `git cherry-pick` is a valid way to integrate an entire feature branch.

How to eliminate wrong answers

Option A is wrong because `git merge --squash` collapses all feature commits into a single commit, which violates the requirement to integrate the feature branch while preserving its individual commits (the log shows multiple commits). Option B is wrong because `git cherry-pick f4e5d6c a7b8c9d` only applies two specific commits, not the entire feature branch, and it does not integrate the branch in a way that maintains a clean linear history. Option C is wrong because `git merge --no-ff` forces a merge commit even when a fast-forward is possible, which creates a non-linear history (a merge bubble) that violates the linear history policy.

Practice this question →
83
MCQhard

Your organization uses Azure DevOps for a large-scale e-commerce platform. The source code is stored in a single Azure Repos Git repository with over 100 contributors. The current branching strategy is a modified GitFlow with main, develop, release, and hotfix branches. However, the team is experiencing frequent merge conflicts and long integration periods. You have been asked to redesign the branching strategy to support continuous integration and deployment (CI/CD) while ensuring high-quality releases. The new strategy must reduce merge conflicts, enable fast feedback, and support hotfixes. The team uses feature flags to manage incomplete features. Which branching strategy should you recommend?

A.Implement trunk-based development: developers work on short-lived feature branches (less than a day) and merge to main multiple times a day. Use feature flags to control release of incomplete features. Hotfixes are created from main and merged back quickly.
B.Use a single main branch and allow developers to commit directly to main, but require all commits to be small and pass CI. Hotfixes are committed directly to main.
C.Use a single main branch and create release branches from main for each deployment. Feature branches are merged to release branches, and then release branches are merged to main after deployment.
D.Continue using GitFlow but enforce stricter branch policies and require more frequent merges.
AnswerA

Trunk-based development with feature flags minimizes merge conflicts and enables CI/CD.

Why this answer

Option B is correct because trunk-based development with short-lived feature branches and feature flags is designed to reduce merge conflicts and enable continuous integration. Option A is incorrect because GitFlow is the current problematic strategy. Option C is incorrect because release branches are not suitable for CI/CD with feature flags.

Option D is incorrect because long-lived feature branches are the opposite of what is needed.

Practice this question →
84
MCQmedium

Your organization uses GitHub Enterprise with a monorepo containing multiple microservices. Developers work on feature branches and create pull requests to merge into main. You need to implement a policy that ensures all pull requests have at least one review from a code owner, pass required status checks (CI build and unit tests), and are up-to-date with the latest main branch before merging. Additionally, you want to prevent direct pushes to main. Which combination of branch protection rules should you configure?

A.Require pull request reviews before merging, require status checks, and restrict who can push to matching branches.
B.Require pull request reviews before merging, require branches to be up-to-date, and restrict push access to admins only.
C.Require status checks, require branches to be up-to-date, and include administrators.
D.Require pull request reviews before merging, require status checks, require branches to be up-to-date, and restrict who can push to matching branches.
AnswerD

Includes all required protections.

Why this answer

Option D is correct because it includes all required elements: require pull request reviews before merging, require status checks, require branches to be up-to-date, and restrict direct pushes. Option A lacks the up-to-date requirement. Option B does not require pull requests.

Option C lacks status checks.

Practice this question →
85
MCQhard

Your team uses Azure Repos and wants to enforce that all commits to the release branch must be signed using GPG. Which branch policy should you enable?

A.Limit merge types
B.Check for linked work items
C.Require a minimum number of reviewers
D.Require signed commits
AnswerD

This policy enforces GPG or S/MIME signing.

Why this answer

Option D is correct because Azure Repos branch policies include a 'Require signed commits' setting that enforces GPG signature verification on all commits pushed to the branch. When enabled, any commit without a valid GPG signature is rejected, ensuring the integrity and authenticity of the commit author.

Exam trap

The trap here is that candidates may confuse 'Require signed commits' with other authentication or authorization policies, such as requiring reviewers or limiting merge types, because all are listed under branch policy settings but serve entirely different security purposes.

How to eliminate wrong answers

Option A is wrong because 'Limit merge types' controls the merge strategies (e.g., squash, rebase, or no-fast-forward) allowed on the branch, not commit signing. Option B is wrong because 'Check for linked work items' enforces that pull requests reference Azure Boards work items, which is unrelated to cryptographic commit signing. Option C is wrong because 'Require a minimum number of reviewers' mandates a certain count of reviewers approve a pull request before merging, but does not enforce that individual commits are signed with GPG.

Practice this question →
86
MCQhard

You are designing a branching strategy for a microservices application with independent deployment cadences. The team wants to support continuous deployment to production from the main branch while allowing feature work to be isolated and tested. Which branching strategy best meets these requirements?

A.One branch per environment (dev, test, prod)
B.GitHub Flow with feature branches merging to main
C.Trunk-based development with short-lived feature branches
D.Git Flow with develop, release, and hotfix branches
AnswerC

Supports CI/CD and isolation.

Why this answer

Trunk-based development with short-lived feature branches (C) is correct because it enables continuous deployment from the main branch while isolating feature work in branches that are merged back to main within hours or a day. This approach minimizes merge conflicts and supports independent deployment cadences for microservices, as each service can be deployed from main independently without waiting for release branches.

Exam trap

The trap here is that candidates confuse GitHub Flow with trunk-based development, but GitHub Flow lacks the strict short-lived branch discipline and feature toggle support required for true continuous deployment from main in a microservices context.

How to eliminate wrong answers

Option A is wrong because one branch per environment (dev, test, prod) creates long-lived branches that diverge over time, leading to merge hell and preventing continuous deployment from a single source of truth. Option B is wrong because GitHub Flow with feature branches merging to main does not inherently support independent deployment cadences for microservices; it assumes a single deployment pipeline and can cause blocking if multiple features are merged before validation. Option D is wrong because Git Flow with develop, release, and hotfix branches introduces long-lived branches and release cycles that conflict with continuous deployment to production from main, as releases are staged through develop and release branches rather than directly from main.

Practice this question →
87
MCQeasy

Your team is migrating from TFVC to Git in Azure Repos. You need to preserve the full history of the TFVC repository, including all branches and changesets. The TFVC repository is large (over 10 GB). Which tool should you use to perform the migration?

A.Manually recreate the commits in a new Git repository.
B.Use git-tfs to clone the TFVC repository and then push to Azure Repos.
C.Use git-svn to convert TFVC to Git.
D.Use the Azure DevOps Migration Tools to export TFVC to Git.
AnswerB

git-tfs preserves history and handles large repos.

Why this answer

B is correct because git-tfs is specifically designed to bridge TFVC and Git, allowing you to clone a TFVC repository (including all branches, changesets, and history) into a local Git repository, which can then be pushed to Azure Repos. It handles large repositories (over 10 GB) by performing an incremental clone, preserving the full history without manual recreation.

Exam trap

The trap here is that candidates confuse git-tfs with git-svn, assuming any 'git-*' tool works for any version control system, but git-svn only works with Subversion, not TFVC.

How to eliminate wrong answers

Option A is wrong because manually recreating commits in a new Git repository would lose the full history, branches, and changesets, which contradicts the requirement to preserve them. Option C is wrong because git-svn is designed for Subversion (SVN) repositories, not TFVC; it cannot interpret TFVC's changeset structure or branching model. Option D is wrong because the Azure DevOps Migration Tools are primarily for migrating work items, test plans, and other Azure DevOps artifacts between organizations, not for converting TFVC repositories to Git with full history.

Practice this question →
88
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
AnswerC

GitHub Importer preserves history and can map branch policies.

Why this answer

The GitHub Importer tool, combined with a custom mapping script, is the correct approach because it can migrate repositories along with their commit history and branch policies from Azure Repos to GitHub. This tool handles the complex branching strategies and build policies by allowing you to define mappings for users, branches, and policies, ensuring a seamless transition without manual recreation or data loss.

Exam trap

The trap here is that candidates often assume a simple git push --force (Option D) is sufficient for migration, overlooking that branch policies are not stored in the Git repository itself but in the platform's metadata, requiring a tool like GitHub Importer to transfer them.

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 →
89
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

Replaces large files with pointers.

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 →
90
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

GitHub Actions can run tests automatically on pull requests.

Why this answer

Option A is correct because 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 →
91
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 runs when a pull request is created or updated.

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 →
92
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

All code resides in one repository, making sharing easy.

Why this answer

Option B is correct because 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 →
93
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 →
94
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

Option B is correct because 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 →
95
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 limits checkout to needed files; shallow fetch limits history depth.

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 →
← PreviousPage 2 of 2 · 95 questions total

Ready to test yourself?

Try a timed practice session using only Design and implement a source control strategy questions.

Start 20-question session