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

Question 1

Your organization uses GitHub Enterprise and wants to enforce that all repositories have a consistent CODEOWNERS file. Which approach should you use to centrally manage this?

Accepted Answer

Create a CODEOWNERS file at the organization level. In GitHub Enterprise, you can create a special repository named `.github` at the organization level. A CODEOWNERS file stored in that repository is applied as a default to all repositories in the organization, providing centralized management. Repository rulesets cannot require that a file exists; they enforce branch/tag rules such as required reviews and status checks, but not file existence.

Answer

Use repository rulesets to require that the CODEOWNERS file exists and has a specified pattern

Answer

Use a script to push CODEOWNERS to each repo manually

Answer

Create a GitHub Actions workflow that runs on push to check CODEOWNERS

Question 2

Which TWO options are benefits of using Git LFS (Large File Storage) in a team environment? (Select TWO.)

Accepted Answer

Prevents large files from being stored in the Git history. Git LFS replaces large files in the repository with text pointer files, while the actual file content is stored in a separate remote store. This prevents the large files from bloating the Git history, which would otherwise permanently increase repository size for all clones and fetches.

Answer

Automatically detects and tracks all binary files in the repository

Answer

Works only with GitHub and Azure Repos

Answer

Eliminates the need for Git when working with large binary files

Question 3

Which THREE practices are recommended for managing secrets in a Git repository? (Select THREE.)

Accepted Answer

Use tools like GitLeaks to scan for accidentally committed secrets. The recommended practices for managing secrets in a Git repository include using tools like GitLeaks to scan for accidentally committed secrets (Option A), using GitHub Secrets or Azure Pipelines secret variables (Option C), and using Azure Key Vault to store and retrieve secrets at build/release time (Option D). These approaches help avoid storing secrets directly in the repository. Option B is incorrect because storing secrets in an encrypted file committed to the repository still exposes them to anyone who can access the repo and the decryption key. Option E is incorrect because committing a .env file with default values risks including sensitive data and is not a secure practice.

Answer

Store secrets in a separate encrypted file committed to the repository

Answer

Commit a .env file with default values to the repository

Question 4

Which TWO Git operations are considered dangerous and should be used with caution because they rewrite history? (Select TWO.)

Accepted Answer

git push --force. `git push --force` overwrites the remote branch history with the local branch, discarding any commits on the remote that are not in the local history. This can cause other collaborators to lose work if they have based changes on the overwritten commits, making it a history-rewriting operation that must be used with caution.

Answer

git fetch

Answer

git merge

Answer

git revert

Question 5

Refer to the exhibit. An Azure DevOps administrator has configured the branch policy for the main branch as shown. A developer attempts to push a commit directly to the main branch. What will happen?

Accepted Answer

The push is rejected because branch policies require a pull request. The branch policy for the main branch requires that all changes be submitted via a pull request. When a developer attempts to push a commit directly to main, Azure Repos enforces this policy by rejecting the push. The push is blocked at the server level before any build validation or other checks occur.

Answer

The push triggers the build validation pipeline

Answer

The push is allowed because allowForcePush is false

Answer

The push is allowed because requireLinearHistory is false

Question 6

Refer to the exhibit. A developer runs 'git log --oneline --graph --decorate' and sees the output. Which Git workflow does this history most closely represent?

Accepted Answer

Git Flow. The output of `git log --oneline --graph --decorate` shows multiple long-lived branches (e.g., `develop`, `feature/*`, `release/*`, `hotfix/*`) with periodic merges back to `develop` and `main`. This branching structure with dedicated branches for features, releases, and hotfixes is the hallmark of Git Flow, which uses a strict branching model to manage releases and maintenance in parallel.

Answer

GitLab Flow

Answer

Trunk-based development

Answer

GitHub Flow

Question 7

Refer to the exhibit. An Azure DevOps pipeline has the YAML configuration shown. A developer creates a pull request from a feature branch to the develop branch. What will happen?

Accepted Answer

The pipeline does not run automatically. The YAML configuration does not include a `trigger` or `pr` trigger, so by default the pipeline only runs on pushes to branches that have a pipeline configured, not on pull requests. Since the developer creates a PR from a feature branch to develop, and no trigger is defined for the feature branch or PR validation, the pipeline does not run automatically.

Answer

The pipeline runs only if the PR is merged

Answer

The pipeline runs as a CI build on the feature branch

Answer

The pipeline runs as a PR validation build

Question 8

Your team uses GitHub Flow. A developer pushes a feature branch to origin and creates a pull request to main. After review and approval, the pull request is merged. Which branch should the developer delete after the merge to maintain a clean repository?

Accepted Answer

