AZ-400 Design and implement source control Practice Test 2 — 15 Questions

Question 1

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?

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

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

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

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

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

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 the build policy in Azure Repos with a path filter to limit which folders trigger the policy.. 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.

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 path filters in the pipeline trigger to include only the changed folder.

Question 6

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 7

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 8

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

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.

Question 9

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?

Accepted Answer

Instruct developers to use a shallow clone with depth 1 to reduce clone time.. 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.

Answer

Configure sparse checkout so developers can clone only the directories they need.

Answer

Move all large binary files to Git LFS to reduce repository size.

Answer

Split the monorepo into multiple repositories and use submodules to aggregate them.

Question 10

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?

Accepted Answer

Configure branch protection on main to require status checks (CI build and tests) to pass before merging.. 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.

Answer

Require at least one code reviewer approval for all pull requests into main.

Answer

Adopt a GitFlow-like branching model with a separate release branch for stable code.

Answer

Disable direct pushes to main and enforce all merges through pull requests.

Answer

Require a linear history on main by enabling 'Rebase and merge' for all pull requests.

Question 11

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

Accepted Answer

Create the pipeline, then select the source repository, then configure triggers, then add tasks, then validate the pipeline.. 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.

Answer

Create the pipeline, then configure triggers, then select the source repository, then add tasks, then validate the pipeline.

Answer

Create the pipeline, then add tasks, then select the source repository, then configure triggers, then validate the pipeline.

Answer

Select the source repository, then create the pipeline, then configure triggers, then add tasks, then validate the pipeline.

Question 12

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

Accepted Answer

Review pipeline logs, then identify the failing task, then check variable values and conditions, then run in debug mode, then apply a fix and retrigger. Troubleshooting starts with logs, then task identification, variable check, debug run, and fix.

Answer

Run in debug mode, then review pipeline logs, then identify the failing task, then check variable values and conditions, then apply a fix and retrigger

Answer

Identify the failing task, then check variable values and conditions, then run in debug mode, then review pipeline logs, then apply a fix and retrigger

Answer

Check variable values and conditions, then apply a fix and retrigger, then review pipeline logs, then identify the failing task, then run in debug mode

Question 13

Match each Git branching strategy to its description.

Accepted Answer

Git Flow: Uses develop and master branches with release branches.. 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.

Answer

Git Flow: Uses only main branch and feature branches.

Answer

GitHub Flow: Uses develop and release branches.

Question 14

Match each Azure Artifacts feed type to its description.

Accepted Answer

Project-scoped feed: A feed scoped to a specific project within an organization, accessible by members of that project.. 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.

Answer

Project-scoped feed: A feed scoped to the entire organization, accessible by all members.

Answer

Organization-scoped feed: A feed scoped to a specific project, accessible by project members.

Answer

Public feed: A feed that requires authentication from external users.

Question 15

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

Answer

git rebase --abort

Answer

git merge main

Answer

git push origin feature/login