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

Question 1

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 2

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 3

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 4

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 5

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 6

You are designing a source control strategy for a team that uses GitHub Copilot. The team wants to ensure that code suggestions do not include sensitive data. Which approach should you recommend?

Accepted Answer

Configure content exclusions in GitHub Copilot settings to block sensitive data patterns. GitHub Copilot's content exclusions allow you to define patterns (e.g., regex for API keys, tokens, or PII) that Copilot will block from being used as context for code suggestions. This directly prevents sensitive data from appearing in suggestions without disabling the tool entirely. It is the most targeted and least disruptive approach to meet the team's goal.

Answer

Use pre-commit hooks to scan for secrets

Answer

Disable GitHub Copilot for the organization

Answer

Enable secret scanning for the repository

Question 7

Your team uses GitHub and wants to automatically close stale branches that have not been updated in 90 days. Which GitHub feature should you configure?

Accepted Answer

Create a scheduled GitHub Actions workflow that deletes branches older than 90 days. A is correct because GitHub Actions can be scheduled using cron syntax to run a workflow that identifies branches with no commits in the last 90 days and deletes them via the GitHub API. This gives you full control over the deletion logic, logging, and notifications, unlike a simple bot. The workflow can use actions like `actions/github-script` to enumerate branches and filter by `committer.date`.

Answer

Auto-merge feature

Answer

Stale bot (GitHub Actions)

Answer

GitHub Discussions

Question 8

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

Question 9

Which THREE practices are recommended for effective source control in a GitHub monorepo? (Choose three.)

Accepted Answer

Use branch protection rules to enforce CI checks. Branch protection rules (B) enforce required status checks like CI builds and tests before merging, maintaining stability in a monorepo with many contributors. Code owners (D) automatically request reviewers from the responsible teams for changes in their respective paths, ensuring proper review and accountability. Path filters (E) trigger only the CI workflows relevant to the changed code, avoiding unnecessary builds and reducing feedback loops. Storing large binaries in the repo (A) is poor practice, and a single build definition for all projects (C) is inefficient because it forces full builds on every change.

Answer

Store large binary files directly in the repository

Answer

Use a single build definition for all projects

Question 10

Which TWO approaches can you use to enforce consistent commit message formatting across your organization? (Choose two.)

Accepted Answer

Use a pre-receive hook in GitHub to validate commit messages. GitHub's pre-receive hooks are server-side scripts that execute on the repository before accepting a push, allowing you to enforce commit message format validation across all contributors. Similarly, Azure Repos branch policies can include a commit message pattern check, which validates commit messages against a regex and rejects pushes with non-conforming messages. Both approaches enforce the standard on the server side, regardless of local client configurations.

Answer

Use a GitHub workflow that checks PR titles

Answer

Provide a commit message template to developers

Answer

Use Git hooks only on client side

Question 11

You are reviewing the branch protection policy for the main branch in an Azure DevOps repository. Based on the exhibit, what happens when a stale review exists on a pull request after new changes are pushed?

Accepted Answer

The stale review is automatically dismissed, and the PR requires new approvals. The branch protection policy for the main branch has 'Reset code reviewer votes when there are new changes' enabled. When a stale review exists after new changes are pushed, Azure DevOps automatically dismisses the previous approval(s) and requires new approvals to meet the minimum number of reviewers (2). This ensures that reviewers re-evaluate the latest code changes before the pull request can be merged.

Answer

Admins are exempt from the review requirement

Answer

The PR still requires only 2 approvals, but stale reviews are not dismissed

Answer

The PR can be merged even without the required reviews

Question 12

Your Azure Pipeline is configured as shown in the exhibit. A developer pushes a commit to a feature branch named 'feature/new-login' and creates a pull request targeting the main branch. Which pipeline runs will be triggered?

Accepted Answer

Only a PR build. The pipeline is configured with a PR trigger that activates on pull requests targeting the main branch. When a developer pushes a commit to 'feature/new-login' and creates a PR to main, only the PR build is triggered. The CI trigger is not configured for the feature branch (only for main), so no CI build runs on the feature branch itself.

Answer

No pipeline runs

Answer

Only a CI build on the feature branch

Answer

Both a CI build on the feature branch and a PR build

Question 13

You are debugging a recent issue introduced in the main branch. Based on the exhibit, which command would you run to revert the 'Fix login bug' commit while preserving the merge commit?

Accepted Answer

git revert -m 1 HEAD. The 'Fix login bug' commit is a merge commit. To revert a merge commit while preserving its merge parent (i.e., the mainline), you must use `git revert -m 1 HEAD`. The `-m 1` flag specifies that the first parent (the main branch) should be kept, effectively reverting the changes brought by the merge. Option C, `git revert HEAD`, would fail because Git requires the `-m` flag when reverting a merge commit. Option B destroys history, which is not desired. Option D uses `-m 2`, which would revert the changes from the secondary parent (the feature branch), not the merge itself.

Answer

git reset --hard HEAD~1

Answer

git revert HEAD

Answer

git revert c3a2b1e -m 2

Question 14

Your team is using GitHub Flow for a web application. Developers create feature branches from main, make changes, and open pull requests. Recently, several pull requests were merged without required reviews because the branch protection rules were not enforced on the main branch. What should you do to ensure all pull requests to main require at least one reviewer?

Accepted Answer

Enable the 'Require a pull request before merging' rule in branch protection for main, and set 'Required approvals' to 1.. Branch protection rules in GitHub can enforce required pull request reviews before merging. By enabling 'Require a pull request before merging' and setting 'Required approvals' to 1, any pull request to main must have at least one reviewer approve before merging. Option B is incorrect because deleting head branches after merge does not enforce reviews. Option C is incorrect because requiring branches to be up to date is about ensuring the branch is current with the base branch, not about requiring reviews. Option D is incorrect because CODEOWNERS are optional and do not enforce mandatory reviews unless branch protection rules are set accordingly.

Answer

Configure the repository to automatically delete head branches after pull requests are merged.

Answer

Enable the 'Require branches to be up to date' rule in branch protection for main.

Answer

Add a CODEOWNERS file and configure it so that every file has at least one owner.

Question 15

Your company uses Azure Repos with a Git branching strategy that includes a main branch, a develop branch, and feature branches. You need to enforce that only designated release managers can merge changes from develop into main, while developers can create feature branches off develop and merge pull requests into develop. What is the best way to implement this?

Accepted Answer

Configure branch policies on main to require a minimum number of reviewers from the release manager group, and set the 'Allow users to create pull requests' permission to only include release managers.. By configuring branch policies on the main branch to require a minimum number of reviewers from the release manager group, you ensure that any changes to main are reviewed by designated release managers. Additionally, setting the 'Allow users to create pull requests' permission to only include release managers controls who can initiate pull requests into main. Option B is incorrect because branch protection rules are a GitHub feature, not available in Azure Repos. Option C is incorrect because setting the main branch to read-only would prevent all pushes, including those from release managers, unless they are granted write permissions; however, this approach does not enforce pull request reviews and is less granular. Option D is incorrect because requiring a successful build does not restrict who can merge; it only ensures code quality.

Answer

Use GitHub branch protection rules to require pull request reviews from release managers on main.

Answer

Set the main branch to read-only for all users except release managers using the 'Security' tab in repository settings.

Answer

Require a successful build for all branches and set the build pipeline to only run for release manager commits.