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

Question 1

Your development team uses GitHub Enterprise and wants to automatically synchronize code from a public GitHub repository to their private repository every morning. What feature should they use?

Accepted Answer

A scheduled GitHub Actions workflow that fetches from the public repo and pushes to the private repo.. B is correct because a scheduled GitHub Actions workflow can periodically fetch changes from the public repository (using `git fetch` or `git pull`) and push them to the private repository. This approach avoids the need for external triggers and works even when the public repo does not send webhooks to your private environment. The schedule is defined using cron syntax in the workflow YAML, ensuring automatic daily synchronization.

Answer

Webhooks from the public repository to trigger a sync pipeline.

Answer

Git submodules to link the public repository as a subdirectory.

Answer

GitHub repository mirroring to automatically mirror the public repo.

Question 2

Your team uses a monorepo in Azure Repos containing multiple projects. You want to set up CI/CD so that only the projects affected by a commit are built and deployed. Which approach should you use?

Accepted Answer

Create separate Azure Pipelines for each project, each configured to trigger on changes to that project's folder.. In a monorepo, to build and deploy only affected projects, create one Azure Pipeline per project and configure each with path-based triggers that include only that project's folder. This way, a commit touching a specific project triggers only that project's pipeline. While a single pipeline can use path filters and conditions to skip steps, the straightforward and recommended approach is separate pipelines.

Answer

Use Git hooks to detect changes and run only the relevant build scripts locally.

Answer

Use a single YAML pipeline that includes all projects, and use the 'condition' keyword to skip steps based on changed files.

Answer

Use a single YAML pipeline with path-based triggers and path filters in the 'trigger' section for each project's folder.

Question 3

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

Question 4

Your team uses Git with a trunk-based development strategy. They want to ensure that all code changes are integrated into the main branch at least once a day, and that branch lifetimes are short. Which practice best supports this?

Accepted Answer

Developers work on short-lived feature branches (less than a day) and merge to main via pull requests after successful CI.. Trunk-based development emphasizes short-lived feature branches (typically less than a day) that are merged into the main branch via pull requests after passing continuous integration (CI) checks. This ensures all code changes are integrated at least daily, keeping branch lifetimes short and reducing merge conflicts.

Answer

Developers use GitFlow with develop and feature branches, merging to develop daily and to main at release.

Answer

Developers commit directly to a release branch, and then the release branch is merged to main at the end of the sprint.

Answer

Developers work on long-lived feature branches and merge to main only after all features are complete.

Question 5

Your organization needs to enforce that every commit to the main branch in Azure Repos is associated with a work item from Azure Boards. What should you configure?

Accepted Answer

Configure a pull request policy that requires a linked work item, and enforce that all merges to main are via pull request.. In Azure Repos, the 'Require a linked work item' branch policy applies only to pull requests, not to direct pushes. To enforce that every commit to main is associated with a work item, you must require that all changes come through pull requests (via a branch policy requiring PRs) and then enable the 'Require a linked work item' policy on pull requests. This ensures that every commit merged into main via a PR has a linked work item. Option A is incorrect because the 'Require a linked work item' branch policy does not apply to direct pushes; it only applies to pull request completions.

Answer

Add a branch policy on main that requires a linked work item for all pushes.

Answer

Create a pre-receive hook in the repository to reject commits without a work item.

Answer

Enable the 'Gated check-in' option in the branch policy for main.

Question 6

Your team uses GitHub and wants to automatically label pull requests based on the content of the changes (e.g., 'frontend' for changes in /frontend folder, 'backend' for /backend). Which approach should you use?

Accepted Answer

Create a GitHub Actions workflow that runs on pull_request events and uses an action like 'actions/labeler' to add labels based on path patterns.. GitHub Actions provides a native, event-driven way to automate labeling based on pull request changes. The 'actions/labeler' action specifically inspects file paths in the diff and applies labels defined in a configuration file, making it the simplest and most maintainable solution for path-based labeling.

Answer

Use branch protection rules to require specific labels based on branch name patterns.

Answer

Set up a webhook that triggers an Azure Function to parse the pull request diff and add labels.

Answer

Use a CODEOWNERS file to assign labels based on file paths.

