Courseiva

CCNA Design and implement source control Questions

31 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 branch policy enforces mandatory peer review by requiring at least a specified number of reviewers to approve the pull request, and also requires that all comment threads be resolved before merging. This ensures that code is reviewed by multiple team members before integration, directly serving the goal of ensuring peer review.

Why this answer

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

Refer to the exhibit. A developer pushes a new commit to an existing pull request targeting the main branch. What is the effect on the pull request?

A.The pull request is automatically merged.
B.The existing approvals remain valid, and no re-review is needed.
C.All existing approvals are revoked, and the pull request must be re-approved.
D.The new commit is rejected because it was pushed without a code review.
AnswerC

With the reset-approvals policy enabled, all previously granted approvals are revoked as soon as a new commit is pushed to the source branch, requiring reviewers to re-approve the latest changes before the pull request can be merged.

Why this answer

The policy 'Reset code reviewer votes when new changes are pushed' is set to true. Therefore, when a new commit is pushed, all previous reviewer votes are reset. The required number of reviewers is 2, but minimum is 1, so at least one reviewer must approve again.

Practice this question →
3
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 is a tool that bridges TFVC and Git, allowing you to clone a TFVC repository including all changesets, branches, and history, converting them into Git commits. After cloning, you push the local Git repository to Azure Repos as a new Git repository, preserving the full migration history. This is the recommended approach when you need to retain historical context.

Why this answer

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 →
4
MCQeasy

A team is using Azure Repos Git and wants to integrate their repository with Azure Boards so that they can create branches directly from work items and track commits and pull requests against those work items. What should they do?

A.Install the Azure Boards extension from the Visual Studio Marketplace and configure a service connection to the repository.
B.Create a YAML pipeline that uses the PublishWorkItem task to associate commits with work items.
C.Ensure the repository and the Azure Boards project are in the same Azure DevOps organization and project, then use work item links in commits and pull requests.
D.Enable the Boards integration from the repository settings by linking the repository to an Azure Boards project.
AnswerC

When a Git repository and an Azure Boards project are in the same Azure DevOps organization and project, the integration is active by default. Developers can reference work items with #ID syntax in commits and pull requests, and Azure Boards shows linked commits, branches, and pull requests without additional configuration. This satisfies the requirement out of the box.

Why this answer

Azure Repos and Azure Boards integrate automatically when they are in the same Azure DevOps organization and project. Developers can then use #ID references in commits and pull requests, create branches from work items, and view linked artifacts in Boards. No extension, service connection, or custom pipeline task is needed for this native integration.

Exam trap

The trap here is assuming that a marketplace extension or service connection must be installed to link Azure Repos with Azure Boards, when the integration is built in for repositories in the same organization and project.

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

Use `git clone --depth 1` or shallow fetch in CI/CD pipelines to retrieve only the most recent commit(s), drastically reducing clone time and disk usage since full history is rarely needed for build and test operations.

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

Status check is a valid branch policy in Azure Repos that requires an external service (e.g., SonarQube, Jenkins) to post a successful status to the PR before it can be completed. The policy defines a context name, and the service must report 'succeeded' via the Status API; otherwise, the PR is blocked. This enforces quality gates from CI/CD or analysis tools.

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

This allows atomic commits across services, while path filters in the pipeline trigger builds only for changed services, preserving build independence and reducing unnecessary builds. It provides the benefits of a monorepo without the cost of building everything.

Why this answer

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 →
8
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 ref refs/tags/v1.0-rc, which is the only operation performed; all other refs remain untouched. The repository still holds the tag ref refs/tags/v1.0, and the three branch refs (refs/heads/main, refs/heads/feature/new-feature, and refs/heads/feature/old-feature, as shown in the exhibit) are independent pointers under refs/heads. Because the tag deletion only removes that one ref under refs/tags, the net result is exactly one tag (v1.0) and three branches remaining.

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

Git branching strategies vary in complexity. Git Flow uses long-lived branches (develop, release), GitHub Flow is simple with feature branches to main, GitLab Flow adds environment branches, and trunk-based development centers on frequent commits to main. Common confusions involve swapping descriptions between Git Flow and GitHub Flow.

