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

Question 1

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 2

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 3

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

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.

Question 6

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

Configure sparse checkout so developers can clone only the directories they need.. Sparse checkout allows developers to clone only the specific directories they need from the monorepo, significantly reducing the amount of data transferred and stored locally. Since the team already uses Git LFS for large binaries, the primary bottleneck is the sheer size of the full commit history and working tree. Sparse checkout, combined with a shallow clone if needed, directly addresses the complaint without breaking the ability to contribute to any part of the repo.

Answer

Instruct developers to use a shallow clone with depth 1 to reduce clone time.

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 7

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.. Option B is correct because 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 8

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.. Option D is correct because Git sparse checkout allows developers to clone only the specific directories they need for their microservice, reducing the amount of data transferred and stored locally, which directly addresses the slow clone/fetch issue. Additionally, path-based CI triggers in Azure Pipelines ensure that the CI pipeline only runs when files in the 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 9

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

Question 10

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

Question 11

Match each Git branching strategy to its description.

Question 12

Match each Azure Artifacts feed type to its description.

Question 13

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 repository FabrikamWeb has a default branch 'develop', and the merge strategy policy may require that all changes be made via pull requests. Also, the absence of a policy on main branch suggests that main is protected by branch policies that are not listed because the query was for the develop branch. However, the question is about pushing to main. Given the exhibit shows policies for the repository, but not specifically for main branch, the most likely cause is that the branch policies are set on the default branch (develop) and maybe also on main, but the push rejection could be due to a branch policy requiring pull requests. However, the correct answer is that the main branch is protected by a branch policy that requires pull requests, which is a common setting.

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 14

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

Question 15

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

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.