Courseiva

CCNA Design and implement source control Questions

32 questions · Design and implement source control · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

A development team uses Git for source control. They want to ensure that all code changes are reviewed before merging into the main branch. Which branch policy should they configure in Azure Repos?

A.Configure a branch policy that requires a minimum number of reviewers and resolves all comments.
B.Configure a branch policy that requires commit messages to follow a specific pattern.
C.Configure a branch policy that requires a successful build.
D.Configure a branch policy that requires linked work items.
AnswerA

This enforces peer review before merge.

Why this answer

Option A is correct because Azure Repos branch policies allow you to enforce that pull requests require a minimum number of reviewers and that all comments are resolved before merging. This directly ensures that all code changes are reviewed and any feedback is addressed, meeting the team's requirement for mandatory code review before merging into the main branch.

Exam trap

The trap here is that candidates may confuse 'code review' with other quality gates like build validation or work item linking, but the question explicitly asks for a policy that ensures all changes are reviewed before merging, which is directly addressed only by reviewer and comment resolution policies.

How to eliminate wrong answers

Option B is wrong because requiring commit messages to follow a specific pattern enforces formatting conventions, not code review. Option C is wrong because requiring a successful build ensures code quality and integration, but does not mandate human review of the changes. Option D is wrong because requiring linked work items enforces traceability to tasks or user stories, not a code review process.

Practice this question →
2
MCQmedium

A team is migrating from TFVC to Git in Azure Repos. They have a large repository with a history of 10,000+ commits. They want to preserve the full history while minimizing migration time. Which approach should they recommend?

A.Use git-tfs to clone the TFVC repository with full history, then push to Azure Repos.
B.Check out the latest version from TFVC, initialize a new Git repo, and push.
C.Use the Azure Repos import repository feature to import from TFVC.
D.Clone the TFVC repository using Git and push to Azure Repos.
AnswerA

git-tfs preserves history and is designed for TFVC to Git migration.

Why this answer

Option A is correct because git-tfs is a specialized bridge tool that can clone a TFVC repository with full history into a local Git repository, preserving all commits, branches, and metadata. This approach minimizes migration time by performing the conversion locally without network overhead, after which the Git repo can be pushed to Azure Repos. Other methods either lose history or are not supported for TFVC-to-Git migration.

Exam trap

The trap here is that candidates may assume Azure Repos has a built-in TFVC import feature (Option C) or that Git can natively clone TFVC (Option D), when in fact only git-tfs or similar third-party tools can perform a full-history migration from TFVC to Git.

How to eliminate wrong answers

Option B is wrong because checking out only the latest version from TFVC and initializing a new Git repo discards all historical commits, which violates the requirement to preserve full history. Option C is wrong because the Azure Repos import repository feature only supports importing from external Git repositories (e.g., GitHub, Bitbucket), not from TFVC. Option D is wrong because Git cannot directly clone a TFVC repository; TFVC uses a different version control protocol and data model, so a standard Git clone operation will fail.

Practice this question →
3
Multi-Selectmedium

Which TWO actions should you take to ensure that your Git repository in Azure Repos remains performant as it grows?

Select 2 answers
A.Use shallow clones in CI/CD pipelines.
B.Store large binary files directly in the repository.
C.Use Git LFS for large binary files.
D.Keep all branches indefinitely to preserve history.
E.Encourage developers to commit all changes in a single commit per day.
AnswersA, C

Shallow clones fetch only recent history, reducing clone time.

Why this answer

Shallow clones fetch only the most recent commit history rather than the entire repository history, which significantly reduces the amount of data transferred and stored during CI/CD pipeline runs. This keeps pipeline execution fast and avoids performance degradation as the repository grows. Azure Repos and Azure Pipelines support shallow clone options via the `--depth` parameter in Git commands or through pipeline YAML settings.

Exam trap

The trap here is that candidates may think storing binaries directly in the repo is acceptable for performance, or that reducing commit frequency improves performance, when in fact these actions degrade performance or violate source control best practices.

Practice this question →
4
MCQmedium

An organization has multiple Git repositories. Developers often forget to update the repository README file after making changes. What is the most effective way to ensure the README is always up-to-date?

A.Apply a label to PRs that touch certain files and require review
B.Add a task in the CI pipeline that checks if the README was modified
C.Use a repository template with a mandatory README file structure
D.Require a pull request comment that confirms README update
AnswerC

Templates provide a starting point and can include a README that developers must fill.

Why this answer

Option C is correct because using a repository template with a mandatory README file structure enforces a consistent baseline for all new repositories, ensuring that a README is always present and follows a predefined format. This approach addresses the root cause—developers forgetting to update the README—by making the README an integral part of the repository creation process, rather than relying on post-hoc checks or manual reviews. In Azure Repos, repository templates can include required files and folder structures, which are automatically applied when a new repository is created from the template, thereby preventing the omission of the README from the start.

Exam trap

The trap here is that candidates often overestimate the effectiveness of CI pipeline checks or PR requirements, failing to recognize that only a structural enforcement mechanism (like a template) can guarantee the presence of a file, whereas content accuracy requires human review or advanced automation that is not implied in the options.

How to eliminate wrong answers