Question 7

Your team uses Azure DevOps and wants to enforce that all changes to the main branch go through a pull request process with at least two approvals. They also want to prevent contributors from approving their own pull requests. Which branch policy settings should they use?

Accepted Answer

Enable 'Require a minimum number of reviewers' set to 2, and enable 'Allow users to approve their own changes' unchecked (or set to false).. It directly addresses both requirements: setting 'Require a minimum number of reviewers' to 2 enforces at least two approvals, and unchecking 'Allow users to approve their own changes' prevents contributors from approving their own pull requests. These are branch policy settings within Azure Repos that control the pull request workflow on the main branch.

Answer

Enable 'Check for linked work items' and 'Require a minimum number of reviewers' set to 2, and enable 'Reset code reviewer votes when new changes are pushed'.

Answer

Add the 'main' branch to the 'Required reviewers' list and add all developers as required reviewers.

Answer

Enable 'Require a minimum number of reviewers' set to 2, and enable 'Build validation' with a required build.

Question 8

Your GitHub organization has multiple repositories that share common CI/CD workflows. You want to centralize these workflows to reduce duplication. Which TWO approaches are valid?

Accepted Answer

Create reusable workflows in a central repository and use the 'uses' keyword in each repository's workflow to reference them.. GitHub Actions supports reusable workflows that can be stored in a central repository and referenced from other repositories using the 'uses' keyword with the syntax 'owner/repo/.github/workflows/workflow.yml@ref'. This allows teams to define common CI/CD logic once and invoke it across multiple repositories, reducing duplication and simplifying maintenance.

Answer

Store the workflows in a central repository and use Git submodules to include them in each repository.

Answer

Use branch protection rules to enforce that all workflows must be reviewed by a central team.

Answer

Publish the workflows as a GitHub Actions workflow library and install it in each repository.

Question 9

Refer to the exhibit. You are reviewing a branch protection rule for the main branch of a GitHub repository. A developer complains that after pushing new commits to an existing pull request, the existing approvals from two reviewers are dismissed, and the pull request cannot be merged even though the CI checks pass. What is the most likely cause?

Accepted Answer

The 'dismiss_stale_reviews' setting is enabled, which dismisses approvals when new commits are pushed.. The 'dismiss_stale_reviews' setting in GitHub branch protection rules automatically dismisses existing pull request approvals when new commits are pushed to the branch. This explains why the developer sees approvals removed after pushing new commits, even though CI checks pass. The setting is designed to ensure that reviewers re-evaluate changes after updates.

Answer

The 'strict' setting requires the branch to be up to date with the base branch, which is not the case.

Answer

The code owner review is required but no code owner has reviewed.

Answer

The CI check 'continuous-integration/jenkins/pr-merge' failed.

Question 10

Your organization uses Azure DevOps for a large-scale e-commerce platform. The source code is stored in a single Azure Repos Git repository with over 100 contributors. The current branching strategy is a modified GitFlow with main, develop, release, and hotfix branches. However, the team is experiencing frequent merge conflicts and long integration periods. You have been asked to redesign the branching strategy to support continuous integration and deployment (CI/CD) while ensuring high-quality releases. The new strategy must reduce merge conflicts, enable fast feedback, and support hotfixes. The team uses feature flags to manage incomplete features. Which branching strategy should you recommend?

Accepted Answer

Implement trunk-based development: developers work on short-lived feature branches (less than a day) and merge to main multiple times a day. Use feature flags to control release of incomplete features. Hotfixes are created from main and merged back quickly.. Trunk-based development with short-lived feature branches (less than a day) and frequent merging to main directly addresses the team's merge conflicts and long integration periods. Feature flags allow incomplete features to be merged safely, enabling continuous integration and fast feedback. Hotfixes from main are simple and quick. Option B is wrong because committing directly to main without branches increases risk of breaking the main branch, even with CI, and does not provide isolation for work-in-progress. Option C is wrong because using release branches introduces long-lived branches and delays integration, contrary to the need for fast feedback and continuous deployment. Option D is wrong because GitFlow's long-lived feature and release branches are the root cause of the frequent merge conflicts and integration delays.

