Design and implement a source control strategy — AZ-400 Practice Quiz

Question 1

Your team uses Azure Repos with a protected 'main' branch. A branch policy requires a successful build validation before a pull request can complete. Developers complain that trivial documentation-only changes (Markdown files under a /docs folder) still trigger the full CI build, delaying their PRs. You must reduce unnecessary build runs for documentation-only changes while keeping the build validation policy enforced for all code changes. What should you configure?

Accepted Answer

Configure a path filter on the build validation policy to exclude the /docs folder.

Answer

Set the build validation policy to 'Optional' so developers can skip it for documentation PRs.

Answer

Add a path filter to the pipeline's CI trigger to exclude the /docs folder.

Answer

Grant developers the 'Bypass policies when completing pull requests' permission for documentation changes.

Question 2

Your team uses pull requests targeting the main branch in Azure Repos. A branch policy requires a minimum of two approvals. Reviewers frequently approve a PR, and then the author pushes additional commits that change the code substantially before merging. Auditors have flagged that approvals granted on earlier code are being carried forward to the final merged code. You must ensure that any new commit pushed to the source branch invalidates existing approvals so reviewers must re-review the latest changes. Which branch policy configuration should you enable?

Accepted Answer

Enable 'Reset code reviewer votes when there are new changes' on the Require a minimum number of reviewers policy

Answer

Enable 'Reset votes on last iteration only' under the Require linked work items policy

Answer

Add a 'Require a merge strategy' policy set to squash merge to consolidate commits

Answer

Enable 'Check for comment resolution' so all comments must be resolved before completion

Question 3

Your team uses Azure Repos with a pull-request workflow targeting the main branch. A third-party static analysis SaaS tool runs against every PR and posts results back to Azure DevOps by calling the Status API on the pull request. Leadership now requires that a PR cannot be completed unless this external tool reports a successful status, and the requirement must survive even if the tool is temporarily slow to respond. Which branch policy configuration meets this requirement?

Accepted Answer

Add a Status check branch policy on main referencing the external tool's status context and mark it as required.

Answer

Add a Build validation branch policy on main that queues the internal CI build pipeline.

Answer

Configure a required reviewer group that includes the service account used by the external tool.

Answer

Enable the 'Check for linked work items' policy and set it to required.

Question 4

Your team maintains a public open-source library in Azure Repos. External contributors must be able to propose changes without gaining write access to the main repository, while your internal maintainers need full control over what merges into the default branch. You also want CI validation to run automatically on every proposed change before a maintainer reviews it. Which approach best satisfies these requirements?

Accepted Answer

Have external contributors fork the repository, submit pull requests from their forks, and configure a branch policy on the default branch requiring a build validation and maintainer review.

Answer

Grant external contributors Contribute permission on the main repository and rely on branch policies to block direct pushes to the default branch.

Answer

Enable a required reviewers branch policy only, and manually copy external patches into a maintainer-created branch before merging.

Answer

Give external contributors the Force Push permission on feature branches and require them to squash-merge into the default branch themselves.

Question 5

A developer accidentally committed a file containing production database credentials to the main branch of an Azure Repos Git repository three weeks ago. Several commits have been made since, and the branch is shared by 12 team members. Security requires that the secret be completely removed from the repository history, not just the latest commit. Which action correctly removes the sensitive data from all history?

Accepted Answer

Use git filter-repo (or BFG) to rewrite history removing the file, force-push the rewritten branch, and have all team members re-clone; also rotate the exposed credentials.

Answer

Delete the file in a new commit and push it to main so the credentials no longer appear in the working tree.

Answer

Enable branch policies with push protection on main so future secret pushes are blocked automatically.

Answer

Create a new tag at the current commit and delete all older tags that reference the commit containing the secret.

Question 6

Your team uses Azure Repos with a Git repository named 'payments-core'. Release engineers create annotated tags such as 'v2.4.0' to mark production builds, and these tags must be immutable for audit compliance. Recently, a developer accidentally deleted the tag 'v2.3.0' and pushed a new tag with the same name pointing to a different commit. You must prevent any user other than the 'Release Managers' group from creating, editing, or deleting tags, while still allowing all contributors to push commits to branches. What should you configure?

Accepted Answer

In the repository's Security settings, navigate to the Tags node and set 'Manage tags' to Deny for Contributors and Allow for Release Managers.

Answer

Set the 'Force push (rewrite history, delete branches and tags)' permission to Deny for the Contributors group at the repository level.

Answer

Create a branch policy on the default branch that requires pull request approval before tags can be pushed.

Answer

Enable Git LFS locking on the repository so that tags are locked to the Release Managers group.

Question 7

