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

Question 1

You see the above git log output. The team has a policy requiring linear history on the main branch. Which command should be used next time to integrate the feature branch?

Accepted Answer

git rebase main feature/login then git merge --ff-only. The team requires a linear history on the main branch. By first rebasing the feature branch onto main (`git rebase main feature/login`), you reapply the feature commits on top of the latest main commit, creating a clean, linear sequence. Then `git merge --ff-only` performs a fast-forward merge, which simply moves the main branch pointer forward without creating a merge commit, preserving the linear history policy.

Answer

git merge --squash feature/login

Answer

git cherry-pick f4e5d6c a7b8c9d

Answer

git merge --no-ff feature/login

Question 2

Your team uses GitHub and wants to enforce that all commits to the main branch are signed with a GPG key. Which branch protection rule should you configure?

Accepted Answer

Require signed commits.. The 'Require signed commits' branch protection rule enforces that every commit pushed to the protected branch must be signed with a GPG key. This ensures cryptographic verification of the commit author's identity, directly addressing the requirement to enforce signed commits on the main branch.

Answer

Require pull request reviews before merging.

Answer

Require status checks to pass before merging.

Answer

Require linear history.

Question 3

Your Azure DevOps project contains a Git repository with multiple branches. You need to ensure that code reviews are mandatory for all pull requests targeting the 'release' branch. Additionally, the build pipeline must pass before merging. How should you configure branch policies?

Accepted Answer

Enable 'Require a minimum number of reviewers' and 'Build validation'.. The requirement specifies two distinct conditions: mandatory code reviews (enforced by 'Require a minimum number of reviewers') and a passing build pipeline before merge (enforced by 'Build validation'). In Azure Repos, branch policies allow you to combine multiple checks; enabling only one of these would leave the other requirement unmet. Therefore, both policies must be enabled to satisfy the full criteria.

Answer

Enable 'Build validation' only.

Answer

Enable 'Require a minimum number of reviewers' only.

Answer

Enable 'Require a minimum number of reviewers' and 'Comment resolution'.

Question 4

Your organization has multiple GitHub repositories that use shared workflows. You want to centrally manage these workflows and ensure they are always up to date. What is the recommended approach?

Accepted Answer

Create a central repository with reusable workflows and reference them using the 'uses' keyword in your workflows.. The recommended approach is to create a central repository with reusable workflows and reference them using the 'uses' keyword. This is a native GitHub Actions feature that allows you to define shared workflow files in one repository and call them from any other repository in your organization. This ensures all workflows stay up to date centrally. The other options are not recommended: B uses API scheduling which is unnecessary and harder to manage; C downloads workflows from blob storage as inline scripts which loses the benefits of shared workflow versioning; D uses Git submodules which are designed for code dependencies and do not integrate well with GitHub Actions workflow execution.

Answer

Use the GitHub API to push workflow files to each repository on a schedule.

Answer

Download the workflows from a central blob storage and include them as inline scripts.

Answer

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

Question 5

You are setting up a new GitHub repository for a project that requires strict access control. Only specific team members should be able to push to the main branch, but all team members should be able to create branches and open pull requests. What is the best way to achieve this?

Accepted Answer

Use a branch protection rule to restrict pushes to the main branch to specific users or teams.. Branch protection rules in GitHub allow you to enforce restrictions on specific branches, such as requiring pull request reviews or restricting who can push directly. By configuring a rule for the main branch that limits push access to only designated users or teams, you ensure that all team members can create branches and open PRs, but only authorized members can merge into main. This directly meets the requirement without over-provisioning permissions or blocking collaboration.

Answer

Add all team members as administrators of the repository.

Answer

Remove write permissions for non-core team members and give them read-only access.

Answer

Set the repository to private and invite only core team members.

Question 6

Which TWO are valid reasons to use a monorepo?

Accepted Answer

Simplifies code sharing and reuse across multiple projects.. A monorepo centralizes all code in a single repository, making it straightforward to share common libraries, utilities, and components across multiple projects without needing separate package feeds or submodule references. Option E is correct because with all projects in one repo, dependency versions are unified and managed in a single set of manifest files (e.g., package.json, requirements.txt), eliminating cross-repo version drift and simplifying coordinated updates.

Answer

Smaller clone size compared to multiple repositories.

Answer

Allows independent CI/CD pipelines for each project.

Answer

Improves security by isolating each project.

Question 7

You receive a webhook notification from Azure Pipelines with the above payload. The build for the 'feature/logging' branch failed. You want to automatically create a work item to track the fix. What should you configure in Azure DevOps?

Accepted Answer

Enable the 'Create work item on failure' option in the pipeline settings.. Azure Pipelines provides a built-in setting called 'Create work item on failure' that automatically generates a work item (e.g., a bug or task) in Azure Boards whenever a pipeline run fails. This directly meets the requirement to track the fix for the failed build on the 'feature/logging' branch without requiring external integrations or manual steps.

Answer

Add a branch policy on 'feature/logging' to require a successful build before merging.

Answer

Use a GitHub Actions workflow to create an issue on failure.

Answer

Create a service hook subscription to listen for build failures and call Azure Boards API.

Question 8

You have the above branch policy configuration for the main branch. A developer pushes a new commit to an existing pull request. What happens?

Accepted Answer

The existing approvals are reset, and a new build is automatically queued.. The branch policy has 'Reset code review votes when new changes are pushed' enabled (resetOnSourcePush: true) and 'Build validation' with 'Automatically queue a new build when new changes are pushed' enabled (queueOnSourceUpdateOnly: true). When a new commit is pushed to an existing pull request, the existing approvals are reset, and a new build is automatically queued. Therefore, option C is correct.

Answer

The existing approvals are reset, but no new build is queued.

Answer

The pull request is automatically completed.

Answer

The existing approvals remain valid, and the build is not requeued.

Question 9

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

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 11

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 12

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

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 14

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 15

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