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

Question 1

Your team uses a monorepo in Azure Repos containing multiple projects. You want to set up CI/CD so that only the projects affected by a commit are built and deployed. Which approach should you use?

Accepted Answer

Create separate Azure Pipelines for each project, each configured to trigger on changes to that project's folder.. In a monorepo, to build and deploy only affected projects, create one Azure Pipeline per project and configure each with path-based triggers that include only that project's folder. This way, a commit touching a specific project triggers only that project's pipeline. While a single pipeline can use path filters and conditions to skip steps, the straightforward and recommended approach is separate pipelines.

Answer

Use Git hooks to detect changes and run only the relevant build scripts locally.

Answer

Use a single YAML pipeline that includes all projects, and use the 'condition' keyword to skip steps based on changed files.

Answer

Use a single YAML pipeline with path-based triggers and path filters in the 'trigger' section for each project's folder.

Question 2

Your organization uses GitHub Advanced Security. A developer accidentally committed a file containing production database connection strings to a feature branch. The push was not yet merged into main. What is the best way to remove the secrets from the branch history while minimizing disruption?

Accepted Answer

Use git filter-repo to remove the file from the branch's history, then force push the branch.. `git filter-repo` is the recommended modern tool for rewriting Git history, including removing a specific file from all commits in a branch. After rewriting the branch's history to exclude the file, a force push (`git push --force`) overwrites the remote branch, effectively purging the secret from the branch's history. This approach minimizes disruption by preserving the branch's other commits and avoiding the need to recreate the branch or lose work.

Answer

Use BFG Repo-Cleaner to delete the file from the branch's history, then force push.

Answer

Delete the feature branch and have the developer recreate the branch without the secret file.

Answer

Revert the commit that added the file, then push the revert.

Question 3

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

Configure a pull request policy that requires a linked work item, and enforce that all merges to main are via pull request.. In Azure Repos, the 'Require a linked work item' branch policy applies only to pull requests, not to direct pushes. To enforce that every commit to main is associated with a work item, you must require that all changes come through pull requests (via a branch policy requiring PRs) and then enable the 'Require a linked work item' policy on pull requests. This ensures that every commit merged into main via a PR has a linked work item. Option A is incorrect because the 'Require a linked work item' branch policy does not apply to direct pushes; it only applies to pull request completions.

Answer

Add a branch policy on main that requires a linked work item for all pushes.

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.

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 git-tfs is the standard bridge tool that clones a TFVC repository (including changesets and history) into a local Git repository, which can then be pushed to Azure Repos as the migration mechanism. Option D is correct because migrating from TFVC to Git changes the workflow fundamentally—developers must understand Git branching (e.g., topic branches, pull requests) and commands (clone, commit, push, rebase) before cutover to avoid disruption and lost work. Option A is not correct because there is no Azure DevOps Migration Tool that directly maps TFVC permissions to Git permissions; permissions must be reconfigured manually or via APIs/CLI. Option C is not correct because mirroring TFVC branch structure into a single Git repository with multiple branches is not a required or recommended migration action—Git branches are lightweight and the mapping is handled by the conversion tool, not by manually creating branches. Option E is not correct because Git LFS is optional for handling large binaries and is not a prerequisite for a smooth TFVC-to-Git 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 reusable workflows are designed exactly for this: you define a workflow in a central repository with the workflow_call trigger and invoke it from other repositories using the uses keyword (e.g., uses: org/central-repo/.github/workflows/ci.yml@main), which centralizes logic and eliminates duplication. Option C is correct because a template repository lets you store standardized workflow files under .github/workflows and generate new repositories that inherit those files, which is a valid way to share common CI/CD workflows across an organization. Option B is not appropriate because Git submodules are for embedding source repositories, not for injecting workflow definitions that GitHub Actions will automatically execute. Option D is wrong because branch protection rules only control merges and reviews; they do not centralize or share workflow definitions. Option E is invalid because GitHub Actions has no concept of a separately installable 'workflow library' package.

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 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 a build validation policy to check the branch name and reject merges that do not follow the pattern.. Azure Repos branch policies do not provide a native setting to restrict which source branches can merge into a target branch. To enforce the GitFlow workflow, you can add a build validation policy that runs a build (or a simple script) on the PR and fails if the source branch does not match the expected pattern for the target branch. For example, for `main` only `hotfix/*` is allowed, while for `develop` both `hotfix/*` and `feature/*` are allowed. This blocks any PR that violates the rules.