Delete the feature branch. In GitHub Flow, feature branches are temporary and should be deleted after their pull request is merged into main. Deleting the feature branch keeps the repository clean by removing stale branches that are no longer needed, reducing clutter and preventing confusion. This practice aligns with the principle of short-lived branches in trunk-based development workflows.

Answer

Keep both branches indefinitely

Answer

Delete the main branch

Answer

Delete the remote main branch and recreate it

Question 9

Your company has multiple teams working on a monorepo in Azure Repos. You need to enforce that changes to the /src/api folder require approval from the API team, while changes to /src/web require approval from the Web team. Which branch policy feature should you use?

Accepted Answer

Path filters in branch policy. Path filters in branch policy allow you to define conditions that trigger specific policy requirements based on the files changed in a pull request. By configuring a path filter for /src/api, you can require approval from the API team only when files in that folder are modified, and a separate path filter for /src/web can require approval from the Web team. This ensures that each team's approval is enforced only for their respective code areas within the monorepo.

Answer

Require a minimum number of reviewers

Answer

Automatically include code reviewers

Answer

Use separate repositories for each team

Question 10

Your team is using Git with Azure Repos. A developer accidentally committed a large binary file to the main branch. What is the recommended way to permanently remove it from the repository history?

Accepted Answer

Use 'git filter-branch' to remove the file from history. `git filter-branch` (or its modern replacement `git filter-repo`) rewrites the entire repository history to permanently remove a file from all commits. This is the recommended approach when a large binary file has been committed to the main branch and must be expunged from history to reduce repository size and prevent it from being cloned by others.

Answer

Delete the file and commit the deletion

Answer

Ignore the file using .gitignore

Answer

Revert the commit using 'git revert'

Question 11

Your organization uses GitHub Enterprise and wants to prevent secrets (e.g., API keys) from being pushed to any repository. Which GitHub feature should you enable?

Accepted Answer

Push protection for secret scanning. Push protection for secret scanning (Option C) is the correct answer because it actively blocks pushes that contain known secrets (e.g., API keys, tokens) at the client side, preventing them from ever reaching the remote repository. This is a dedicated feature of GitHub Advanced Security that integrates with pre-receive hooks to scan commits in real time, rejecting the push if a secret pattern is detected. It is specifically designed to prevent secrets from being pushed, unlike passive scanning which only alerts after the fact.

Answer

Repository rulesets

Answer

GitHub Advanced Security secret scanning

Answer

Branch protection rules requiring signed commits

Question 12

Your team is migrating from TFVC to Git in Azure Repos. Developers frequently work on the same files simultaneously. Which Git workflow should you recommend to minimize merge conflicts?

Accepted Answer

Feature branch workflow. The feature branch workflow is ideal for minimizing merge conflicts when developers work on the same files simultaneously because each developer creates a short-lived branch off the main branch for their specific feature or fix, commits frequently, and merges back via pull requests. This isolates changes until they are ready, reducing the surface area for conflicts compared to long-lived branches. Git's merge or rebase strategies within this workflow allow for incremental conflict resolution, which is more manageable than resolving large conflicts from divergent histories.

Answer

GitFlow

Answer

Forking workflow

Answer

Centralized workflow

Question 13

Your team uses Azure Pipelines to build and test code. You want to automatically trigger a pipeline when a pull request is created targeting the main branch. Which trigger should you configure?

Accepted Answer

PR trigger. A PR trigger is the correct choice because Azure Pipelines supports a 'pr' trigger that automatically starts a pipeline when a pull request is created targeting a specified branch (e.g., main). This is distinct from a CI trigger, which runs on commits to a branch, and is essential for validating changes before merging.

Answer

Scheduled trigger

Answer

CI trigger

Answer

Manual trigger

Question 14

Your organization uses GitHub Copilot for pull request summaries. A developer notices that the AI-generated summary is inaccurate. Which step should the developer take to improve the quality of future summaries?

Accepted Answer

Provide a detailed pull request description. Providing a detailed pull request description gives GitHub Copilot more context and structured input, which directly improves the accuracy of AI-generated summaries. Copilot's PR summary feature relies on the diff and any existing description to infer intent; a richer description reduces ambiguity and enhances the quality of the generated output.

Answer

Disable Copilot for pull requests

Answer

Edit the description after generation

Answer

Ignore the inaccuracy

Question 15

Your team uses Azure Repos and wants to enforce that all commits to the release branch must be signed using GPG. Which branch policy should you enable?

Accepted Answer

Require signed commits. Azure Repos branch policies include a 'Require signed commits' setting that enforces GPG signature verification on all commits pushed to the branch. When enabled, any commit without a valid GPG signature is rejected, ensuring the integrity and authenticity of the commit author.

Answer

Limit merge types

Answer

Check for linked work items

Answer

Require a minimum number of reviewers