AZ-400 Design and implement a source control strategy Practice Test 6 — 15 Questions

Question 1

Your organization needs to enforce that every commit to the main branch in Azure Repos is associated with a work item from Azure Boards. What should you configure?

Accepted Answer

Add a branch policy on main that requires a linked work item for all pushes.. Option A is correct because Azure Repos branch policies include a specific policy to 'Require a linked work item' for all pushes to a branch. This policy enforces that every commit pushed directly to the main branch must be associated with a work item from Azure Boards, ensuring traceability and compliance with your organization's requirements.

Answer

Create a pre-receive hook in the repository to reject commits without a work item.

Answer

Enable the 'Gated check-in' option in the branch policy for main.

Answer

Configure a pull request policy that requires a linked work item, and enforce that all merges to main are via pull request.

Question 2

Your team uses GitHub and wants to automatically label pull requests based on the content of the changes (e.g., 'frontend' for changes in /frontend folder, 'backend' for /backend). Which approach should you use?

Accepted Answer

Create a GitHub Actions workflow that runs on pull_request events and uses an action like 'actions/labeler' to add labels based on path patterns.. Option C is correct because GitHub Actions provides a native, event-driven way to automate labeling based on pull request changes. The 'actions/labeler' action specifically inspects file paths in the diff and applies labels defined in a configuration file, making it the simplest and most maintainable solution for path-based labeling.

Answer

Use branch protection rules to require specific labels based on branch name patterns.

Answer

Set up a webhook that triggers an Azure Function to parse the pull request diff and add labels.

Answer

Use a CODEOWNERS file to assign labels based on file paths.

Question 3

Your team uses Azure DevOps and wants to enforce that all changes to the main branch go through a pull request process with at least two approvals. They also want to prevent contributors from approving their own pull requests. Which branch policy settings should they use?

Accepted Answer

Enable 'Require a minimum number of reviewers' set to 2, and enable 'Allow users to approve their own changes' unchecked (or set to false).. Option D is correct because it directly addresses both requirements: setting 'Require a minimum number of reviewers' to 2 enforces at least two approvals, and unchecking 'Allow users to approve their own changes' prevents contributors from approving their own pull requests. These are branch policy settings within Azure Repos that control the pull request workflow on the main branch.

Answer

Enable 'Check for linked work items' and 'Require a minimum number of reviewers' set to 2, and enable 'Reset code reviewer votes when new changes are pushed'.

Answer

Add the 'main' branch to the 'Required reviewers' list and add all developers as required reviewers.

Answer

Enable 'Require a minimum number of reviewers' set to 2, and enable 'Build validation' with a required build.

Question 4

Your team is migrating from TFVC to Git in Azure Repos. Which TWO actions should you take to ensure a smooth migration?

Accepted Answer

Use the git-tfs tool to clone the TFVC repository with full history into a local Git repository.. Option B is correct because the git-tfs tool is specifically designed to bridge TFVC and Git, allowing you to clone a TFVC repository with full changeset history into a local Git repository. This preserves the commit history, which is critical for audit trails and code review continuity during the migration.

Answer

Use the Azure DevOps Migration Tool to directly map TFVC permissions to Git repository permissions.

Answer

Create a single Git repository with multiple branches that mirror the TFVC branch structure.

Answer

Enable Git LFS in the new repository to handle large binary files from TFVC.

Question 5

Your GitHub organization has multiple repositories that share common CI/CD workflows. You want to centralize these workflows to reduce duplication. Which TWO approaches are valid?

Accepted Answer

Create reusable workflows in a central repository and use the 'uses' keyword in each repository's workflow to reference them.. Option A is correct because GitHub Actions supports reusable workflows that can be stored in a central repository and referenced from other repositories using the 'uses' keyword with the syntax 'owner/repo/.github/workflows/workflow.yml@ref'. This allows teams to define common CI/CD logic once and invoke it across multiple repositories, reducing duplication and simplifying maintenance.

Answer

Store the workflows in a central repository and use Git submodules to include them in each repository.

Answer

Use branch protection rules to enforce that all workflows must be reviewed by a central team.

Answer

Publish the workflows as a GitHub Actions workflow library and install it in each repository.

Question 6