Answer

Use a single main branch and allow developers to commit directly to main, but require all commits to be small and pass CI. Hotfixes are committed directly to main.

Answer

Use a single main branch and create release branches from main for each deployment. Feature branches are merged to release branches, and then release branches are merged to main after deployment.

Answer

Continue using GitFlow but enforce stricter branch policies and require more frequent merges.

Question 11

Your company is a startup developing a mobile application with a small team of 5 developers. You use GitHub Free and want to implement a simple but effective branching strategy that supports continuous delivery. The team wants to release new features every week and be able to hotfix critical bugs quickly. They currently have a main branch and feature branches, but sometimes features are merged to main before they are fully tested, causing issues. You need to recommend a strategy that minimizes risk while keeping the process lightweight. The team does not want to use long-lived branches. What should you recommend?

Accepted Answer

Use GitHub Flow: developers create feature branches from main, open pull requests with required CI and at least one review, then merge to main. Hotfixes follow the same process.. GitHub Flow is the simplest and most effective strategy for a small team using GitHub Free that wants continuous delivery without long-lived branches. By requiring feature branches, pull requests with CI checks, and at least one review before merging to main, it ensures that all code is tested and reviewed before integration, preventing untested features from breaking main. Hotfixes follow the same lightweight process, allowing quick, safe patches without additional branch overhead.

Answer

Use a single main branch and create release branches for each weekly release; features are merged to release branches, then release branches are merged to main after testing.

Answer

Allow developers to commit directly to main but require all commits to pass CI and be reviewed by at least one other developer after the fact.

Answer

Adopt GitFlow with develop and release branches.

Question 12

Your team uses a monorepo in Azure Repos. Developers frequently commit directly to the main branch, causing build failures. You need to enforce a policy that requires all changes to go through pull requests with at least one reviewer. What should you configure?

Accepted Answer

Configure a branch policy on the main branch to require a minimum number of reviewers.. Azure Repos allows you to configure branch policies on specific branches (like main) to enforce that all changes must come through pull requests and require a minimum number of reviewers. This directly addresses the need to prevent direct commits to main and ensure code review before merging.

Answer

Configure a repository policy to require a pull request for all branches.

Answer

Create a service hook to reject commits to main that are not from pull requests.

Answer

Enable the 'Require a minimum number of reviewers' setting in the project settings.

Question 13

Which TWO Git commands are commonly used to incorporate changes from a remote repository into your local branch while keeping history linear?

Accepted Answer

git pull --rebase. `git pull --rebase` (A) is correct because it fetches changes from the remote and then replays your local commits on top of the fetched commits, resulting in a linear history without merge commits. `git rebase` (E) is correct because it directly rewrites commit history by moving or combining a sequence of commits onto a new base, which can be used to incorporate remote changes linearly when combined with `git fetch`.

Answer

git fetch

Answer

git merge

Answer

git cherry-pick

Question 14

Which THREE practices are recommended when implementing a Git branching strategy for a team using Azure Repos?

Accepted Answer

Delete branches after they are merged.. The three recommended practices are: A) Delete branches after they are merged to keep the repository clean; C) Use short-lived feature branches that are merged within a day to reduce merge conflicts and promote continuous integration; E) Require build validation on pull requests to the main branch to ensure code quality. B is incorrect because force pushes should be avoided on shared branches as they can rewrite history and disrupt collaboration. D is incorrect because keeping feature branches alive for the entire sprint increases complexity and delays integration.

Answer

Allow force pushes to shared branches to clean up history.

Answer

Keep feature branches alive for the entire sprint.

Question 15

Refer to the exhibit. You have a branch policy JSON for Azure Repos. Which statement about this policy is correct?

Accepted Answer

At least two reviewers must approve the pull request.. The branch policy JSON specifies `minimumApproverCount: 2`, which enforces that at least two distinct reviewers must approve the pull request before it can be completed. This is a standard Azure Repos branch policy setting that controls the required number of approvals, not the identity of the approvers or the merge strategy.

Answer

The last person who pushed can approve the pull request.

Answer

Pull requests to main are automatically squash-merged.

Answer

Approvals are reset when the source branch is updated.