Option A is wrong because applying a label to PRs that touch certain files and requiring review only flags changes to specific files but does not enforce that the README is updated; developers can still submit PRs without modifying the README, and the label alone does not block the PR. Option B is wrong because adding a task in the CI pipeline that checks if the README was modified only detects whether the README file has changed, but it cannot determine if the README content is actually up-to-date with the code changes; a developer could make a trivial edit to the README to satisfy the check without ensuring accuracy. Option D is wrong because requiring a pull request comment that confirms a README update relies on manual developer discipline and is not enforceable; a developer could simply add the comment without actually updating the README, and there is no automated validation to verify the claim.

Practice this question →
5
Multi-Selectmedium

Which TWO branch policies can be configured in Azure Repos to enforce code quality?

Select 2 answers
A.Status check
B.Comment requirements
C.Build validation
D.Work item linking
E.Merge strategy
AnswersA, C

Requires external services (e.g., SonarQube) to pass.

Why this answer

Status check (A) is correct because Azure Repos allows you to require that a status check passes before a pull request can be completed. This enforces code quality by integrating with external or built-in services (e.g., Azure Pipelines, SonarQube) that run automated tests, linting, or security scans. Build validation (C) is correct because it triggers a build pipeline automatically when a pull request is created, ensuring the code compiles and passes defined quality gates before merging.

Exam trap

The trap here is that candidates often confuse 'comment requirements' with 'reviewer requirements' or assume 'work item linking' enforces quality, when in fact it only ensures traceability, not code quality.

Practice this question →
6
MCQhard

You are a DevOps engineer at a company that develops a cloud-based SaaS application. The application consists of multiple microservices, each stored in its own Git repository within a single Azure DevOps project. The team has grown rapidly, and developers frequently need to make changes that span multiple services. They often complain about the overhead of managing multiple pull requests and coordinating merges across repositories. To improve efficiency, the team lead suggests consolidating all microservices into a single monorepo. However, the lead architect is concerned about the impact on build times, as the CI pipeline currently builds each service independently. You are tasked with designing a source control strategy that reduces cross-repository coordination overhead while maintaining fast, independent builds. You propose using a monorepo with a structure that allows selective building. Which approach should you recommend?

A.Keep separate repositories but create a meta-repo that references them as submodules
B.Create a single monorepo with a build pipeline that uses path filters to trigger builds only for changed services
C.Keep separate repositories but use Git submodules to share code
D.Create a single monorepo with all services and a single build pipeline that builds everything
AnswerB

Allows atomic commits across services while maintaining independent builds.

Why this answer

Option B is correct because using a single monorepo with path filters in the build pipeline allows you to trigger builds only for the microservices that have changed, reducing cross-repository coordination overhead while maintaining fast, independent builds. Path filters in Azure Pipelines (e.g., `paths` in YAML) enable selective triggering based on file paths, so unchanged services are not rebuilt, preserving CI efficiency.

Exam trap

The trap here is that candidates may confuse a monorepo with a monolithic build, assuming all code must be built together, when in fact path filters allow selective building to maintain CI speed.

How to eliminate wrong answers

Option A is wrong because a meta-repo with submodules does not reduce coordination overhead; developers still need to manage multiple repositories and pull requests for changes across submodules, and submodules introduce complexity with detached HEAD states and synchronization issues. Option C is wrong because keeping separate repositories with Git submodules for shared code does not address the core problem of coordinating changes across multiple services; submodules add overhead for version pinning and updates, and do not enable selective building across services. Option D is wrong because a single monorepo with a single build pipeline that builds everything would dramatically increase build times, as every change would trigger a full build of all services, defeating the goal of maintaining fast, independent builds.

Practice this question →
7
MCQmedium

Refer to the exhibit. After executing the delete command, what is the state of the repository?

A.The tag v1.0-rc is removed, but the commit it pointed to is also deleted from the repository.
B.The tag v1.0-rc is removed, and the branch feature/new-feature is also deleted because it was the same object.
C.The tag v1.0-rc is removed, and the repository now contains only one tag (v1.0) and three branches.
D.The command fails because the tag does not exist.
AnswerC

The delete command removes the tag v1.0-rc. The other refs remain, so there is one tag and three branches.

Why this answer

The command deleted the tag refs/tags/v1.0-rc. After deletion, the tag is no longer available. The other refs (branches and tags) remain unchanged.

The repository now has only one tag: v1.0. The branches main, develop, and feature/new-feature still exist.

Practice this question →
8
Matchingmedium

Match each Git branching strategy to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Uses develop and feature branches with release branches

Feature branches merged to main with pull requests

Short-lived branches merged frequently to main

Main branch with release branches for production

Why these pairings

Common branching strategies used in Azure Repos.

Practice this question →
9
MCQmedium

Your team manages a large monorepo in Azure Repos containing multiple microservices. The repository has grown to over 10,000 files and 500 MB. Developers report that cloning and fetching operations are slow, often taking more than 10 minutes. Additionally, the CI pipeline triggers on every push to any branch, causing long queue times. You need to improve the developer experience and CI efficiency without splitting the repository. What should you do?