Practice this question →
10
MCQmedium

Refer to the exhibit. A developer is on the 'feature/login' branch and wants to integrate the latest changes from 'feature/user-profile' without creating a merge commit. Which Git command should the developer use?

A.git rebase origin/feature/user-profile
B.git pull --rebase origin main
C.git merge origin/feature/user-profile
D.git cherry-pick 9f8e7d6..8a7b6c5
AnswerA

git rebase origin/feature/user-profile is correct because it replays the unique commits from the current feature/login branch on top of the latest commits from origin/feature/user-profile, creating a linear history without a merge commit while preserving the login-specific changes.

Why this answer

To integrate changes from another branch without a merge commit, rebase is appropriate. The developer can rebase feature/login onto feature/user-profile (or onto main after merging user-profile). However, the exhibit shows that feature/user-profile is already merged into main, so rebasing feature/login onto main is also valid.

The simplest is to rebase feature/login onto main, but that would include all changes. Alternatively, rebasing feature/login onto feature/user-profile directly would also work, but since user-profile is merged into main, rebasing onto main is common. The correct answer is rebase.

Practice this question →
11
MCQhard

Refer to the exhibit. A pipeline in repository 'MyProject/AppRepo' is configured to trigger when changes are pushed to 'SharedRepo'. A developer pushes a commit to the 'release/v1' branch of 'SharedRepo'. What will happen?

A.The pipeline will trigger only if the commit also includes changes to 'main'.
B.The pipeline will fail because the trigger configuration is invalid.
C.The pipeline will trigger because 'release/v1' matches the 'release/*' include pattern.
D.The pipeline will not trigger because 'release/v1' is not explicitly listed.
AnswerC

The 'release/*' include pattern is a wildcard that matches any branch name beginning with 'release/' and containing any characters after the slash. Because 'release/v1' starts with 'release/', it matches the pattern, satisfying the branch trigger and causing the pipeline to trigger on that branch.

Why this answer

