Courseiva

CCNA Design and implement source control Questions

34 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
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 →
5
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
AnswerB

Adding a CI pipeline task that checks if the README was modified automatically verifies that any code changes are accompanied by a corresponding README update, ensuring the README remains accurate.

Why this answer

Adding a task in the CI pipeline that checks whether the README was modified directly enforces that developers include README updates in the same pull request that contains code changes. This ensures the README stays current with the codebase. In Azure Repos, CI pipelines can easily validate file changes using scripts or tasks.

Option C (repository template) only ensures a README exists for new repositories but does not enforce updates after initial creation, so it does not address the core issue of keeping the README up-to-date over time.

Exam trap

Candidates often choose repository templates because they enforce structure, but they miss that templates only apply at creation time. The real challenge is keeping the README current with ongoing changes, which requires automated enforcement in the CI/CD pipeline.

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 →
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 trigger includes branches matching 'main' and 'release/*'. 'release/v1' matches the wildcard 'release/*', so the pipeline in AppRepo will be triggered.

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

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

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 →
14
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 →
15
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 →
16
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 →
17
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 →
18
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 →
19
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 →
20
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
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 →
21
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 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 →
22
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 →
23
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 →
24
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 →
25
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 →
26
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

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 →
27
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 →
28
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
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 →
29
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
AnswerD

A build validation policy runs a configured pipeline (e.g., a script that greps commit messages) and can fail the build if a message lacks a work item ID, but this is an indirect, custom workaround. It does not natively enforce work item linking in the pull request metadata, is prone to bypass via malformed commit messages, and is not the designated Azure DevOps policy for this requirement.

Why this answer

The 'Require a work item linking policy' in Azure Repos ensures each pull request is linked to a work item, but it does not validate that each commit message contains a reference. To enforce that commit messages themselves reference an Azure Boards work item, a build validation policy can run a script to verify the commit message format. Therefore, option D is the correct choice.

Exam trap

Candidates may confuse the native work item linking policy with actual commit message validation. The work item linking policy only requires a PR-level link, not per-commit message references.

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 →
30
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 →
31
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 →
32
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 →
33
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 →
34
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 branch in question, e.g., 'feature/ex6lsa', falls under the exclude pattern 'feature/*', which indicates that any branch beginning with 'feature/' is excluded from triggering the pipeline. Therefore, pushing a commit to this branch will not start the pipeline, and no steps (restore, build, test) will execute. This is the expected behavior according to the branch filter configuration.

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