A.Configure shallow clone (depth=1) for all operations and disable CI triggers on feature branches.
B.Break the monorepo into multiple smaller repositories and use Git submodules to manage dependencies.
C.Implement Git Virtual File System (GVFS) for the repository and use CI triggers only on the main branch.
D.Use Git sparse checkout to clone only the folders needed for each microservice, and configure path-based CI triggers to run only when files in specific directories change.
AnswerD

Sparse checkout reduces download size, and path-based triggers reduce unnecessary CI runs.

Why this answer

Option D is correct because Git sparse checkout allows developers to clone only the specific directories they need for their microservice, reducing the amount of data transferred and stored locally, which directly addresses the slow clone/fetch issue. Additionally, path-based CI triggers in Azure Pipelines ensure that the CI pipeline only runs when files in the relevant directories change, reducing unnecessary builds and queue times. This approach improves both developer experience and CI efficiency without splitting the monorepo.

Exam trap

The trap here is that candidates may confuse sparse checkout with shallow clone or GVFS, or incorrectly assume that disabling CI triggers on feature branches is acceptable, when the real goal is to optimize both cloning and CI triggering without breaking the monorepo structure.

How to eliminate wrong answers

Option A is wrong because while shallow clone (depth=1) reduces clone time, disabling CI triggers on feature branches would prevent developers from getting early feedback on their changes, which is a core CI practice; it does not address the root cause of slow operations for existing clones or the need for selective CI execution. Option B is wrong because the question explicitly states 'without splitting the repository,' and using Git submodules would introduce additional complexity and management overhead, potentially breaking the monorepo structure. Option C is wrong because Git Virtual File System (GVFS) is designed for extremely large repositories (e.g., >10 GB) and is specific to Windows and Visual Studio; it is not a standard Git feature and would not be appropriate for a 500 MB repo, nor does it address path-based CI triggers.

Practice this question →
10
MCQhard

You are a DevOps engineer for a company developing a mobile application. The source code is stored in Azure Repos (Git). The team uses trunk-based development with short-lived feature branches. Recently, developers have reported that their feature branch builds are taking over 30 minutes, whereas the main branch builds complete in under 10 minutes. The pipeline is defined in a YAML file and includes steps to restore NuGet packages, compile, run unit tests, and perform code analysis. The pipeline also publishes build artifacts. The main branch has a branch policy that requires a successful build before merging. The feature branches do not have branch policies. All builds run on Microsoft-hosted agents. Upon investigation, you notice that the feature branch builds are restoring all NuGet packages from scratch each time, while main branch builds use cached packages. Additionally, the code analysis tool is scanning the entire codebase, not just the changed files. You need to reduce the feature branch build time to under 15 minutes without compromising code quality. Which course of action should you take?

A.Configure a self-hosted agent with pre-installed dependencies and a larger disk for faster I/O.
B.Enable pipeline caching for NuGet packages and configure the code analysis step to scan only changed files using path filters.
C.Remove the code analysis step from feature branch builds and only run it on main branch builds.
D.Increase the agent VM size to a more powerful SKU for feature branch builds.
AnswerB

Caching reduces restore time, and scanning only changed files reduces analysis time.

Why this answer

Option B is correct because it directly addresses the two root causes of the slow feature branch builds: uncached NuGet package restores and full-codebase code analysis. Enabling pipeline caching (using the Cache@2 task) stores the NuGet packages folder (typically ~/.nuget/packages) and restores it on subsequent runs, eliminating redundant downloads. Configuring the code analysis step with path filters (e.g., using the 'changedFiles' condition or a custom script) ensures only modified files are scanned, drastically reducing analysis time without sacrificing quality.

Exam trap

The trap here is that candidates often assume hardware upgrades (larger agents or self-hosted machines) are the solution, when the real issue is inefficient pipeline logic—specifically, missing caching and incremental scanning—which are software-level optimizations that directly target the root causes.

How to eliminate wrong answers

Option A is wrong because switching to a self-hosted agent with pre-installed dependencies and a larger disk does not address the core issues of uncached package restores or full-codebase scanning; it only improves I/O speed, which is not the bottleneck here. Option C is wrong because removing code analysis entirely from feature branch builds compromises code quality by allowing potential issues to go undetected until the main branch merge, violating the requirement to not compromise code quality. Option D is wrong because increasing the agent VM size (e.g., to a more powerful SKU) only speeds up execution but does not solve the fundamental problem of redundant package downloads and unnecessary full scans; it would still leave builds over 15 minutes and waste resources.

Practice this question →
11
MCQhard

A team uses Git-LFS to store large binary files. They observe that cloning the repository takes a long time because Git-LFS files are downloaded. How can they improve clone performance?

A.Use a shallow clone with depth 1
B.Use the --filter=blob:none option when cloning
C.Use sparse checkout to limit files in working directory
D.Configure git lfs prune to run automatically
AnswerB

This partial clone defers downloading LFS blobs until they are accessed.

Why this answer

Option B is correct because the `--filter=blob:none` option performs a partial clone, which omits all blob objects (including Git-LFS pointer files and other large blobs) from the initial download. This significantly reduces clone time by only fetching commit and tree metadata, and then lazily downloading blobs on demand when they are actually accessed. For Git-LFS specifically, this avoids downloading the large binary files stored in LFS until they are needed, improving clone performance.

Exam trap

