AZ-400 Design and implement source control — 10 Questions

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