Your organization uses Azure Repos and wants to implement a Git branching strategy that supports continuous delivery with hotfix capabilities. Which THREE practices should be part of the strategy?

Accepted Answer

Release branches are used to stabilize a release before merging to main.. Option B is correct because release branches allow a team to stabilize a release candidate without disrupting ongoing development on the main branch. Once the release is fully tested and stable, it is merged into main, ensuring that main always contains production-ready code. This aligns with the continuous delivery principle of maintaining a deployable main branch.

Answer

Feature branches have long lifetimes and are merged to main only after full feature completion.

Answer

Hotfixes are merged directly to develop and then cherry-picked to main.

Question 7

Refer to the exhibit. You are reviewing a branch protection rule for the main branch of a GitHub repository. A developer complains that after pushing new commits to an existing pull request, the existing approvals from two reviewers are dismissed, and the pull request cannot be merged even though the CI checks pass. What is the most likely cause?

Accepted Answer

The 'dismiss_stale_reviews' setting is enabled, which dismisses approvals when new commits are pushed.. Option A is correct because the 'dismiss_stale_reviews' setting in GitHub branch protection rules automatically dismisses existing pull request approvals when new commits are pushed to the branch. This explains why the developer sees approvals removed after pushing new commits, even though CI checks pass. The setting is designed to ensure that reviewers re-evaluate changes after updates.

Answer

The 'strict' setting requires the branch to be up to date with the base branch, which is not the case.

Answer

The code owner review is required but no code owner has reviewed.

Answer

The CI check 'continuous-integration/jenkins/pr-merge' failed.

Question 8

Your organization uses Azure DevOps for a large-scale e-commerce platform. The source code is stored in a single Azure Repos Git repository with over 100 contributors. The current branching strategy is a modified GitFlow with main, develop, release, and hotfix branches. However, the team is experiencing frequent merge conflicts and long integration periods. You have been asked to redesign the branching strategy to support continuous integration and deployment (CI/CD) while ensuring high-quality releases. The new strategy must reduce merge conflicts, enable fast feedback, and support hotfixes. The team uses feature flags to manage incomplete features. Which branching strategy should you recommend?

Accepted Answer

Implement trunk-based development: developers work on short-lived feature branches (less than a day) and merge to main multiple times a day. Use feature flags to control release of incomplete features. Hotfixes are created from main and merged back quickly.. Option B is correct because trunk-based development with short-lived feature branches and feature flags is designed to reduce merge conflicts and enable continuous integration. Option A is incorrect because GitFlow is the current problematic strategy. Option C is incorrect because release branches are not suitable for CI/CD with feature flags. Option D is incorrect because long-lived feature branches are the opposite of what is needed.

Answer

Use a single main branch and allow developers to commit directly to main, but require all commits to be small and pass CI. Hotfixes are committed directly to main.

Answer

Use a single main branch and create release branches from main for each deployment. Feature branches are merged to release branches, and then release branches are merged to main after deployment.

Answer

Continue using GitFlow but enforce stricter branch policies and require more frequent merges.

Question 9

Your company is a startup developing a mobile application with a small team of 5 developers. You use GitHub Free and want to implement a simple but effective branching strategy that supports continuous delivery. The team wants to release new features every week and be able to hotfix critical bugs quickly. They currently have a main branch and feature branches, but sometimes features are merged to main before they are fully tested, causing issues. You need to recommend a strategy that minimizes risk while keeping the process lightweight. The team does not want to use long-lived branches. What should you recommend?

Accepted Answer

Use GitHub Flow: developers create feature branches from main, open pull requests with required CI and at least one review, then merge to main. Hotfixes follow the same process.. GitHub Flow is the simplest and most effective strategy for a small team using GitHub Free that wants continuous delivery without long-lived branches. By requiring feature branches, pull requests with CI checks, and at least one review before merging to main, it ensures that all code is tested and reviewed before integration, preventing untested features from breaking main. Hotfixes follow the same lightweight process, allowing quick, safe patches without additional branch overhead.

Answer

Use a single main branch and create release branches for each weekly release; features are merged to release branches, then release branches are merged to main after testing.

Answer

Allow developers to commit directly to main but require all commits to pass CI and be reviewed by at least one other developer after the fact.

Answer

Adopt GitFlow with develop and release branches.

Question 10