Answer

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

Answer

Use branch policies on main and develop that allow only certain source branches to merge, using branch naming conventions.

Answer

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

Question 7

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. Option A, `git pull --rebase`, is correct because it fetches changes from the remote and then replays your local commits on top of the updated remote branch, avoiding a merge commit and keeping history linear. Option E, `git rebase`, is correct because it rewrites your local commits onto a new base (such as the updated remote-tracking branch after a fetch), which linearizes history by eliminating merge commits. Option B, `git fetch`, only downloads remote objects and updates remote-tracking branches; it does not integrate changes into your local branch, so it does not by itself produce linear history. Option C, `git merge`, integrates changes but typically creates a merge commit, which is non-linear. Option D, `git cherry-pick`, applies individual commits from another branch and is not the standard way to incorporate an entire remote branch while preserving linear history.

Answer

git fetch

Answer

git merge

Answer

git cherry-pick

Question 8

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.. It includes all required elements: requiring pull request reviews (which can be configured to require code owner reviews), requiring status checks, requiring branches to be up-to-date, and restricting who can push to matching branches to prevent direct pushes. Option A lacks the up-to-date requirement. Option B does include pull request reviews but lacks status checks and permits admin direct pushes. Option C lacks pull request reviews and does not restrict direct pushes, though it does include 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.

Question 9

Your team uses GitHub with a monorepo containing frontend and backend code. You need to implement a strategy where changes to the frontend folder trigger a frontend CI pipeline, changes to the backend folder trigger a backend CI pipeline, and changes to both trigger both. You also want to ensure that pull requests include changes only to one area to reduce complexity. What should you do?

Accepted Answer

Configure separate CI pipelines with path filters so that each pipeline triggers only on changes to its respective folder.. GitHub Actions and Azure Pipelines support path filters (e.g., `paths` in YAML triggers) that allow you to define separate CI pipelines for frontend and backend folders. When a pull request includes changes to both folders, both pipelines automatically trigger, satisfying the requirement. This approach ensures that each pipeline runs only when its relevant code changes, reducing unnecessary builds and complexity.

Answer

Use CODEOWNERS to assign different reviewers for frontend and backend, and rely on manual pipeline triggers.

Answer

Create branch policies that require specific builds based on the branch name.

Answer

Use a single pipeline that runs all tests on every change.

Question 10

Your organization stores a shared library in an Azure Repos Git repository. Multiple product repositories need to consume this library as source, and you want each product build to pin an exact commit of the library rather than a moving branch. You also want contributors to be able to open pull requests against the library from their product work. Which Git feature should you configure in each product repository?

Accepted Answer

A Git submodule that references the library repository commit SHA.. Submodules encode a precise commit SHA of an external repository inside the consuming repository, giving reproducible builds that pin the library exactly. Because the library remains a normal Git repository, contributors can branch, commit, and raise pull requests against it from their product context. Subtree merges, package feeds, and LFS pointers each fail either the exact-commit pinning or the pull-request contribution requirement.

Answer

A NuGet package feed that publishes the library on every commit to its main branch.

Answer

A Git LFS pointer that tracks the library repository as a large file.

Answer

A Git subtree merge that copies the library source into a subdirectory of each product repository.

Question 11

Your team uses a monorepo in Azure Repos containing multiple projects. You want to set up CI/CD so that only the projects affected by a commit are built and deployed. Which approach should you use?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use trunk-based development with feature flags to merge small, frequent changes.. Trunk-based development with feature flags is the correct approach because it encourages developers to merge small, frequent changes into the main branch, reducing the surface area for conflicts. Feature flags allow incomplete features to be hidden in production, enabling continuous integration without requiring long-lived feature branches. This strategy directly addresses the problem of frequent merge conflicts by minimizing divergence between branches.

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 12

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

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

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 15

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