The trap here is that candidates confuse shallow clones (which limit history) or sparse checkouts (which limit working tree files) with partial clones (which limit object downloads), not realizing that Git-LFS files are downloaded during checkout regardless of history depth or sparse patterns unless blob filtering is used.

How to eliminate wrong answers

Option A is wrong because a shallow clone with depth 1 reduces the commit history but does not prevent Git-LFS files from being downloaded; Git-LFS still downloads all LFS objects during checkout. Option C is wrong because sparse checkout limits the working directory to a subset of files but does not affect the download of Git-LFS objects; all LFS files in the checked-out commit are still fetched. Option D is wrong because `git lfs prune` removes local copies of LFS files that are no longer referenced, but it runs after cloning and does not improve initial clone performance.

Practice this question →
12
MCQmedium

You are a DevOps consultant for a financial services company that is migrating from TFVC to Git. The existing TFVC repository has several branches: main, dev, feature branches, and release branches. The history is linear with no branching. The company requires that all future Git commits follow a strict naming convention: 'type(scope): description' (e.g., 'feat(api): add new endpoint'). They also want to prevent direct commits to the main branch; all changes must go through pull requests with at least one reviewer. Additionally, they want to ensure that each commit message is validated before it is merged. The team is small (5 developers) and they want a simple setup without complex tooling. Which approach should you recommend?

A.Create a build pipeline that validates commit messages and fails the build if invalid
B.Use a server-side pre-receive hook in the Git repository
C.Install a client-side pre-commit hook on each developer's machine to validate messages
D.Configure branch policies on the main branch: require a minimum of one reviewer, and add a status check that runs a script to validate the commit message format
AnswerD

Server-side enforcement with minimal overhead.

Why this answer

Option D is correct because Azure Repos branch policies allow you to enforce pull request requirements (e.g., minimum number of reviewers) and require a status check that runs a custom script to validate commit message format. This ensures all commits merged into main comply with the naming convention and review policy without complex tooling, fitting the small team's need for a simple, server-side enforcement mechanism.

Exam trap

The trap here is that candidates often confuse client-side hooks (option C) with server-side enforcement, not realizing that client-side hooks are optional and easily bypassed, whereas Azure Repos branch policies (option D) provide mandatory, centralized enforcement without requiring custom server-side hook infrastructure.

How to eliminate wrong answers

Option A is wrong because a build pipeline that validates commit messages runs after the code is already merged (or during a PR build), but it does not prevent direct commits to main or enforce the review requirement; it only fails the build, not the merge. Option B is wrong because server-side pre-receive hooks are not natively supported in Azure Repos (they are available in on-premises Git servers like GitHub Enterprise or self-hosted GitLab); Azure Repos uses branch policies instead. Option C is wrong because client-side pre-commit hooks are not enforceable; developers can bypass them by using --no-verify or by not installing the hook, so they do not guarantee compliance across the team.

Practice this question →
13
MCQmedium

A team uses a monorepo in Azure Repos. They want to implement a build validation policy that only triggers builds for code changes in specific folders to reduce build times. Which approach should they use?

A.Use a manual trigger and have developers specify which folder to build.
B.Create separate YAML pipelines for each folder and configure branch policies to require all pipelines.
C.Configure the build policy in Azure Repos with a path filter to limit which folders trigger the policy.
D.Configure path filters in the pipeline trigger to include only the changed folder.
AnswerD

Path filters restrict when the pipeline runs based on changed paths.

Why this answer

Option D is correct because Azure Pipelines supports path filters in the pipeline trigger configuration (using the `paths` keyword in YAML). This allows you to specify include and exclude patterns so that the pipeline only triggers when changes are made to specific folders within the monorepo. This directly reduces unnecessary builds and aligns with the requirement to limit builds to code changes in specific folders.

Exam trap

The trap here is that candidates confuse branch policy path filters (which do not exist in Azure Repos) with pipeline trigger path filters, leading them to incorrectly select Option C.

How to eliminate wrong answers

Option A is wrong because a manual trigger defeats the purpose of an automated build validation policy; it relies on developers remembering to trigger builds, which is error-prone and not scalable. Option B is wrong because requiring all separate pipelines via branch policies would cause every pipeline to run on any change, negating the goal of reducing build times and creating unnecessary overhead. Option C is wrong because Azure Repos branch policies do not support path filters for build validation; path filters are a feature of pipeline triggers, not branch policy configuration.

Practice this question →
14
MCQeasy

A developer accidentally committed a sensitive password to a Git repository. The commit has already been pushed to the remote. What is the first step to remediate the situation?

A.Delete the file from the repository and commit the deletion
B.Remove the password from the file, amend the commit, and force push
C.Revert the commit that introduced the password
D.Immediately notify the security team and rotate the password
AnswerB

Amending removes the password from the commit and force push updates the remote.

Why this answer

Option B is correct because the password has already been pushed to the remote, meaning it exists in the commit history. Simply deleting the file or reverting the commit does not remove the password from the Git history; anyone with access to the repository can still retrieve it. The proper first step is to remove the password from the file, amend the commit (using `git commit --amend`), and force push (`git push --force`) to overwrite the remote history, effectively erasing the sensitive data from the branch.

Exam trap

The trap here is that candidates confuse 'reverting' (which adds a new commit) with 'removing from history' (which requires amending or interactive rebase and force push), leading them to choose Option C as a safe alternative.

