AZ-400 Design and implement a source control strategy — Timed 20 Questions

Question 1

Your team uses a monorepo in Azure Repos with multiple feature branches. You notice that merge conflicts frequently occur because developers are working on the same files. You want to reduce conflicts and improve collaboration. Which branching strategy should you recommend?

Accepted Answer

Use trunk-based development with feature flags to merge small, frequent changes.. Option C is correct because feature flags allow developers to merge incomplete features into the main branch without affecting users, reducing long-lived branches and conflicts. Option A is wrong because GitFlow has long-lived branches that increase conflict risk. Option B is wrong because trunk-based development with short-lived branches is the recommended approach. Option D is wrong because release branches do not reduce conflicts on the main branch.

Answer

Use release branches for each deployment and cherry-pick commits from main.

Answer

Use a single main branch and require all changes to be committed directly.

Answer

Use GitFlow with separate develop and release branches.

Question 2

Your company is migrating from TFVC to Git in Azure Repos. The repository contains a large number of binary files (e.g., .dll, .exe) that are frequently updated. You need to minimize repository size and clone time. What should you include in your migration plan?

Accepted Answer

Use Git LFS to track binary files.. Option B is correct because Git LFS (Large File Storage) replaces large binary files in the repository with lightweight text pointers, storing the actual binary content in external storage. This prevents the repository from bloating with frequently updated binaries, reducing clone time and repository size since only the pointers are cloned.

Answer

Perform a shallow clone of the last commit only.

Answer

Use sparse checkout to exclude binary files from the working tree.

Answer

Use TFVC to Git converter with default settings.

Question 3

You have a GitHub repository with a GitHub Actions workflow that builds a .NET application. The workflow should only run when changes are pushed to the main branch, but it currently runs on every push to any branch. How should you fix the workflow trigger?

Accepted Answer

Add 'on: push: branches: [main]' to the workflow.. Option D is correct because the GitHub Actions workflow syntax to restrict a push trigger to a specific branch uses `on: push: branches: [main]`. This ensures the workflow only executes when commits are pushed to the main branch, not on pushes to any other branch.

Answer

Add 'on: push: branch: [main]' to the workflow.

Answer

Add 'on: push: paths: [main]' to the workflow.

Answer

Add 'on: pull_request: branches: [main]' to the workflow.

Question 4

You are reviewing a webhook payload from Azure Repos. The payload indicates that a new branch named 'feature-123' was created. Which event type triggered this webhook?

Accepted Answer

A new branch creation.. The webhook payload explicitly indicates that a new branch named 'feature-123' was created. In Azure Repos, the event type that corresponds to this action is 'New branch creation' (also known as 'Push' with a new ref). This event fires when a new branch reference is pushed to the remote repository, which is exactly what happened here.

Answer

A push to an existing branch.

Answer

A branch deletion.

Answer

A pull request update.

Question 5

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. Option D is correct because 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 6

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.. Option D is correct because 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 7

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'.. Option C is correct because 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 8

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.. Option B is correct because GitHub Actions allows you to reference workflows from other repositories using the 'uses' keyword with a path to a workflow file in another repo. Option A is wrong because submodules are for code, not workflows. Option C is wrong because you cannot directly reference a zip file. Option D is wrong because there is no 'workflow templates' API in GitHub.

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 9

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 10

Which TWO actions help reduce the size of a Git repository over time?

Accepted Answer

Use Git LFS for large binary files.. Option A is correct because Git LFS (Large File Storage) replaces large binary files with text pointers in the repository, storing the actual binary content in an external server. This prevents the repository from bloating with large files that are stored in full in every commit, significantly reducing the repository size over time.

Answer

Squash commits before pushing to the remote.

Answer

Perform shallow clones when cloning the repository.

Answer

Regularly run 'git gc' to compress objects.

Question 11

Which THREE are best practices for managing secrets in GitHub Actions workflows?

Accepted Answer

Use environment secrets to restrict access to specific workflows.. Option A is correct because secrets should be stored as Actions secrets, not in YAML. Option B is correct because access can be limited to specific workflows. Option C is correct because secrets should be masked in logs. Option D is wrong because secrets should not be shared across repositories unless necessary. Option E is wrong because environment variables are visible in logs.

Answer

Pass secrets as environment variables to actions.

Answer

Store the same secret in multiple repositories for consistency.

Question 12

Which TWO are valid reasons to use a monorepo?

Accepted Answer

Simplifies code sharing and reuse across multiple projects.. Option B is correct because 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 13

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.. Option B is correct because 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 14

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.. Option A is correct because 'resetOnSourcePush' is true, so the vote count resets, and 'queueOnSourceUpdateOnly' is true, so a new build is queued. Option B is wrong because the build is queued. Option C is wrong because the vote count resets. Option D is wrong because the build is queued and votes reset.

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 15

Your team uses GitHub and wants to automate the creation of a new release branch (e.g., release/v1.2.3) whenever a tag starting with 'v' is pushed. Which GitHub Actions trigger should you use?

Accepted Answer

on: create: tags: ['v*']. Option B is correct because the `on: create` trigger fires when a Git tag or branch is created, and the `tags: ['v*']` filter ensures it only activates for tags starting with 'v'. This directly matches the requirement to automate branch creation upon pushing a version tag, without relying on a GitHub Release event or a branch push.

Answer

on: release: types: [published]

Answer

on: push: branches: ['v*']

Answer

on: workflow_dispatch: inputs: tag

Question 16

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 17

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 18

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 19

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 20

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