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

Question 1

Your team uses GitHub Flow. A developer pushes a feature branch to origin and creates a pull request to main. After review and approval, the pull request is merged. Which branch should the developer delete after the merge to maintain a clean repository?

Accepted Answer

Delete the feature branch. In GitHub Flow, feature branches are temporary and should be deleted after their pull request is merged into main. Deleting the feature branch keeps the repository clean by removing stale branches that are no longer needed, reducing clutter and preventing confusion. This practice aligns with the principle of short-lived branches in trunk-based development workflows.

Answer

Keep both branches indefinitely

Answer

Delete the main branch

Answer

Delete the remote main branch and recreate it

Question 2

Your company has multiple teams working on a monorepo in Azure Repos. You need to enforce that changes to the /src/api folder require approval from the API team, while changes to /src/web require approval from the Web team. Which branch policy feature should you use?

Accepted Answer

Path filters in branch policy. Path filters in branch policy allow you to define conditions that trigger specific policy requirements based on the files changed in a pull request. By configuring a path filter for /src/api, you can require approval from the API team only when files in that folder are modified, and a separate path filter for /src/web can require approval from the Web team. This ensures that each team's approval is enforced only for their respective code areas within the monorepo.

Answer

Require a minimum number of reviewers

Answer

Automatically include code reviewers

Answer

Use separate repositories for each team

Question 3

Your team is using Git with Azure Repos. A developer accidentally committed a large binary file to the main branch. What is the recommended way to permanently remove it from the repository history?

Accepted Answer

Use 'git filter-branch' to remove the file from history. Option D is correct because `git filter-branch` (or its modern replacement `git filter-repo`) rewrites the entire repository history to permanently remove a file from all commits. This is the recommended approach when a large binary file has been committed to the main branch and must be expunged from history to reduce repository size and prevent it from being cloned by others.

Answer

Delete the file and commit the deletion

Answer

Ignore the file using .gitignore

Answer

Revert the commit using 'git revert'

Question 4

Your organization uses GitHub Enterprise and wants to prevent secrets (e.g., API keys) from being pushed to any repository. Which GitHub feature should you enable?

Accepted Answer

Push protection for secret scanning. Push protection for secret scanning (Option C) is the correct answer because it actively blocks pushes that contain known secrets (e.g., API keys, tokens) at the client side, preventing them from ever reaching the remote repository. This is a dedicated feature of GitHub Advanced Security that integrates with pre-receive hooks to scan commits in real time, rejecting the push if a secret pattern is detected. It is specifically designed to prevent secrets from being pushed, unlike passive scanning which only alerts after the fact.

Answer

Repository rulesets

Answer

GitHub Advanced Security secret scanning

Answer

Branch protection rules requiring signed commits

Question 5

Your team is migrating from TFVC to Git in Azure Repos. Developers frequently work on the same files simultaneously. Which Git workflow should you recommend to minimize merge conflicts?

Accepted Answer

Feature branch workflow. The feature branch workflow is ideal for minimizing merge conflicts when developers work on the same files simultaneously because each developer creates a short-lived branch off the main branch for their specific feature or fix, commits frequently, and merges back via pull requests. This isolates changes until they are ready, reducing the surface area for conflicts compared to long-lived branches. Git's merge or rebase strategies within this workflow allow for incremental conflict resolution, which is more manageable than resolving large conflicts from divergent histories.

Answer

GitFlow

Answer

Forking workflow

Answer

Centralized workflow

Question 6

Your team uses Azure Pipelines to build and test code. You want to automatically trigger a pipeline when a pull request is created targeting the main branch. Which trigger should you configure?

Accepted Answer

PR trigger. A PR trigger is the correct choice because Azure Pipelines supports a 'pr' trigger that automatically starts a pipeline when a pull request is created targeting a specified branch (e.g., main). This is distinct from a CI trigger, which runs on commits to a branch, and is essential for validating changes before merging.

Answer

Scheduled trigger

Answer

CI trigger

Answer

Manual trigger

Question 7

Your organization uses GitHub Copilot for pull request summaries. A developer notices that the AI-generated summary is inaccurate. Which step should the developer take to improve the quality of future summaries?

Accepted Answer

Provide a detailed pull request description. Providing a detailed pull request description helps Copilot generate more accurate summaries. Disabling Copilot is not necessary. Editing the summary once is a workaround but does not improve future generations. Ignoring the issue does not help.

Answer

Disable Copilot for pull requests

Answer

Edit the description after generation

Answer

Ignore the inaccuracy

Question 8

Your team uses Azure Repos and wants to enforce that all commits to the release branch must be signed using GPG. Which branch policy should you enable?

Accepted Answer

