AZ-400 Design and implement source control — All Questions With Answers

Question 1

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?

Accepted Answer

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

Answer

Automatically include work items in pull request descriptions

Answer

Configure a minimum number of reviewers policy

Answer

Use a build validation policy to check commit messages

Question 2

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?

Accepted Answer

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

Answer

Apply a label to PRs that touch certain files and require review

Answer

Add a task in the CI pipeline that checks if the README was modified

Answer

Require a pull request comment that confirms README update

Question 3

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?

Accepted Answer

Use branch security to restrict who can create forks. In Azure Repos, the ability to create forks is controlled by a specific permission called 'Create Fork' at the repository level. By default, all contributors have this permission. To restrict fork creation to only specific users, you must remove the 'Create Fork' permission from all users and groups, then explicitly grant it only to the desired group or individuals. This is a permission-based security model, not a branch policy or global toggle.

Answer

Set branch policies on the main branch to prevent forks

Answer

Configure the repository to disable forks globally

Answer

Remove the 'Create Fork' permission from all users except the required group

Question 4

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?

Accepted Answer

Squash commit. 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.

Answer

Rebase and fast-forward

Answer

Merge commit (no fast-forward)

Answer

Semi-linear merge

Question 5

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?

Accepted Answer

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

Answer

Set minimum number of reviewers to 1 and require a separate approval from a manager

Answer

Set minimum number of reviewers to 2 and allow resetting code review votes on new pushes

Answer

Configure a build validation policy that checks number of approvals

Question 6

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?

Accepted Answer

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

Answer

Use a shallow clone with depth 1

Answer

Use sparse checkout to limit files in working directory

Answer

Configure git lfs prune to run automatically

Question 7

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?

Accepted Answer

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

Answer

Delete the file from the repository and commit the deletion

Answer

Revert the commit that introduced the password

Answer

Immediately notify the security team and rotate the password

Question 8

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?

Accepted Answer

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

Answer

Copy the latest version of the code to a new Git repository and start fresh

Answer

Use the Git-TF tool to clone the TFVC repository

Answer

Export TFVC as a Git bundle and import with --no-metadata

Question 9

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

Accepted Answer

Status check. 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.

Answer

Comment requirements

Answer

Work item linking

Answer

Merge strategy

Question 10

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

Accepted Answer

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

Answer

Reduced risk of configuration drift

Answer

Faster clone times due to smaller repository size

Question 11

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

Accepted Answer

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

Answer

Fast-forward only

Answer

Squash merge

Answer

Rebase only

Question 12

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?

Accepted Answer

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

Answer

Keep separate repositories but create a meta-repo that references them as submodules

Answer

Keep separate repositories but use Git submodules to share code

Answer

Create a single monorepo with all services and a single build pipeline that builds everything

Question 13

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?

Accepted Answer

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

Answer

Create a build pipeline that validates commit messages and fails the build if invalid

Answer

Use a server-side pre-receive hook in the Git repository

Answer

Install a client-side pre-commit hook on each developer's machine to validate messages

Question 14

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?

Accepted Answer

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

Answer

Configure a branch policy that requires commit messages to follow a specific pattern.

Answer

Configure a branch policy that requires a successful build.

Answer

Configure a branch policy that requires linked work items.

Question 15

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?

Accepted Answer

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

Answer

Check out the latest version from TFVC, initialize a new Git repo, and push.

Answer

Use the Azure Repos import repository feature to import from TFVC.

Answer

Clone the TFVC repository using Git and push to Azure Repos.

Question 16

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?

Accepted Answer

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

Answer

Configure branch policy to require signed commits and have developers add their SSH public key to Azure Repos.

Answer

Configure repository settings to require a personal access token (PAT) for each commit.

Answer

Use Azure Key Vault to store signing keys and configure Azure Repos to automatically sign commits.

Question 17

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?

Accepted Answer

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

Answer

Use a manual trigger and have developers specify which folder to build.

Answer

Create separate YAML pipelines for each folder and configure branch policies to require all pipelines.

Answer

Configure the build policy in Azure Repos with a path filter to limit which folders trigger the policy.

Question 18

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

Accepted Answer

Use shallow clones in CI/CD pipelines.. 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.

Answer

Store large binary files directly in the repository.

Answer

Keep all branches indefinitely to preserve history.

Answer

Encourage developers to commit all changes in a single commit per day.

Question 19

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?

Accepted Answer

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

Answer

Configure a self-hosted agent with pre-installed dependencies and a larger disk for faster I/O.

Answer

Remove the code analysis step from feature branch builds and only run it on main branch builds.

Answer

Increase the agent VM size to a more powerful SKU for feature branch builds.

Question 20

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?

Accepted Answer

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

Answer

Use squash merge when completing pull requests to main.

Answer

Create feature branches from main and keep them long-lived for stability.

Answer

Allow developers to commit directly to main for urgent fixes.

AZ-400 Design and implement source control — All Questions With Answers

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?

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

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

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

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

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

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

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

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

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

Match each Git branching strategy to its description.

Match each Azure Artifacts feed type to its description.

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

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?

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

Exhibit

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?

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

AZ-400 Design and implement source control — All Questions With Answers

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?

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

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

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

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

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

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

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

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

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

Match each Git branching strategy to its description.

Match each Azure Artifacts feed type to its description.

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

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?

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

Exhibit

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?

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