Your team uses a monorepo in Azure Repos. Developers frequently commit directly to the main branch, causing build failures. You need to enforce a policy that requires all changes to go through pull requests with at least one reviewer. What should you configure?

Accepted Answer

Configure a branch policy on the main branch to require a minimum number of reviewers.. Option C is correct because Azure Repos allows you to configure branch policies on specific branches (like main) to enforce that all changes must come through pull requests and require a minimum number of reviewers. This directly addresses the need to prevent direct commits to main and ensure code review before merging.

Answer

Configure a repository policy to require a pull request for all branches.

Answer

Create a service hook to reject commits to main that are not from pull requests.

Answer

Enable the 'Require a minimum number of reviewers' setting in the project settings.

Question 11

Your team is adopting GitFlow with a main and develop branch. You need to ensure that hotfix branches are merged into both main and develop, but feature branches only into develop. What branch policy configuration should you implement?

Accepted Answer

Use branch policies on main and develop that allow only certain source branches to merge, using branch naming conventions.. Option B is correct because Azure Repos branch policies allow you to restrict which source branches can merge into a target branch using branch naming conventions. By configuring policies on `main` and `develop` that only permit merges from specific source patterns (e.g., `hotfix/*` for `main` and `develop`, and `feature/*` only for `develop`), you enforce the GitFlow workflow without relying on manual oversight or build validation logic.

Answer

Set the main branch to require all merges to come from pull requests, and for develop, allow direct pushes.

Answer

Configure a global policy that requires all branches to have a minimum number of reviewers.

Answer

Use a build validation policy to check the branch name and reject merges that do not follow the pattern.

Question 12

Which TWO Git commands are commonly used to incorporate changes from a remote repository into your local branch while keeping history linear?

Accepted Answer

git pull --rebase. `git pull --rebase` (A) is correct because it fetches changes from the remote and then replays your local commits on top of the fetched commits, resulting in a linear history without merge commits. `git rebase` (E) is correct because it directly rewrites commit history by moving or combining a sequence of commits onto a new base, which can be used to incorporate remote changes linearly when combined with `git fetch`.

Answer

git fetch

Answer

git merge

Answer

git cherry-pick

Question 13

Which THREE practices are recommended when implementing a Git branching strategy for a team using Azure Repos?

Accepted Answer

Delete branches after they are merged.. Options A, B, and D are correct. A: Short-lived branches reduce merge conflicts. B: Build validation in branch policies ensures quality. D: Deleting branches after merge keeps repository clean. C is wrong because long-lived feature branches increase complexity. E is wrong because force pushing can rewrite history and disrupt collaboration.

Answer

Allow force pushes to shared branches to clean up history.

Answer

Keep feature branches alive for the entire sprint.

Question 14

Refer to the exhibit. You have a branch policy JSON for Azure Repos. Which statement about this policy is correct?

Accepted Answer

At least two reviewers must approve the pull request.. The branch policy JSON specifies `minimumApproverCount: 2`, which enforces that at least two distinct reviewers must approve the pull request before it can be completed. This is a standard Azure Repos branch policy setting that controls the required number of approvals, not the identity of the approvers or the merge strategy.

Answer

The last person who pushed can approve the pull request.

Answer

Pull requests to main are automatically squash-merged.

Answer

Approvals are reset when the source branch is updated.

Question 15

Your organization uses GitHub Enterprise with a monorepo containing multiple microservices. Developers work on feature branches and create pull requests to merge into main. You need to implement a policy that ensures all pull requests have at least one review from a code owner, pass required status checks (CI build and unit tests), and are up-to-date with the latest main branch before merging. Additionally, you want to prevent direct pushes to main. Which combination of branch protection rules should you configure?

Accepted Answer

Require pull request reviews before merging, require status checks, require branches to be up-to-date, and restrict who can push to matching branches.. Option D is correct because it includes all required elements: require pull request reviews before merging, require status checks, require branches to be up-to-date, and restrict direct pushes. Option A lacks the up-to-date requirement. Option B does not require pull requests. Option C lacks status checks.

Answer

Require pull request reviews before merging, require status checks, and restrict who can push to matching branches.

Answer

Require pull request reviews before merging, require branches to be up-to-date, and restrict push access to admins only.

Answer

Require status checks, require branches to be up-to-date, and include administrators.