AZ-400 Practice Exam 56 — 20 Questions

Question 1

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'.. Option C is correct because 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'.

Question 2

Your team uses GitHub and wants to automate the creation of a new release branch (e.g., release/v1.2.3) whenever a tag starting with 'v' is pushed. Which GitHub Actions trigger should you use?

Accepted Answer

on: create: tags: ['v*']. Option B is correct because the `on: create` trigger fires when a Git tag or branch is created, and the `tags: ['v*']` filter ensures it only activates for tags starting with 'v'. This directly matches the requirement to automate branch creation upon pushing a version tag, without relying on a GitHub Release event or a branch push.

Answer

on: release: types: [published]

Answer

on: push: branches: ['v*']

Answer

on: workflow_dispatch: inputs: tag

Question 3

You see the above git log output. The team has a policy requiring linear history on the main branch. Which command should be used next time to integrate the feature branch?

Accepted Answer

git rebase main feature/login then git merge --ff-only. Option D is correct because the team requires a linear history on the main branch. By first rebasing the feature branch onto main (`git rebase main feature/login`), you reapply the feature commits on top of the latest main commit, creating a clean, linear sequence. Then `git merge --ff-only` performs a fast-forward merge, which simply moves the main branch pointer forward without creating a merge commit, preserving the linear history policy.

Answer

git merge --squash feature/login

Answer

git cherry-pick f4e5d6c a7b8c9d

Answer

git merge --no-ff feature/login

Question 4

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

Use repository rulesets to require that the CODEOWNERS file exists and has a specified pattern. Repository rulesets in GitHub Enterprise allow you to centrally enforce policies across all repositories in an organization, including requiring that a CODEOWNERS file exists and matches a specific pattern. This ensures consistency without manual intervention or per-repo configuration, leveraging GitHub's native repository management capabilities.

Answer

Create a CODEOWNERS file at the organization level

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 5

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 6

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 7

Your organization uses Azure Repos and has multiple Git repositories that share common code. You want to enable code reuse across these repositories without duplicating code. Which strategy should you use?

Accepted Answer

Reference the shared repository as a Git submodule. Git submodules allow you to include a specific commit of a shared repository as a subdirectory within multiple parent repositories, enabling code reuse without duplication. When the shared code is updated, you can pull the latest commit into each parent repository, maintaining a clear link between the parent and the shared codebase. This is the native Git mechanism for referencing external repositories while preserving version control history.

Answer

Use Git subtrees to merge the shared code into each repository

Answer

Publish the shared code as a NuGet package

Answer

Add the shared repository as an upstream source in Azure Artifacts

Question 8

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 9

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. Option C is correct because 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 10

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 11

Your team uses GitHub and wants to enforce a policy that all commits to the main branch must be signed with a GPG key that is associated with the author's GitHub account. Which method should you use to enforce this?

Accepted Answer

Add a branch protection rule that requires signed commits. Option C is correct because branch protection rules in GitHub include a 'Require signed commits' setting that enforces GPG or S/MIME signature verification on all commits pushed to the protected branch. This policy is enforced server-side before the commit is accepted, ensuring that only commits signed with a key associated with the author's GitHub account are allowed into the main branch.

Answer

Create a GitHub Actions workflow that runs a signature check after push

Answer

Use a commit status check to verify signatures

Answer

Configure a repository ruleset that requires signed commits

Question 12

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 13

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 14

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 15

Your team uses Git with Azure Repos. You notice that the commit history on the main branch contains many merge commits and commit messages like 'fix merge conflict'. You want a linear history for better traceability. What should you change?

Accepted Answer

Use squash merge when completing pull requests. Option D is correct because squash merge collapses all feature branch commits into a single commit on the main branch, eliminating merge commits and preserving a linear history. This directly addresses the problem of cluttered commit messages like 'fix merge conflict' by discarding intermediate commits and their messages. Squash merge is configured in the Azure Repos branch policy for pull request completion.

Answer

Configure the repository to use rebase when pulling

Answer

Set the branch policy to require a clean fast-forward merge

Answer

Use rebase merge when completing pull requests

Question 16

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. Option D is correct because 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

Question 17

Your team uses Git for source control. A developer accidentally committed a large binary file (500 MB) to the main branch. The push succeeded but other team members are now complaining about slow fetch times. What is the most efficient way to remove the file from the repository history?

Accepted Answer

Use 'git filter-repo' to remove the file from history. Option A is correct because 'git filter-repo' is the recommended modern tool for permanently removing large files from Git history. It rewrites the repository's commit graph, eliminating the file from all commits, which reduces repository size and resolves slow fetch times for team members. Unlike BFG Repo-Cleaner, 'git filter-repo' is actively maintained and integrates natively with Git, making it the most efficient and reliable choice for this task.

Answer

Add the file to .gitignore and push again

Answer

Use 'git revert' to undo the commit

Answer

Use BFG Repo-Cleaner

Question 18

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. Option C is correct because 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 19

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

Accepted Answer

git push --force. Option B is correct because `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 20

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.. Option A is correct because `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.