The pipeline's resource trigger uses a branch include pattern 'release/*', and 'release/v1' matches that wildcard, so the push triggers the pipeline. Azure Pipelines resource triggers evaluate the branch filter against the pushed branch name, and wildcard matching is supported. No explicit listing of 'release/v1' is required.

Exam trap

AZ-400 often tests whether candidates recognise that wildcard patterns like 'release/*' match without explicit branch listing — many assume every branch must be named individually.

How to eliminate wrong answers

Option A is wrong because the trigger is scoped to SharedRepo's branch pattern, not to changes in 'main' — there is no requirement that the commit also touch main. Option B is wrong because the trigger configuration is valid; wildcard patterns are supported in resource triggers. Option D is wrong because 'release/*' is a wildcard include, so 'release/v1' matches without being explicitly named.

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

Branch policies in Azure Repos provide server-side enforcement: requiring a minimum number of reviewers and adding a build validation status check that runs a script to validate commit message format ensures that every pull request to main must pass both human review and automated message validation before merging, which fully satisfies the requirement.

Why this answer

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.
AnswerC

Path filters in build validation policies affect only PR validation builds and do not control CI triggers. Additionally, the policy's path filter only determines whether the build is required for the PR; it does not prevent the pipeline from being triggered by other means. To limit builds to specific folders for all triggers, path filters should be configured in the pipeline trigger itself (as in option D).

Why this answer

Azure Repos build validation policies allow you to specify path filters when configuring the policy. These path filters restrict when the policy requires a build, based on the files changed in the pull request. By setting the path filter to the specific folders of interest, the build validation only triggers for changes in those folders, directly reducing build times for unrelated changes.

Pipeline trigger path filters (Option D) control CI builds on push, not the build validation policy for pull requests.

Exam trap

Candidates often confuse branch policy path filters with pipeline trigger path filters. Build validation policies are configured in Azure Repos branch policies and support path filters that apply specifically to pull request validations. Pipeline trigger path filters (in YAML) control when a pipeline runs on push CI, but they do not configure the build validation policy itself.

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
AnswerD

Rotating/revoking the password is a critical remediation step to prevent unauthorized use, but it does not remove the secret from source control. You must also purge the secret from Git history using tools like git filter-branch or git filter-repo, or by amending the commit as described, to fully eliminate the exposure.

Why this answer

Once a secret is pushed to a remote Git repository, it must be considered compromised because the commit may already be fetched by others, and old commits remain in reflogs and other clones. The first step is to immediately notify the security team and rotate/revoke the password to prevent unauthorized use. Only after the credential is invalidated should you attempt to remove it from Git history (e.g., by amending, rebasing, or using filter-repo) and force push, understanding that history rewriting may not fully eliminate all copies.

Exam trap

The trap is that candidates may focus on removing the secret from history rather than recognizing that the secret is already exposed. The correct first action is always to limit the damage by revoking or rotating the compromised credential.

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
Multi-Selecteasy

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

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

Semi-linear merge first rebases the source branch onto the latest target branch and then creates a merge commit, combining the benefits of a clean linear history with an explicit merge point. This strategy is valid in Azure Repos and is also known as 'rebasing before merging'.

Why this answer

Among the given options, the valid merge strategies are: 'Merge commit (no fast-forward)' (Option B), 'Semi-linear merge' (Option A), and 'Squash merge' (Option D). 'Merge commit (no fast-forward)' preserves the full history of both branches. 'Semi-linear merge' rebases the source branch onto the target before creating a merge commit, ensuring linear history. 'Squash merge' combines all source branch commits into a single commit on the target. Note that Azure Repos also supports 'Rebase and fast-forward' as a valid merge strategy, but it is not among the options. Options C and E are not valid merge strategies in Azure Repos pull requests.

Exam trap

Candidates often mistakenly believe that only two merge strategies are available or confuse 'Squash merge' as a non-strategy, but it is a valid completion option in Azure Repos.

Practice this question →
16
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
AnswerD

The 'Create Fork' permission is a repository-level security permission in Azure Repos, stored separately from branch permissions. To allow only a specific group to create forks, you remove the 'Create Fork' permission from all other users and groups (for example, Contributors and Readers) in the repository's Security page, then explicitly set it to 'Allow' for the required group. This is the only per-repository mechanism that enforces the requirement precisely, since it leaves fork creation available to the approved group while denying everyone else.

Why this answer

In Azure Repos, the ability to create forks is controlled by the 'Create Fork' permission, which is a repository-level permission, not a branch-level setting. By default, all contributors have this permission. To restrict fork creation to only specific users, navigate to the repository settings, go to Security (or Permissions), remove the 'Create Fork' permission from all users and groups, then explicitly grant it only to the desired group or individuals.

Therefore, the correct answer is D: remove the 'Create Fork' permission from all users except the required group.

Exam trap

The trap is that candidates often confuse repository-level permissions with branch-level settings. They may think 'branch security' controls fork creation because both involve permissions, but fork creation is managed at the repository level, not the branch level.

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 →
17
Drag & Dropmedium

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

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The correct order for setting up a continuous integration pipeline in Azure Pipelines is: first create the pipeline, then select the source repository (e.g., Azure Repos or GitHub), then configure triggers (e.g., on commit or PR), then add tasks (build, test, etc.), and finally validate the pipeline by running it. This sequence is reflected in option A. Starting with source selection or adding tasks before creation is incorrect.

Practice this question →
18
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 was created for isolated, exploratory work and has intentionally never been merged into main, so none of its commits are part of the v1.0 release history. Tagging the main branch's commit correctly captures the exact state of the code that was built, tested, and validated for release. This is consistent with standard branching practices where release tags are applied to integration branches, not to feature or experiment branches.

Why this answer

The tag v1.0 sits on the current main commit, and the experiment branch has unmerged commits — this is the normal, expected state when experimental work is intentionally kept out of a release. Tags mark specific commits as release points; they do not require every branch to be merged. The most likely scenario is that the experiment branch is exploratory work not destined for v1.0, so the tag correctly identifies the release commit on main.

Exam trap

AZ-400 often tests the misconception that an unmerged branch must be merged before a release can be tagged, confusing branch hygiene with release tagging — candidates wrongly assume the tag is misplaced rather than recognizing parallel experimental work.

How to eliminate wrong answers

Option A is wrong because deleting an unmerged branch is a destructive action with no technical justification — unmerged branches are routinely kept for ongoing or abandoned experiments, and deletion is a policy decision, not a diagnosis of the tag's placement. Option B is wrong because it assumes the tag must be on a merge commit of the experiment branch, but tags mark release points on whatever commit represents the release; there is no rule requiring experimental branches to be merged before tagging. Option C is wrong because it assumes the experiment branch commits belong in the release, but the scenario gives no evidence they were intended for v1.0 — merging unvetted experimental code would be the actual mistake.

Practice this question →
19
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 is the standard community-maintained bridge that clones a TFVC repository by replaying each TFVC changeset into a corresponding Git commit, preserving the original author, timestamp, commit message, branch structure, and merge topology. It handles the TFVC-to-Git ID mapping and can also fetch shelvesets, making it the preferred tool for a full-fidelity migration. Because it reconstructs the entire commit graph rather than just copying files, it maintains the historical context needed for auditing, bisecting, and code review — which is exactly what the team needs when moving from TFVC to Git.

Why this answer

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 →
20
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.
AnswerB

A shallow clone with `depth 1` retrieves only the latest commit from each branch, omitting the entire commit history and all historical tree and blob objects that are not reachable from that tip. This can shrink the clone payload from many gigabytes to just the snapshot of the latest revision, dramatically cutting clone time. Developers who need older history can later run `git fetch --unshallow` or `git fetch --depth=N` to incrementally download additional commits, and the clone remains a normal repository capable of receiving changes to any part of the monorepo.

Why this answer

Using a shallow clone with depth 1 significantly reduces clone time by fetching only the latest commit history instead of all 50,000 commits. This minimizes the data transferred over the network, which is the primary cause of slow clones. Developers can later deepen the clone if they need more history.

Sparse checkout alone does not reduce the data transferred during clone; it only limits what appears in the working directory. Git LFS is already being used for large binaries, so that is not the issue. Splitting the monorepo would require significant restructuring and may complicate cross-project contributions.

Exam trap

The trap is that candidates may think sparse checkout alone speeds up cloning, but it only affects the working directory after all objects are downloaded. Shallow clone directly reduces the amount of history and data transferred, which is the key factor in clone time.

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

Establishing a branch policy on main that requires a successful build before merging ensures that every pull request targeting main must pass a defined build pipeline as a mandatory gate. Azure DevOps blocks the merge until the build succeeds, preventing broken code from integrating into main and enforcing continuous integration at the point of merge.

Why this answer

Option A configures a branch policy on main that requires a successful build before merging, directly ensuring every commit on main has passed a build. Option C requires at least one approver on all pull requests targeting main, which enforces the code review process as part of the pull request workflow, a key practice for maintaining a healthy branching strategy with short-lived feature branches. Together, these two practices enforce both the build-success requirement and the pull-request-based workflow.

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

In Azure Artifacts, project-scoped feeds are limited to a specific project, organization-scoped feeds are available to the entire org, and public feeds allow anonymous access. Common confusions arise from swapping the scope of project and org feeds, or misstating public feed authentication requirements.

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

Branch protection blocks merges to main until required status checks — the CI build and tests — pass, so incomplete feature work cannot land and break the deployable main. This directly prevents the accidental merge while keeping fast feedback through pull requests.

Why this answer

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 →
24
MCQmedium

A development team uses Azure Repos Git. They need to ensure that every commit pushed to the main branch includes a valid work item link, but they do not want to block developers from pushing to feature branches. What should they configure?

A.A required reviewer policy on main that assigns a specific team.
B.A branch policy on main that checks for linked work items.
C.A repository-level policy that requires all commits to be signed.
D.A branch policy on main that requires a minimum number of reviewers.
AnswerB

The linked work items policy on the main branch requires that every commit or pull request targeting main be associated with at least one Azure Boards work item. Feature branches remain unaffected because the policy is scoped only to main, so developers can push freely to feature branches while main stays compliant.

Why this answer

The linked work items branch policy on main enforces that commits or pull requests targeting main are associated with at least one work item, while leaving feature branches unrestricted. Reviewer count, commit signing, and required reviewer policies address different concerns and do not enforce work item linkage.

Exam trap

The trap here is confusing approval-related policies such as minimum reviewers or required reviewers with the linked work items policy that specifically validates work item association.

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

Azure Repos branch policies can enforce that every commit in a protected branch is signed, and developers must configure their local Git client to sign commits with a GPG key (e.g., set user.signingkey and commit.gpgsign=true). When a developer pushes a signed commit, Azure Repos verifies the GPG signature against the developer's configured public key, while the private key remains securely on the developer's machine.

Why this answer

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 →
26
Drag & Dropmedium

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

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

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

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

Squash commit is correct because it merges the feature branch by combining all of its changes into a single new commit on the target branch. This collapses the entire commit history of the feature into one commit, exactly matching the requirement to combine all changes into a single commit.

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 →
28
MCQhard

Refer to the exhibit. A developer runs the pipeline on a branch called 'feature/abc'. What will happen?

A.The pipeline will fail with a syntax error.
B.Only the Build stage will execute.
C.Both stages will execute.
D.The Deploy stage will run but skip the steps.
AnswerB

Only the Build stage will execute because the Build stage has no condition (or an unconditional condition), so it runs on every branch. The Deploy stage has a condition that restricts it to the main branch (e.g., eq(variables['Build.SourceBranch'], 'refs/heads/main')), which evaluates to false on the o50p branch, causing the entire Deploy stage to be skipped.

Why this answer

The 'Deploy' stage has a condition that checks if the source branch is 'refs/heads/main'. Since the branch is 'feature/abc', the condition evaluates to false, so the Deploy stage will be skipped. The Build stage runs regardless.

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

Because all code resides in a single repository, projects can directly import shared libraries without separately publishing and versioning them. This enables large-scale refactoring, such as changing an API signature, to be done in one atomic change that immediately affects all consuming projects, greatly simplifying coordination.

Why this answer

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 →
30
MCQhard

You are an Azure DevOps engineer at a software company that uses a single Azure Repos Git repository for a product with two independent release trains: a web front end and a backend API. You need to enforce that pull requests targeting the release branch for each train require approval from a different set of reviewers, and you must be able to report on policy compliance separately for each train. What should you configure?

A.Enable required reviewers on each release branch individually using the branch name, and assign the appropriate reviewer group to each policy.
B.Configure a single required reviewer policy on the main branch and rely on branch hierarchy inheritance to apply it to the release branches.
C.Create a path-based required reviewer policy on the folders that contain the web and API source code.
D.Create a branch policy on the release/* wildcard path with a required reviewer group that contains all reviewers for both trains.
AnswerA

Configuring a separate required-reviewer policy on each specific release branch lets you attach the correct reviewer group to the web train and a different group to the API train. Because each branch has its own policy object, Azure DevOps reports policy status and compliance independently for each branch, satisfying both the approval and reporting requirements without affecting unrelated branches.

Why this answer

Separate required-reviewer policies on each specific release branch allow different reviewer groups to be assigned to the web and API trains while keeping policy status and compliance reporting distinct per branch. Wildcard policies, path-based policies, and main-branch policies all fail to scope the approval requirement to each release train independently.

Exam trap

The trap here is assuming that a wildcard branch policy on release/* or a path-based policy can enforce different reviewer groups per branch, when only per-branch policies provide that separation.

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

This allows the two-reviewer policy to be applied normally, while still permitting urgent fixes to be merged without two approvals; the override requires a justification and is logged for audit, balancing policy enforcement with operational flexibility.

Why this answer

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 →

Ready to test yourself?

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

Start 20-question session