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

Question 1

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 2

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

Accepted Answer

GitFlow. GitFlow is a common branching strategy that uses a main branch (master/main) alongside develop, feature, release, and hotfix branches. It provides a structured model for managing releases, hotfixes, and parallel development, making it suitable for projects with scheduled release cycles.

Answer

Monorepo

Answer

Centralized version control

Question 3

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 (option B). Instead, it stores a small pointer file in the repo while the actual large file content is stored externally, which reduces the size of the Git repository (option E). Options A, C, and D are incorrect because LFS does not automatically compress all files, replace .gitignore, or speed up diff operations for binary files.

Answer

Automatically compresses all files in the repository

Answer

Replaces .gitignore for excluding large files

Answer

Speeds up diff operations for binary files

Question 4

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 5

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

Question 6

Your organization uses Azure Repos and requires that all code changes pass a security scan before merging. The scan is run as a build validation policy. However, the scan takes 30 minutes and developers often bypass it by pushing directly to main. How can you enforce the policy for all changes?

Accepted Answer

Set a branch policy on main that requires a build validation with the security scan. Setting a branch policy on main that requires a build validation with the security scan enforces the scan as a mandatory gate for all pull requests targeting main. This prevents developers from bypassing the scan by pushing directly, as the policy blocks direct pushes and only allows changes through pull requests that must pass the configured build validation.

Answer

Turn off direct push permissions for all users and force all changes through pull requests

Answer

Delete the main branch and recreate it as a protected branch

Answer

Use a service hook to run the scan on every push to main

Question 7

Your team uses GitHub for source control. You need to ensure that sensitive data, such as connection strings, is never committed to the repository. Which tool should you use?

Accepted Answer

GitHub secret scanning. GitHub secret scanning automatically detects sensitive data like connection strings, API keys, and tokens as they are pushed to a repository, preventing them from being committed. It scans for known patterns and can block the push or alert the repository administrator, making it the correct tool for this requirement.

Answer

GitHub Actions

Answer

Dependabot

Answer

Git Large File Storage (LFS)

Question 8

You work for a multinational company that uses Azure Repos. The compliance team requires that all code changes include a work item reference in the commit message. What is the most effective way to enforce this?

Accepted Answer

Set a branch policy that requires a linked work item for pull requests. A branch policy in Azure Repos that requires linked work items for pull requests enforces the compliance requirement at the server side, ensuring that every pull request merge includes a work item reference. This policy is enforced before the merge completes, making it a reliable and auditable method that cannot be bypassed by individual developers. It directly integrates with Azure Boards to validate the link, providing a centralized enforcement mechanism.

Answer

Create a script in the build pipeline that checks the commit message

Answer

Configure a client-side commit hook that validates the commit message

Answer

Use a custom build task to automatically add the work item ID to the commit message

Question 9

Your organization is migrating from Azure Repos to GitHub. You have 200 repositories with complex branching strategies and build policies. You need to preserve the commit history and branch policies. What is the best migration approach?

Accepted Answer

Use git push --force to push all branches to GitHub and recreate policies manually. The GitHub Importer tool does not preserve branch policies; it only migrates repository history and code. To keep commit history and then recreate branch policies, the best approach is to use `git push --force` to push all branches from Azure Repos to GitHub, then recreate branch policies manually or via the GitHub API. This ensures complete history is preserved while policies are re-established separately.

Answer

Manually recreate each repository in GitHub and copy the code from Azure Repos

Answer

Use a third-party tool to perform a mirror clone and then push to GitHub

Answer

Use the GitHub Importer tool with a custom mapping script to migrate repositories and policies

Question 10

Your development team uses GitHub for source control. You want to automatically run a set of tests every time a pull request is opened against the main branch. What should you configure?

Accepted Answer