How to eliminate wrong answers

Option A is wrong because deleting the file and committing the deletion leaves the password in the previous commit history, which is still accessible via `git log` and `git checkout`. Option C is wrong because reverting the commit creates a new commit that undoes the changes but does not remove the original commit from history; the password remains in the reverted commit. Option D is wrong because while notifying the security team and rotating the password is a critical follow-up step, it is not the first technical step to remediate the Git history; the immediate priority is to remove the password from the remote repository to prevent further exposure.

Practice this question →
15
MCQhard

Refer to the exhibit. A developer attempts to push a commit directly to the main branch of FabrikamWeb repository but receives a push rejection. What is the most likely reason?

A.The developer tried to push to the wrong remote URL.
B.The FabrikamWeb repository has a minimum number of reviewers policy set to 1, which blocks direct pushes.
C.The developer does not have permission to push to the main branch due to branch policies requiring pull requests.
D.The main branch does not exist in the FabrikamWeb repository.
AnswerC

Branch policies on main typically enforce that all changes must go through pull requests and be reviewed.

Why this answer

The repository FabrikamWeb has a default branch 'develop', and the merge strategy policy may require that all changes be made via pull requests. Also, the absence of a policy on main branch suggests that main is protected by branch policies that are not listed because the query was for the develop branch. However, the question is about pushing to main.

Given the exhibit shows policies for the repository, but not specifically for main branch, the most likely cause is that the branch policies are set on the default branch (develop) and maybe also on main, but the push rejection could be due to a branch policy requiring pull requests. However, the correct answer is that the main branch is protected by a branch policy that requires pull requests, which is a common setting.

Practice this question →
16
Multi-Selecteasy

Which TWO are valid Git merge strategies available in Azure Repos pull requests?

Select 2 answers
A.Semi-linear merge
B.Merge commit (no fast-forward)
C.Fast-forward only
D.Squash merge
E.Rebase only
AnswersA, B

Rebases commits onto target then creates a merge commit.

Why this answer

Azure Repos pull requests offer three merge strategies: 'Merge commit (no fast-forward)', 'Semi-linear merge', and 'Squash merge'. 'Semi-linear merge' (Option A) creates a merge commit but ensures the source branch is rebased onto the target branch first, resulting in a linear history with a merge commit. 'Merge commit (no fast-forward)' (Option B) creates a merge commit that preserves the full history of both branches without any rebasing.

Exam trap

The trap here is that candidates often confuse the available merge strategies in Azure Repos with those in other Git hosting platforms (like GitHub or GitLab), or they mistakenly think 'Fast-forward only' and 'Rebase only' are separate strategies when they are actually sub-behaviors or not offered at all.

Practice this question →
17
MCQhard

A development team uses a forking workflow in Azure Repos. They want to ensure that only specific users can create forks of the main repository. How can they achieve this?

A.Use branch security to restrict who can create forks
B.Set branch policies on the main branch to prevent forks
C.Configure the repository to disable forks globally
D.Remove the 'Create Fork' permission from all users except the required group
AnswerA

Under repository settings, you can set security by group for 'Create Fork' permission.

Why this answer

In Azure Repos, the ability to create forks is controlled by a specific permission called 'Create Fork' at the repository level. By default, all contributors have this permission. To restrict fork creation to only specific users, you must remove the 'Create Fork' permission from all users and groups, then explicitly grant it only to the desired group or individuals.

This is a permission-based security model, not a branch policy or global toggle.

Exam trap

The trap here is that candidates often confuse branch policies (which control branch-specific actions like pull requests) with repository-level permissions (which control actions like creating forks), leading them to incorrectly select branch security or branch policies as the solution.

How to eliminate wrong answers

Option A is correct because it directly addresses the permission control needed. Option B is wrong because branch policies on the main branch (e.g., requiring pull request reviews) do not control who can create forks; they only enforce rules on commits and merges to that branch. Option C is wrong because Azure Repos does not have a global 'disable forks' setting; fork creation is controlled per-repository via permissions.

Option D is wrong because 'Create Fork' is not a permission that can be removed from users; it is a permission that must be explicitly denied or granted, and the correct approach is to remove the permission from all users and grant it only to the required group.

Practice this question →
18
MCQhard

Refer to the exhibit. A developer is working on the feature/login branch and wants to ensure that the latest changes from main are incorporated before creating a pull request. Which command should the developer run next?

A.git rebase --abort
B.git merge main
C.git push origin feature/login
D.git pull --rebase origin main
AnswerD

This fetches the latest main and rebases the feature branch onto it, incorporating the latest changes and keeping history linear.

Why this answer

The exhibit shows that the feature/login branch has a merge commit from main (3a1b2c3) which means main was already merged into feature/login. However, the local branch is ahead of origin by 1 commit (the merge commit). The developer wants to incorporate the latest changes from main.

Since main has advanced (d4e5f6a is the latest on origin/main), the developer should pull the latest main and rebase or merge again. The best practice is to rebase onto the latest main to maintain a linear history. Therefore, the developer should run 'git pull --rebase origin main' to fetch and rebase.

Practice this question →
19
Drag & Dropmedium

