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

Question 1

Your team uses Git for source control. A developer accidentally committed a large binary file (500 MB) to the main branch. The push succeeded but other team members are now complaining about slow fetch times. What is the most efficient way to remove the file from the repository history?

Accepted Answer

Use 'git filter-repo' to remove the file from history. Option A is correct because 'git filter-repo' is the recommended modern tool for permanently removing large files from Git history. It rewrites the repository's commit graph, eliminating the file from all commits, which reduces repository size and resolves slow fetch times for team members. Unlike BFG Repo-Cleaner, 'git filter-repo' is actively maintained and integrates natively with Git, making it the most efficient and reliable choice for this task.

Answer

Add the file to .gitignore and push again

Answer

Use 'git revert' to undo the commit

Answer

Use BFG Repo-Cleaner

Question 2

Your organization is adopting a trunk-based development strategy with short-lived feature branches. Which branch policy should you enforce to ensure that code is integrated frequently and conflicts are minimized?

Accepted Answer

Require a minimum number of reviewers and enforce a squash merge strategy. In a trunk-based development strategy with short-lived feature branches, the goal is to integrate code frequently and minimize merge conflicts. Requiring a minimum number of reviewers ensures code quality and team awareness, while enforcing a squash merge strategy collapses all feature branch commits into a single commit on the main branch, keeping the history linear and clean. This approach reduces the risk of complex merge conflicts and supports continuous integration by encouraging small, frequent merges.

Answer

Allow direct pushes to main branch for senior developers

Answer

Create release branches for each production deployment

Answer

Require all merges to be fast-forward only

Question 3

Your team uses GitHub and wants to enforce a policy that all commits to the main branch must be signed with a GPG key that is associated with the author's GitHub account. Which method should you use to enforce this?

Accepted Answer

Add a branch protection rule that requires signed commits. Option C is correct because branch protection rules in GitHub include a 'Require signed commits' setting that enforces GPG or S/MIME signature verification on all commits pushed to the protected branch. This policy is enforced server-side before the commit is accepted, ensuring that only commits signed with a key associated with the author's GitHub account are allowed into the main branch.

Answer

Create a GitHub Actions workflow that runs a signature check after push

Answer

Use a commit status check to verify signatures

Answer

Configure a repository ruleset that requires signed commits

Question 4

Your organization uses Azure Repos and has multiple Git repositories that share common code. You want to enable code reuse across these repositories without duplicating code. Which strategy should you use?

Accepted Answer

Reference the shared repository as a Git submodule. Git submodules allow you to include a specific commit of a shared repository as a subdirectory within multiple parent repositories, enabling code reuse without duplication. When the shared code is updated, you can pull the latest commit into each parent repository, maintaining a clear link between the parent and the shared codebase. This is the native Git mechanism for referencing external repositories while preserving version control history.

Answer

Use Git subtrees to merge the shared code into each repository

Answer

Publish the shared code as a NuGet package

Answer

Add the shared repository as an upstream source in Azure Artifacts

Question 5

Your team uses GitHub Flow and wants to ensure that every pull request is reviewed by at least one team member. Which branch protection rule should you enable?

Accepted Answer

Require a pull request before merging and set required number of reviewers to 1. Option A is correct because GitHub Flow relies on pull requests for collaboration, and the 'Require a pull request before merging' rule with a required number of reviewers set to 1 enforces that every PR must be reviewed by at least one team member before it can be merged. This directly satisfies the requirement of ensuring code review for all changes.

Answer

Require signed commits

Answer

Require status checks to pass before merging

Answer

Require conversation resolution before merging

Question 6

Your company uses Azure DevOps and has a large monorepo with multiple teams. Developers report that Git operations are slow due to the repository size. Which approach should you recommend to improve performance while maintaining a single repository?

Accepted Answer

Enable sparse checkout and shallow fetch. Sparse checkout and shallow fetch are designed to improve Git performance in large monorepos by limiting the working tree to specific directories (sparse checkout) and reducing the history depth (shallow fetch). This keeps the repository intact as a single unit while significantly reducing the amount of data transferred and stored locally, directly addressing the slow Git operations without breaking the monorepo structure.

Answer

Use Git LFS to store all files

Answer

Split the monorepo into multiple smaller repositories

Answer

Add a .gitattributes file with filter directives

Question 7

Your team uses GitHub and wants to automatically link pull requests to work items in Azure Boards. What should you configure?

Accepted Answer

Install the Azure Boards app for GitHub and configure the integration. The Azure Boards app for GitHub is the official integration that synchronizes work items with GitHub commits, branches, and pull requests. Once installed and configured, it automatically links pull requests to Azure Boards work items based on mention patterns (e.g., 'AB#123') in the PR description or commit messages, enabling traceability without custom scripting.

Answer

Add a repository secret with Azure Boards connection string

Answer

Configure branch protection rules to require a linked work item

Answer

Create a GitHub Actions workflow that posts comments to Azure Boards

Question 8

Your team uses Git and wants to ensure that all commits follow a consistent message format. Which approach should you use?