Create a GitHub Actions workflow triggered by pull_request events to main. GitHub Actions natively supports the `pull_request` event trigger, which can be configured to run workflows automatically when a pull request is opened against a specific branch (e.g., `main`). This allows you to define a YAML-based workflow in the `.github/workflows` directory that executes tests on every PR event, providing immediate feedback to developers without requiring external services or manual API calls.

Answer

Use the GitHub API to trigger tests when a PR is opened

Answer

Set up a webhook to trigger an external CI system

Answer

Configure a branch protection rule to require status checks

Question 11

Your team uses Azure Repos with a Git branching strategy. You need to ensure that all changes to the release branch are reviewed by at least two approvers and that builds succeed before merging. Which TWO branch policy settings should you enable?

Accepted Answer

Build validation. Build validation (A) ensures that a pull request cannot be merged unless the source branch compiles successfully and passes all configured automated tests, which directly enforces the requirement that builds succeed before merging. Minimum number of reviewers (C) set to 2 enforces the policy that at least two distinct approvers must approve the pull request before it can be completed. Together, these two settings satisfy both conditions: successful builds and two-reviewer approval.

Answer

Work item linking

Answer

Require a clean fast-forward merge

Answer

Require a merge commit

Question 12

Your organization uses GitHub for source control. You need to implement a secure source control strategy that prevents secrets from being exposed and ensures code quality. Which THREE practices should you implement?

Accepted Answer

Configure branch protection rules requiring status checks to pass. Branch protection rules enforce required status checks (e.g., CI builds, code reviews) before merging, ensuring only validated changes enter protected branches—this supports code quality. GitHub secret scanning automatically detects known types of secrets in repositories and alerts on exposure, directly preventing secret leaks. Pre-commit hooks scan code for secrets before a commit is created, blocking accidental commits of credentials or tokens. Together, A, D, and E address both secret prevention and code quality. Commit signing (C) verifies authorship but does not prevent secret exposure or enforce code quality checks.

Answer

Store secrets in a .env file committed to the repository

Answer

Require commit signing using GPG keys

Question 13

Your team uses Git for source control. You want to maintain a clean commit history on the main branch by avoiding merge commits. Which TWO merge strategies in a pull request achieve this?

Accepted Answer

Rebase merge. A rebase merge (option A) rewrites the commit history of the feature branch onto the tip of the target branch, creating a linear sequence of commits without any merge commits. This maintains a clean, linear history on the main branch. A squash merge (option C) combines all commits from the feature branch into a single new commit on the target branch, also avoiding merge commits and keeping the history clean.

Answer

Merge commit

Answer

Three-way merge

Answer

Fast-forward merge

Question 14

Your team uses GitHub for source control and wants to enforce that all pull requests into the main branch require at least two reviewers and must pass a status check from a CI pipeline. Which branch protection rule configurations should you apply?

Accepted Answer

Require a minimum of 2 reviewers, require status checks to pass before merging. GitHub branch protection rules allow you to require a minimum number of reviewers before merging and to require status checks to pass. By setting 'Require a minimum number of reviewers' to 2 and enabling 'Require status checks to pass before merging', you enforce that every pull request into the main branch must be approved by at least two reviewers and must pass the CI pipeline status check, meeting the stated requirements.

Answer

Require signed commits and status checks

Answer

Require status checks to pass, but do not require reviewers

Answer

Require a minimum of 2 reviewers, but do not require status checks

Question 15

You are designing a branching strategy for a microservices application with independent deployment cadences. The team wants to support continuous deployment to production from the main branch while allowing feature work to be isolated and tested. Which branching strategy best meets these requirements?

Accepted Answer

Trunk-based development with short-lived feature branches. Trunk-based development with short-lived feature branches (C) is correct because it enables continuous deployment from the main branch while isolating feature work in branches that are merged back to main within hours or a day. This approach minimizes merge conflicts and supports independent deployment cadences for microservices, as each service can be deployed from main independently without waiting for release branches.

Answer

One branch per environment (dev, test, prod)

Answer

GitHub Flow with feature branches merging to main

Answer

Git Flow with develop, release, and hotfix branches