Drag and drop the steps to set up a continuous integration pipeline in Azure Pipelines into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

The pipeline setup starts with creation, then source selection, trigger configuration, task addition, and finally validation.

Practice this question →
20
MCQhard

Refer to the exhibit. A team wants to release version 1.0 from the main branch. They notice that the tag v1.0 is already on the current main commit. However, they also see that the origin/feature/experiment branch has commits that are not merged into main. What is the most likely scenario?

A.The team should delete the experiment branch because it is not merged.
B.The tag v1.0 was applied to the wrong commit; it should be on the merge commit of the experiment branch.
C.The main branch is missing the experiment branch commits; a merge is required before release.
D.The experiment branch contains experimental work that was not intended for release; the tag v1.0 correctly marks the release on main.
AnswerD

The experiment branch is separate and its commits are not part of main, so they are not included in the release.

Why this answer

The tag v1.0 is on the current main commit (9a8b7c6). The feature/experiment branch (1a2b3c4) is a child of the initial commit, but it is not merged into main. The main branch has commits that are ahead of the experiment branch.

The team wants to release v1.0 from main; the tag already exists. The presence of the experiment branch not merged suggests that it was not intended for this release. The most likely scenario is that the experiment branch was created from an older commit and is not ready for release, so it was not merged.

The release v1.0 is correctly tagged on main.

Practice this question →
21
MCQmedium

A team is migrating from TFVC to Git. They have a large codebase with many branches. What is the recommended approach to preserve the history during migration?

A.Copy the latest version of the code to a new Git repository and start fresh
B.Use the Git-TF tool to clone the TFVC repository
C.Use the git-tfs tool to clone the TFVC repository with changesets
D.Export TFVC as a Git bundle and import with --no-metadata
AnswerC

git-tfs converts TFVC changesets into Git commits preserving history.

Why this answer

Option C is correct because git-tfs is a specialized bridge tool that converts TFVC changesets into Git commits, preserving the full history, author information, and branch structure during migration. Unlike Git-TF, which is deprecated and lacks support for newer TFVC features, git-tfs handles complex scenarios like merges and shelvesets, making it the recommended approach for preserving history when moving from TFVC to Git.

Exam trap

The trap here is that candidates confuse Git-TF with git-tfs, assuming both are equivalent, but Git-TF is deprecated and lacks branch support, while git-tfs is the actively maintained tool for full history preservation.

How to eliminate wrong answers

Option A is wrong because copying only the latest version discards all historical changesets, defeating the purpose of preserving history and losing audit trail and rollback capability. Option B is wrong because Git-TF (Git-TF) is a deprecated tool that does not support TFVC branches or shelvesets, and its last update was in 2015, making it unsuitable for modern TFVC repositories. Option D is wrong because TFVC does not natively support Git bundle export; the `--no-metadata` flag is irrelevant as TFVC changesets cannot be directly converted to Git bundles without a bridge tool like git-tfs.

Practice this question →
22
MCQeasy

Your team manages a large monorepo in Azure Repos containing multiple projects. Developers frequently complain that cloning the entire repository takes too long and that they only need a subset of the code. The team uses Git LFS for large binary files. The repository currently has 50,000 commits and is 5 GB in size. You want to improve clone performance without sacrificing the ability to contribute to any part of the repo. What should you do?

A.Configure sparse checkout so developers can clone only the directories they need.
B.Instruct developers to use a shallow clone with depth 1 to reduce clone time.
C.Move all large binary files to Git LFS to reduce repository size.
D.Split the monorepo into multiple repositories and use submodules to aggregate them.
AnswerA

Sparse checkout allows cloning a subset of files, dramatically reducing clone time and disk usage.

Why this answer

Sparse checkout allows developers to clone only the specific directories they need from the monorepo, significantly reducing the amount of data transferred and stored locally. Since the team already uses Git LFS for large binaries, the primary bottleneck is the sheer size of the full commit history and working tree. Sparse checkout, combined with a shallow clone if needed, directly addresses the complaint without breaking the ability to contribute to any part of the repo.

Exam trap

The trap here is that candidates often confuse sparse checkout with shallow clone, thinking that reducing commit history alone solves the problem, when in fact the working tree size is the primary bottleneck for developers who only need a subset of code.

How to eliminate wrong answers

Option B is wrong because a shallow clone with depth 1 reduces the commit history but still downloads the full working tree for all projects, which is 5 GB; it does not solve the problem of needing only a subset of code. Option C is wrong because the team already uses Git LFS for large binary files, so moving files to LFS again would not further reduce repository size or improve clone performance. Option D is wrong because splitting the monorepo into multiple repositories with submodules introduces significant overhead in managing cross-repo dependencies, breaks the monorepo workflow, and does not guarantee faster clones for developers who still need multiple submodules.

Practice this question →
23
Multi-Selectmedium

A development team uses Git for source control. They want to enforce a branching strategy where all feature work is done in short-lived branches that are merged to main via pull requests. The team also requires that every commit on main builds successfully. Which TWO practices should the team implement?

Select 2 answers
A.Configure a branch policy on main that requires a successful build before merging.
B.Use squash merge when completing pull requests to main.
C.Require at least one approver on all pull requests targeting main.
D.Create feature branches from main and keep them long-lived for stability.
E.Allow developers to commit directly to main for urgent fixes.
AnswersA, C