Your team uses Azure Repos with Git. Leadership requires that no code reaches the 'main' branch without at least two reviewers, all comments must be resolved, changes must be traceable to a work item, and the CI build must pass before merging. Developers must not be able to push commits directly to 'main'. Which combination of Azure Repos branch policies on 'main' best satisfies all these requirements?

Accepted Answer

Enable 'Require a minimum number of reviewers' set to 2, 'Check for linked work items', 'Check for comment resolution', and 'Build validation' as a required policy.

Answer

Add a branch security rule denying 'Contribute' to all developers and rely on nightly pipeline validation to catch defects.

Answer

Enable 'Require a minimum number of reviewers' set to 1 with 'Allow requestors to approve their own changes', plus an optional build validation trigger.

Answer

Create a server-side pre-receive hook that rejects pushes and configure a scheduled release pipeline to gate merges.

Question 8

Your game development team stores large binary assets (textures, 3D models, and video files, often 100 MB to 2 GB each) in an Azure DevOps Git repository. Developers report that cloning the repository takes hours and consumes excessive disk space because every historical version of each binary is downloaded. You must reduce clone times and storage bloat for these binary files while keeping them under version control. What should you implement?

Accepted Answer

Configure Git LFS and track the binary file types with a .gitattributes file, then migrate the existing binaries into LFS.

Answer

Enable Scalar on each client and run scalar clone to accelerate the existing repository.

Answer

Create a branch policy that requires a pull request before any binary file can be committed to main.

Answer

Add the binary file extensions to a .gitignore file so they are excluded from version control.

Question 9

A team's Azure Repos Git repository has grown to several gigabytes because designers have committed large .psd and .png files directly into history for the past two years. Cloning now takes over 20 minutes. The team wants to move these existing binary files (including all historical versions) into Git LFS so future clones only download the LFS pointers and current blobs. Which approach correctly converts the existing history to use Git LFS?

Accepted Answer

Run 'git lfs migrate import --include="*.psd,*.png" --everything' to rewrite history so the matching files in all commits are stored in LFS, then force-push the rewritten branches.

Answer

Add a .gitattributes file tracking *.psd and *.png with LFS, commit it, and push — existing files will automatically be relocated to LFS storage.

Answer

Enable Git LFS on the repository in Azure DevOps project settings, which retroactively moves all binary blobs to LFS without changing commit history.

Answer

Run 'git lfs track "*.psd" "*.png"' and then 'git gc --aggressive' to compress the existing binaries into the LFS store.

Question 10

A developer at your company accidentally deleted a feature branch named 'feature/payments' in an Azure Repos Git repository. The branch contained several unmerged commits that were pushed to the remote before deletion. The developer does not have the commit SHA and no local clone with the branch still exists. As the DevOps engineer, what is the fastest supported way to restore the branch with its commits in Azure DevOps?

Accepted Answer

Use the Azure DevOps portal to search for the deleted branch under the repository's Branches page 'Deleted branches' view and select Restore.

Answer

Open a support ticket with Microsoft to recover the branch from server-side backups, since deleted branches cannot be restored by users.

Answer

Run 'git reflog' on the Azure DevOps server through an SSH session to find the dangling commit and re-create the branch.

Answer

Restore the repository from the last daily snapshot in Project Settings, which will bring back all recently deleted branches.

Question 11

Your team maintains a very large Git monorepo in Azure Repos that is over 200 GB with hundreds of thousands of files. Developers report that cloning and running everyday Git commands (status, checkout) is extremely slow because they only work in a small subset of directories. You want to improve local performance without splitting the repository. Which approach should you implement?

Accepted Answer

Register the repository with Scalar to enable partial clone and sparse-checkout, downloading only needed objects and files on demand

Answer

Enable Git LFS for all source code files so that only pointers are stored locally until files are accessed

Answer

Run 'git gc --aggressive' on the server-side repository to repack objects and reduce clone size for all developers

Answer

Create a shallow clone with '--depth 1' and instruct all developers to use only shallow history permanently

Question 12

Your team ships a customer-facing web service and deploys to production multiple times per day. Developers integrate small changes directly into a single main branch behind feature flags, and every commit to main triggers CI and automated deployment. Recently, a critical production bug requires a fix that must ship immediately while a large in-progress feature (already merged behind a disabled flag) must NOT be released. Which approach best preserves your current branching strategy while safely shipping the fix?

Accepted Answer

Commit the hotfix directly to main and rely on the disabled feature flag to keep the unfinished feature hidden, then let the normal pipeline deploy.

Answer

Create a long-lived release branch from an earlier commit, cherry-pick the fix there, and permanently deploy from that branch going forward.

Answer

Revert every commit related to the in-progress feature on main, ship the hotfix, then re-apply the feature commits afterward.

Answer

Freeze all merges to main, switch the team to a feature-branch model, and only deploy once the large feature is complete.

More AZ-400 practice