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

Question 1

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?

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

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 2

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 3

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 4

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 5

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. Option A, Build validation, is correct because it enforces that a build pipeline runs and succeeds against the pull request before the changes can be merged into the release branch, satisfying the requirement that builds succeed before merging. Option C, Minimum number of reviewers set to 2, is correct because it requires at least two approvers to sign off on each pull request targeting the release branch, satisfying the two-approver review requirement. Option B, Work item linking, only enforces association of work items to commits or PRs and does not address reviewer counts or build success. Option D, Require a clean fast-forward merge, only controls merge history shape and does not enforce reviews or builds. Option E, Require a merge commit, likewise only dictates the merge strategy and does not provide approval or build gating.

Answer

Work item linking

Answer

Require a clean fast-forward merge

Answer

Require a merge commit

Question 6

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?

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

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 7

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 8

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 9

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

Question 10

Your Azure DevOps repository contains a large binary file that is slowing down clone operations. Which Git feature should you use to reduce the clone time?

Accepted Answer

Git LFS (Large File Storage). Git LFS (Large File Storage) is the correct solution because it replaces large binary files in the repository with lightweight text pointers, storing the actual binary content in external remote storage. This prevents the large file from being downloaded during every clone, significantly reducing clone time and repository size on disk.

Answer

Shallow clone

Answer

Depth parameter in clone command

Answer

Sparse checkout

Question 11

Your team uses Azure Repos and needs to prevent secrets from being committed to the repository. Which built-in feature should you enable?

Accepted Answer

Enable push protection in Azure Repos. Push protection in Azure Repos is a built-in feature that scans commits for high-confidence secrets (e.g., Azure service connection strings, SSH keys, and other credential patterns) and blocks the push if a secret is detected. This prevents secrets from ever reaching the remote repository, enforcing security at the server side without requiring client-side configuration.

Answer

Enable GitHub secret scanning

Answer

Enable Azure Policy to scan repositories

Answer

Configure a pre-commit hook with a secret scanning tool

Question 12

Your organization uses GitHub and wants to implement a monorepo strategy for multiple related projects. Which approach best optimizes CI/CD pipeline performance by only building projects that have changed?

Accepted Answer

Use path filters in GitHub Actions workflows. GitHub Actions path filters (using `on.push.paths` or `on.pull_request.paths`) allow you to trigger workflows only when changes are made to specific directories or files. In a monorepo, this ensures that CI/CD pipelines run exclusively for the projects that have been modified, avoiding unnecessary builds and significantly improving performance.

Answer

Use a single workflow that builds all projects on every push

Answer

Use submodules to separate projects

Answer

Use workflow templates and composite actions

Question 13

You need to enforce that every commit in your repository is associated with a work item in Azure Boards. Which mechanism should you use?

Accepted Answer

Configure a branch policy to require linked work items. Azure Repos branch policies include a setting to 'Require linked work items', which enforces that every pull request (and by extension, every commit merged through that PR) is associated with a work item in Azure Boards. This policy is enforced server-side at merge time, ensuring no commit can be merged without a linked work item, regardless of how the commit message is formatted.

Answer

Use commit messages with work item IDs

Answer

Deploy a custom Git hook on the server

Answer

Use the 'Require status checks' policy

Question 14

Your team is migrating from TFVC to Git in Azure Repos. They want to preserve the history of all branches. Which migration tool should you use?

Accepted Answer

git-tfs tool. The git-tfs tool is specifically designed to migrate TFVC repositories to Git while preserving full branch history, including changesets, branch relationships, and merge history. It bridges the gap between TFVC and Git by converting TFVC changesets into Git commits and mapping TFVC branches to Git branches, making it the correct choice for this migration scenario.

Answer

GitHub Importer

Answer

Azure DevOps Migration Tools

Answer

git-svn

Question 15

Which TWO actions should you take to proactively protect your repository from accidentally committing secrets? (Choose two.)

Accepted Answer

Use pre-commit hooks with tools like detect-secrets. Pre-commit hooks, such as those using the detect-secrets tool, scan staged changes before a commit is finalized. This prevents secrets from ever entering the repository history, providing a proactive, client-side guard. Option C is correct because push protection in secret scanning blocks pushes that contain known secret patterns at the server side, preventing the secret from being stored in the remote repository.

Answer

Enable branch protection rules

Answer

Use signed commits

Answer

Configure secret scanning alerts