Ensures every commit to main has passed build validation.

Why this answer

Option A is correct because configuring a branch policy on main that requires a successful build before merging ensures that every commit merged into main has passed a validation build. This enforces the team's requirement that every commit on main builds successfully, as the pull request cannot be completed until the build pipeline reports success.

Exam trap

The trap here is that candidates often confuse squash merge (which simplifies history) with a practice that ensures build success, or they mistakenly think allowing direct commits for urgent fixes is acceptable when the requirement explicitly demands every commit on main builds successfully.

Practice this question →
24
Matchingmedium

Match each Azure Artifacts feed type to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Accessible to all projects in the organization

Accessible only within a specific project

Caches packages from external sources like NuGet.org

Filters packages by release status (e.g., prerelease)

Why these pairings

Feed types and features in Azure Artifacts.

Practice this question →
25
MCQhard

A development team is using Git for source control. They have a main branch that should always be deployable. Developers work on feature branches and create pull requests to merge into main. Recently, a feature branch with incomplete work was accidentally merged into main, causing build failures. What is the best Git branch strategy to prevent this in the future while maintaining fast feedback?

A.Require at least one code reviewer approval for all pull requests into main.
B.Configure branch protection on main to require status checks (CI build and tests) to pass before merging.
C.Adopt a GitFlow-like branching model with a separate release branch for stable code.
D.Disable direct pushes to main and enforce all merges through pull requests.
E.Require a linear history on main by enabling 'Rebase and merge' for all pull requests.
AnswerB

This ensures that only branches with passing builds and tests can be merged into main.

Why this answer

Option B is correct because configuring branch protection on main to require status checks (CI build and tests) to pass before merging directly prevents incomplete or broken code from being merged. This enforces that every pull request must pass automated validation, ensuring main remains deployable while still allowing fast feedback through the CI pipeline.

Exam trap

The trap here is that candidates often confuse process controls (like requiring pull requests or code reviews) with automated quality gates (like status checks), mistakenly believing that human review alone is sufficient to catch all integration issues.

How to eliminate wrong answers

Option A is wrong because requiring code reviewer approval alone does not prevent incomplete or broken code from being merged; reviewers may miss issues or approve without running builds. Option C is wrong because adopting GitFlow with a separate release branch adds complexity and delays feedback, contradicting the need for fast feedback and not directly preventing accidental merges of incomplete work. Option D is wrong because disabling direct pushes and enforcing merges through pull requests is a prerequisite but does not enforce that the code is complete or passes validation; it only controls the merge mechanism.

Option E is wrong because requiring a linear history via 'Rebase and merge' only affects commit history structure, not the quality or completeness of the code being merged.

Practice this question →
26
MCQhard

An organization uses Azure Repos with multiple Git repositories. They want to enforce that all commits to the main branch are signed using GPG keys. Which combination of actions is required to enforce commit signing?

A.Configure branch policy to require signed commits and have developers add their SSH public key to Azure Repos.
B.Configure repository settings to require a personal access token (PAT) for each commit.
C.Configure branch policy to require signed commits and have developers configure Git to sign commits with their GPG key.
D.Use Azure Key Vault to store signing keys and configure Azure Repos to automatically sign commits.
AnswerC

Branch policy enforces signing, and GPG key configuration enables signing locally.

Why this answer

Option C is correct because Azure Repos supports a branch policy that requires commits to be signed, and developers must configure Git to sign commits with their GPG key using `git config --global user.signingkey` and `git commit -S`. This ensures that only signed commits are accepted into the main branch, enforcing non-repudiation and integrity.

Exam trap

The trap here is confusing authentication methods (SSH keys, PATs) with commit signing (GPG keys), leading candidates to select options that address access control rather than cryptographic integrity.

How to eliminate wrong answers

Option A is wrong because SSH public keys are used for authentication, not for signing commits; commit signing requires GPG keys, not SSH keys. Option B is wrong because a personal access token (PAT) is used for authentication to Azure Repos, not for signing commits; it does not enforce cryptographic signing. Option D is wrong because Azure Key Vault can store keys but Azure Repos does not automatically sign commits; signing must be performed client-side by the developer using Git.

Practice this question →
27
Drag & Dropmedium

Drag and drop the steps to troubleshoot a failed Azure DevOps release pipeline into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

Troubleshooting starts with logs, then task identification, variable check, debug run, and fix.

Practice this question →
28
MCQeasy

A team uses a monorepo with multiple projects in one Git repository. They want to enforce that each commit message must reference a work item from Azure Boards. Which branch policy should they configure?

A.Automatically include work items in pull request descriptions
B.Require a work item linking policy in branch policies
C.Configure a minimum number of reviewers policy
D.Use a build validation policy to check commit messages
AnswerB

This policy enforces that every pull request has at least one linked work item.

Why this answer

The 'Require a work item linking policy' in Azure Repos branch policies enforces that every pull request must be associated with at least one Azure Boards work item before it can be completed. This policy directly meets the requirement to ensure each commit message references a work item, as the linking is validated at merge time.

Exam trap

The trap here is that candidates often confuse 'commit message validation' with 'pull request work item linking', assuming a build validation or custom script is needed, when Azure Repos provides a native branch policy specifically for enforcing work item association.