Accepted Answer

Use a client-side Git hook (commit-msg) to validate the message. A client-side Git hook, specifically the commit-msg hook, runs locally on the developer's machine before the commit is finalized, allowing immediate validation of the commit message format. This ensures that every commit adheres to the team's convention at the point of creation, without relying on server-side enforcement or pipeline execution.

Answer

Add a step in Azure Pipelines to validate commit messages

Answer

Create a GitHub Actions workflow that checks commit messages on push

Answer

Configure a branch policy in Azure Repos to enforce commit message format

Question 9

Your organization uses GitHub Enterprise and wants to enforce that all repositories have a consistent CODEOWNERS file. Which approach should you use to centrally manage this?

Accepted Answer

Use repository rulesets to require that the CODEOWNERS file exists and has a specified pattern. Repository rulesets in GitHub Enterprise allow you to centrally enforce policies across all repositories in an organization, including requiring that a CODEOWNERS file exists and matches a specific pattern. This ensures consistency without manual intervention or per-repo configuration, leveraging GitHub's native repository management capabilities.

Answer

Create a CODEOWNERS file at the organization level

Answer

Use a script to push CODEOWNERS to each repo manually

Answer

Create a GitHub Actions workflow that runs on push to check CODEOWNERS

Question 10

Which TWO options are benefits of using Git LFS (Large File Storage) in a team environment? (Select TWO.)

Accepted Answer

Prevents large files from being stored in the Git history. Option A is correct because Git LFS replaces large files in the repository with text pointer files, while the actual file content is stored in a separate remote store. This prevents the large files from bloating the Git history, which would otherwise permanently increase repository size for all clones and fetches.

Answer

Automatically detects and tracks all binary files in the repository

Answer

Works only with GitHub and Azure Repos

Answer

Eliminates the need for Git when working with large binary files

Question 11

Which THREE practices are recommended for managing secrets in a Git repository? (Select THREE.)

Accepted Answer

Use tools like GitLeaks to scan for accidentally committed secrets. Options B, D, and E are correct. Using Azure Key Vault (B), GitHub Secrets (D), and scanning with tools (E) are best practices. Option A is wrong because storing encrypted secrets in Git is risky. Option C is wrong because committing .env files is dangerous.

Answer

Store secrets in a separate encrypted file committed to the repository

Answer

Commit a .env file with default values to the repository

Question 12

Which TWO Git operations are considered dangerous and should be used with caution because they rewrite history? (Select TWO.)

Accepted Answer

git push --force. Option B is correct because `git push --force` overwrites the remote branch history with the local branch, discarding any commits on the remote that are not in the local history. This can cause other collaborators to lose work if they have based changes on the overwritten commits, making it a history-rewriting operation that must be used with caution.

Answer

git fetch

Answer

git merge

Answer

git revert

Question 13

Refer to the exhibit. An Azure DevOps administrator has configured the branch policy for the main branch as shown. A developer attempts to push a commit directly to the main branch. What will happen?

Accepted Answer

The push is rejected because branch policies require a pull request. Option D is correct. The policy has 'requireLinearHistory' false, but 'allowForcePush' is false, and there is no branch policy that allows direct pushes. By default, branch policies require pull requests. Option A is wrong because allowForcePush false prevents force pushes. Option B is wrong because requireLinearHistory false does not allow direct pushes. Option C is wrong because build validation does not block the push; it is part of PR policy.

Answer

The push triggers the build validation pipeline

Answer

The push is allowed because allowForcePush is false

Answer

The push is allowed because requireLinearHistory is false

Question 14

Refer to the exhibit. A developer runs 'git log --oneline --graph --decorate' and sees the output. Which Git workflow does this history most closely represent?

Accepted Answer

Git Flow. The output of `git log --oneline --graph --decorate` shows multiple long-lived branches (e.g., `develop`, `feature/*`, `release/*`, `hotfix/*`) with periodic merges back to `develop` and `main`. This branching structure with dedicated branches for features, releases, and hotfixes is the hallmark of Git Flow, which uses a strict branching model to manage releases and maintenance in parallel.

Answer

GitLab Flow

Answer

Trunk-based development

Answer

GitHub Flow

Question 15

Refer to the exhibit. An Azure DevOps pipeline has the YAML configuration shown. A developer creates a pull request from a feature branch to the develop branch. What will happen?

Accepted Answer

The pipeline does not run automatically. Option C is correct. The pipeline trigger includes develop branch, but the pr trigger only includes main. Since the PR target is develop (not main), the pr trigger does not fire. The CI trigger fires on push to develop, but the PR is from feature to develop, so the CI trigger (on push to develop) would run only after the PR is merged. Option A is wrong because the PR trigger is for main only. Option B is wrong because the CI trigger is for main and develop, but the PR push is not to develop directly. Option D is wrong because the pipeline does not run.

Answer

The pipeline runs only if the PR is merged

Answer

The pipeline runs as a CI build on the feature branch

Answer

The pipeline runs as a PR validation build