AZ-400 Design and implement source control Practice Test 1 — 15 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?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use a build validation policy to check commit messages. 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.

Answer

Automatically include work items in pull request descriptions

Answer

Require a work item linking policy in branch policies

Answer

Configure a minimum number of reviewers policy

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

Add a task in the CI pipeline that checks if the README was modified. 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.

Answer

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

Answer

Use a repository template with a mandatory README file structure

Answer

Require a pull request comment that confirms README update

Question 3

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

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

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

Accepted Answer

Use Git sparse checkout to clone only the folders needed for each microservice, and configure path-based CI triggers to run only when files in specific directories change.. Git sparse checkout allows developers to limit the working tree to specific directories, reducing local disk usage and checkout time. However, a standard sparse checkout alone does not reduce the amount of data downloaded during a full clone—this requires combining it with shallow or partial clone options. In Azure Pipelines, path-based CI triggers ensure pipelines run only when files in relevant directories change, reducing unnecessary builds and queue times. This approach improves both developer experience and CI efficiency without splitting the monorepo.

Answer

Configure shallow clone (depth=1) for all operations and disable CI triggers on feature branches.

Answer

Break the monorepo into multiple smaller repositories and use Git submodules to manage dependencies.

Answer

Implement Git Virtual File System (GVFS) for the repository and use CI triggers only on the main branch.

Question 6

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?

Accepted Answer

The developer does not have permission to push to the main branch due to branch policies requiring pull requests.. The developer's direct push to main was rejected because the main branch has an active branch policy that requires all changes to be introduced via pull requests. In Azure DevOps, any branch policy (such as 'Require a minimum number of reviewers' or 'Require pull request comments resolution') blocks direct pushes to that branch, even if the user has 'Contribute' permission. The exhibit likely shows branch policies applied to the main branch, which prevents direct pushes. An incorrect remote URL would typically result in a 'repository not found' error, and a non-existent branch would produce a different error. Therefore, the most likely reason is that branch policies on main require pull requests.

Answer

The developer tried to push to the wrong remote URL.

Answer

The FabrikamWeb repository has a minimum number of reviewers policy set to 1, which blocks direct pushes.

Answer

The main branch does not exist in the FabrikamWeb repository.

Question 7

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?

Accepted Answer

git pull --rebase origin main. The developer wants to incorporate the latest changes from main into the feature/login branch before creating a pull request. The command 'git pull --rebase origin main' fetches the latest changes from the remote main branch and rebases the current branch on top of them, resulting in a linear history. This is a common practice to keep the feature branch up to date and avoid merge commits.

Answer

git rebase --abort

Answer

git merge main

Answer

git push origin feature/login

Question 8

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

Accepted Answer

The pipeline will not trigger because the branch is excluded.. The pipeline will not trigger because the branch 'feature/new-login' matches an exclude pattern in the trigger configuration. In Azure Pipelines, branch filters can include exclude patterns that prevent the pipeline from running for certain branches. Since the branch is excluded, no pipeline run occurs.

Answer

The pipeline will trigger and run all steps because the branch name does not match any exclude pattern.

Answer

The pipeline will trigger only the restore and build steps, skipping tests.

Answer

The pipeline will trigger but fail with an error because the branch is not in the include list.

Question 9

Refer to the exhibit. A developer sees this error when running a YAML pipeline in Azure DevOps. What is the most likely cause?

Accepted Answer

The Azure DevOps organization has no available parallel jobs.. The pipeline error requires the exhibit to identify the exact message. Without it, none of the options can be confirmed as the most likely cause. The question should be revised or removed.

Answer

The pipeline agent pool is misconfigured.

Answer

The pipeline YAML file has a syntax error.

Answer

The Azure subscription is not linked to the Azure DevOps organization.

Question 10

You are a DevOps engineer at a company that uses Azure Repos Git. A security audit found that secrets were committed to the repository history. You need to remove the secrets from all past commits and prevent future pushes containing secrets. Which two actions should you perform? (Choose two.)

Accepted Answer

Run the git filter-repo command to rewrite history and remove the secret files, then force-push the rewritten history to Azure Repos.. Removing secrets from history requires rewriting commits with a tool such as git filter-repo and force-pushing the result, while preventing future leaks is achieved by enabling secret scanning push protection. Ignoring files, rotating secrets into variable groups, or adding reviewer policies do not purge history or automatically block pushes containing secrets.

Answer

Create a branch policy that requires a minimum number of reviewers on all branches.

Answer

Add the secret file paths to .gitignore and commit the change.

Answer

Rotate the exposed secrets and add them as secret variables in an Azure Pipelines variable group.

Question 11

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

Remove the 'Create Fork' permission from all users except the required group. 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.

Answer

Use branch security to restrict who can create forks

Answer

Set branch policies on the main branch to prevent forks

Answer

Configure the repository to disable forks globally

Question 12

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 13

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

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

Immediately notify the security team and rotate the password. 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.

Answer

Delete the file from the repository and commit the deletion

Answer

Remove the password from the file, amend the commit, and force push

Answer

Revert the commit that introduced the password

Question 15

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