Require signed commits. Option D is correct because Azure Repos branch policies include a 'Require signed commits' setting that enforces GPG signature verification on all commits pushed to the branch. When enabled, any commit without a valid GPG signature is rejected, ensuring the integrity and authenticity of the commit author.

Answer

Limit merge types

Answer

Check for linked work items

Answer

Require a minimum number of reviewers

Question 9

Your team uses GitHub and wants to prevent direct pushes to the main branch. Only pull requests with at least one approval should be allowed to merge. Which GitHub feature should you use?

Accepted Answer

Branch protection rules. Branch protection rules are the correct GitHub feature to enforce that direct pushes to the main branch are blocked and that only pull requests with at least one approval can merge. This is configured under the repository's Settings > Branches, where you can require pull request reviews before merging and restrict who can push directly.

Answer

Repository rulesets

Answer

CODEOWNERS file

Answer

GitHub Actions

Question 10

Which TWO actions should you take to implement Git-based source control for a large enterprise with multiple teams and a single repository (monorepo)? (Select TWO.)

Accepted Answer

Configure path-based branch policies. Using sparse checkout reduces clone size. Path-based branch policies enforce team-specific reviews. Forking is not typical for monorepos. Submodules introduce complexity. Single branch for all teams causes conflicts.

Answer

Require all teams to work on a single branch

Answer

Use Git submodules to separate team code

Answer

Use forking workflow for each team

Question 11

Which THREE are common Git branching strategies used by development teams? (Select THREE.)

Accepted Answer

GitFlow. GitFlow, Trunk-based development, and Feature branching are common strategies. Centralized version control is not a Git branching strategy. Monorepo is a repository structure, not a branching strategy.

Answer

Monorepo

Answer

Centralized version control

Question 12

Which TWO benefits does using Git LFS (Large File Storage) provide? (Select TWO.)

Accepted Answer

Prevents large files from being stored in the Git history. Git LFS (Large File Storage) prevents large files from being stored directly in the Git repository history. Instead, it replaces the large file in the working tree with a small text pointer file, while the actual binary content is stored on a remote LFS server. This keeps the repository lightweight and avoids bloating the Git object database with large blobs.

Answer

Automatically compresses all files in the repository

Answer

Replaces .gitignore for excluding large files

Answer

Speeds up diff operations for binary files

Question 13

Your team uses a monorepo in Azure Repos with multiple microservices. Developers frequently report merge conflicts due to long-lived feature branches. Which branching strategy minimizes merge conflicts while supporting continuous integration?

Accepted Answer

Use trunk-based development with short-lived feature branches and frequent merges to main. Trunk-based development with short-lived feature branches (typically lasting less than a day) minimizes merge conflicts by ensuring that changes are integrated into the main branch frequently, often multiple times per day. This approach reduces the divergence between branches, making conflicts less likely and easier to resolve. It also supports continuous integration by triggering automated builds and tests on every merge to main, aligning with the team's need for rapid feedback and reduced integration overhead.

Answer

Use release branches for all development work and merge to main only at release time

Answer

Use GitFlow with separate develop and main branches, and long-lived feature branches

Answer

Use a forking workflow where each developer works in a personal fork and submits pull requests

Question 14

You are designing a source control strategy for a global team of 200 developers working on a single large .NET solution. The solution takes 45 minutes to build. You need to reduce build times and enable independent versioning of components. What should you do?

Accepted Answer

Split the solution into multiple repositories, each with its own CI/CD pipeline. Splitting the solution into multiple repositories (a multi-repo strategy) allows independent teams to version and build their components separately, reducing the monolithic 45-minute build to smaller, parallel CI/CD pipelines. This approach also enables independent versioning of components, which is impossible in a monorepo without complex tooling. Each repository can have its own pipeline that triggers only on changes to that component, drastically cutting build times.

Answer

Migrate from Git to Team Foundation Version Control (TFVC) for better performance

Answer

Stay in a monorepo and use one pipeline with path filters to build only changed components

Answer

Keep the monorepo and disable continuous integration builds to reduce load

Question 15

Your organization uses GitHub for source control. You need to enforce that all pull requests require at least one approval and that branches must be up to date with the base branch before merging. Which branch protection rule settings should you enable?

Accepted Answer

Require a pull request before merging and require branches to be up to date. Option D is correct because GitHub branch protection rules allow you to enforce both that pull requests require at least one approval and that branches are up to date with the base branch before merging. The 'Require a pull request before merging' setting ensures that changes cannot be pushed directly to the protected branch and must go through a PR with required approvals. The 'Require branches to be up to date' setting (under 'Require status checks to pass before merging') ensures that the branch is tested against the latest base branch code, preventing stale merges.

Answer

Require branches to be up to date only

Answer

Require a pull request before merging only

Answer

Require status checks to pass before merging only