How to eliminate wrong answers

Option A is wrong because automatically including work items in pull request descriptions only adds work item links to the description text, but does not enforce that every commit message must reference a work item. Option C is wrong because a minimum number of reviewers policy controls who must approve the pull request, not the content of commit messages or work item references. Option D is wrong because a build validation policy runs a build pipeline to validate code quality or tests, but it cannot inspect or enforce commit message content for work item references without custom scripting, and it is not the native policy designed for this purpose.

Practice this question →
29
MCQeasy

A team uses Git for source control. They want to automatically squash all commits in a feature branch into a single commit when merging to the main branch. Which merge type should they use?

A.Rebase and fast-forward
B.Squash commit
C.Merge commit (no fast-forward)
D.Semi-linear merge
AnswerB

Combines all changes into a single commit on target branch.

Why this answer

B is correct because the squash commit merge type collapses all commits in a feature branch into a single new commit on the target branch. This satisfies the requirement to automatically squash all commits when merging to main, as it creates a clean, linear history with one combined commit that contains all changes from the feature branch.

Exam trap

The trap here is that candidates often confuse 'squash commit' with 'rebase and fast-forward' because both can produce a linear history, but only squash commit collapses multiple commits into one.

How to eliminate wrong answers

Option A is wrong because rebase and fast-forward replays each individual commit from the feature branch onto the tip of main, preserving the full commit history rather than squashing them into one. Option C is wrong because merge commit (no fast-forward) creates a merge commit that preserves all individual commits from the feature branch, resulting in a non-linear history with multiple commits. Option D is wrong because semi-linear merge (also called rebase merge) first rebases the feature branch onto main and then creates a merge commit, but still retains all original commits from the feature branch instead of squashing them.

Practice this question →
30
Multi-Selecthard

Which THREE are benefits of using a monorepo vs multiple repositories?

Select 3 answers
A.Easier code sharing and refactoring across projects
B.Reduced risk of configuration drift
C.Simplified dependency management across projects
D.Faster clone times due to smaller repository size
E.Atomic commits that span multiple components
AnswersA, C, E

Shared code is in the same repo, simplifying updates.

Why this answer

Option A is correct because a monorepo enables easier code sharing and refactoring across projects by allowing all code to reside in a single repository. This eliminates the need for cross-repository package publishing or versioning, as shared libraries can be directly referenced and refactored atomically across all dependent projects within the same commit.

Exam trap

The trap here is that candidates often confuse 'reduced configuration drift' (Option B) with the benefits of centralized configuration management, but in a monorepo, configuration drift can still occur if teams modify shared files inconsistently, and the exam expects you to recognize that this is not an inherent benefit.

Practice this question →
31
MCQmedium

A company has a policy that all code changes must be reviewed by at least two people. However, for urgent bug fixes, they want to allow a single reviewer. How should they configure the branch policy?

A.Set minimum number of reviewers to 1 and require a separate approval from a manager
B.Set minimum number of reviewers to 2 and allow resetting code review votes on new pushes
C.Configure a build validation policy that checks number of approvals
D.Set minimum number of reviewers to 2, but allow policy override for urgent fixes
AnswerD

Policy override can be used with a justification to bypass the two-reviewer requirement.

Why this answer

Option D is correct because Azure Repos branch policies allow you to set a minimum number of reviewers (e.g., 2) and then enable the 'Allow policy override' setting for urgent fixes. This lets authorized users bypass the two-reviewer requirement for critical bug fixes while maintaining the default policy for normal changes.

Exam trap

The trap here is that candidates often confuse 'policy override' with 'bypassing all policies' or think a build validation can count approvals, when in fact Azure Repos requires explicit permission-based override settings for urgent scenarios.

How to eliminate wrong answers

Option A is wrong because setting the minimum number of reviewers to 1 does not enforce the two-reviewer policy, and requiring a separate manager approval does not address the urgent fix scenario—it adds an extra approval step instead of allowing a single reviewer. Option B is wrong because setting minimum reviewers to 2 and allowing resetting votes on new pushes does not provide a mechanism to bypass the two-reviewer requirement for urgent fixes; it only resets approvals when new commits are pushed. Option C is wrong because a build validation policy checks build success, not the number of approvals; it cannot enforce or override reviewer count requirements.

Practice this question →
32
MCQmedium

Refer to the exhibit. A developer pushes a commit to a branch named 'feature/new-login'. Which of the following will occur?

A.The pipeline will trigger and run all steps because the branch name does not match any exclude pattern.
B.The pipeline will not trigger because the branch is excluded.
C.The pipeline will trigger only the restore and build steps, skipping tests.
D.The pipeline will trigger but fail with an error because the branch is not in the include list.
AnswerB

The exclude pattern 'feature/*' prevents triggering on any branch starting with 'feature/'.

Why this answer

The trigger includes main and release/* branches, and explicitly excludes feature/* branches. Since 'feature/new-login' matches the exclude pattern 'feature/*', the pipeline will not trigger. The pipeline will only trigger for branches that match include patterns and do not match exclude patterns. 'feature/new-login' is excluded, so no build will start.

Practice this question →

Ready to test yourself?

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

Start 20-question session