AZ-400 Questions 71-80: Repositories, Permissions, and DevOps Metrics

This set goes back to the first two AZ-400 domains with harder, more specific scenarios: permissions and roles in GitHub and Azure DevOps, teams and projects, CODEOWNERS and rulesets, scaling large Git repositories, cleaning history, automated release notes, integrations through service hooks, and the DORA metrics that show how well a team delivers. These are the details that separate a pass from a near-miss.

This is the eighth post in our AZ-400 series (Questions 71-80). The previous set, AZ-400 Questions 61-70: Monitoring, Application Insights, and KQL, covers Azure Monitor and KQL. Every question here is an original practice scenario, not a copy of a real exam item.

Question 71: Measuring Delivery Performance

Contoso’s leadership wants four metrics that show how fast and how safely the team delivers software: how often it deploys, how long a commit takes to reach production, how often deployments cause failures, and how fast service is restored. What are these metrics commonly called?

A) Sprint velocity metrics

B) DORA metrics

C) Code coverage metrics

D) Burndown metrics

👁 Reveal Answer

Correct Answer: B

Explanation: The DORA metrics, from the DevOps Research and Assessment program, are deployment frequency, lead time for changes, change failure rate, and time to restore service. They balance speed with stability. A measures planned work completed per sprint. C measures how much code tests exercise. D tracks remaining work. The AZ-400 outline asks you to design dashboards with flow metrics such as cycle time, lead time, and time to recovery — DORA metrics fit there.

Question 72: Triage Without Code Access

Fabrikam’s support lead must label, assign, and close issues and pull requests in a GitHub repository, but must not push code. Which repository role is the least-privileged fit?

A) Read

B) Write

C) Triage

D) Maintain

👁 Reveal Answer

Correct Answer: C

Explanation: GitHub’s repository roles, from least to most access, are Read, Triage, Write, Maintain, and Admin. Triage lets someone manage issues and pull requests — labels, assignees, closing and reopening — without write access to code. A cannot manage issues beyond commenting. B and D both grant push access, which the requirement rules out.

Question 73: Requiring Experts to Review Their Code

Northwind Traders wants any pull request that changes files under /infra/ to be approved by the platform team, and changes under /payments/ by the payments team, in a GitHub repository. What should you configure?

A) A CODEOWNERS file plus a branch protection rule or ruleset that requires review from code owners

B) A .gitignore entry for each folder

C) Separate forks for each team

D) A GitHub Actions workflow that emails both teams on every push

👁 Reveal Answer

Correct Answer: A

Explanation: A CODEOWNERS file maps paths to the people or teams responsible for them, and GitHub automatically requests their review on matching pull requests. Turning on “require review from code owners” in a branch protection rule or ruleset makes that approval mandatory before merge. B stops files from being tracked at all. C splits the codebase and makes collaboration harder. D notifies people but enforces nothing. Azure Repos achieves the same with automatically included reviewers in branch policies.

Question 74: Giving Developers the Right Azure DevOps Access

New developers at Woodgrove Bank must be able to push code, create branches, and queue builds in one Azure DevOps project, but must not change project settings or security. Which security group should they join?

A) Project Administrators

B) Readers

C) Project Collection Administrators

D) Contributors

👁 Reveal Answer

Correct Answer: D

Explanation: The Contributors group is the default for project members who add and change code, work items, and pipelines, without administrative rights. A can change project settings and security. B can only view. C has administrative control over the whole organization. Remember that permissions also depend on access levels: a contributor needs at least Basic access to use Azure Repos, while Stakeholder access does not include code in private projects.

Question 75: One Project, Several Teams

Adventure Works has one Azure DevOps project with three squads. Each squad needs its own backlog, board, and sprint schedule, while sharing the same repositories and pipelines. What should you configure?

A) Three separate Azure DevOps organizations

B) Three teams in the project, each with its own area path and iterations

C) Three repositories with no teams

D) One team with three different dashboards

👁 Reveal Answer

Correct Answer: B

Explanation: Teams within a project each get their own backlog, boards, and dashboards. Assigning each team an area path controls which work items appear on its backlog, and selecting iterations sets its sprint cadence — all while the project’s repositories and pipelines stay shared. A splits everything apart and makes sharing hard. C separates code but gives no separate planning. D still mixes all work into one backlog.

Question 76: A Very Large Repository

Tailspin Toys’ monorepo has millions of files and years of history. Clones, fetches, and git status are painfully slow, but splitting the repository is not an option yet. What should developers use?

A) Scalar, which configures partial clone, sparse-checkout, and background maintenance

B) A new repository for every feature

C) Disabling Git compression

D) Deleting the .git folder after each clone

👁 Reveal Answer

Correct Answer: A

Explanation: Scalar ships with Git and sets up a repository for scale: partial clone downloads objects only when needed, sparse-checkout limits the working tree to the folders you use, and background maintenance keeps the repository optimized, making everyday commands much faster. B fragments the codebase. C makes transfers larger and slower. D destroys the repository’s history and Git functionality. Scalar appears in the AZ-400 outline under scaling and optimizing a Git repository.

Question 77: Moving Existing Large Files to LFS

A repository already contains hundreds of large .psd files committed over the past year. The team has now installed Git LFS and wants those files, including their history, moved into LFS. What should they run?

A) git lfs track "*.psd" only

B) git gc --aggressive

C) git revert on each commit that added a .psd file

D) git lfs migrate import --include="*.psd", then force-push the rewritten history after coordinating with the team

👁 Reveal Answer

Correct Answer: D

Explanation: git lfs migrate import rewrites history so that matching files in past commits become LFS pointers, which actually shrinks the repository. Because history changes, everyone must re-clone or reset after the force-push, so plan it with the team. A only affects files added from now on; old versions stay in history. B compresses objects but keeps every large file. C adds new commits that undo changes but leaves the large files in history.

Question 78: Release Notes Without Manual Work

Coho Winery publishes GitHub releases every two weeks. Writing release notes by hand takes hours. The team wants notes generated from the merged pull requests, grouped into categories such as Features and Bug Fixes by label. What should they use?

A) A wiki page edited after each release

B) GitHub’s automatically generated release notes, configured with a .github/release.yml file

C) The repository’s README file

D) A git tag with no message

👁 Reveal Answer

Correct Answer: B

Explanation: GitHub can generate release notes from the merged pull requests and contributors since the previous release. A .github/release.yml file defines categories based on labels and can exclude certain labels or authors. This is the “automate creation of documentation from Git history” skill. A is manual. C is not a release history. D marks a commit but contains no notes. In Azure Pipelines, a similar result is possible with a pipeline step that builds notes from linked work items and commits.

Question 79: Calling an External System on Events

Litware wants its internal ticketing system to receive an HTTP POST every time a pull request is completed in Azure Repos, so tickets can be closed automatically. What should you configure?

A) A service hook subscription that sends a web hook on the pull request merge event

B) A branch policy requiring a linked work item

C) A scheduled pipeline that checks for merged pull requests every hour

D) A dashboard widget showing completed pull requests

👁 Reveal Answer

Correct Answer: A

Explanation: Service hooks let Azure DevOps call external services when events happen — code pushed, pull request merged, build completed, work item updated. A web hook subscription sends the event as JSON to any HTTP endpoint the ticketing system exposes. B improves traceability but does not notify external systems. C polls with a delay and costs agent time. D only displays information. In GitHub, the equivalent is a repository or organization webhook.

Question 80: Tagging Releases in Git

Your team wants every production release marked in Git with its version number, the person who created it, the date, and a short message, so that the exact released code can always be found later. What should you create?

A) A lightweight tag

B) A new branch for each commit

C) An annotated tag, such as git tag -a v2.4.0 -m "Release 2.4.0"

D) A note in the commit message only

👁 Reveal Answer

Correct Answer: C

Explanation: Annotated tags are full Git objects that store the tagger’s name, email, date, and a message, and they can be signed — ideal for marking releases. A lightweight tag is only a named pointer to a commit with no extra information. B creates clutter and branches can move, so they do not mark a fixed point. D mixes release information into commit text and is hard to search reliably. Tags also help organize a repository and give the hotfix path a reliable starting point.

Study Tips for Repositories, Permissions, and Metrics

• Know the GitHub role ladder. Read, Triage, Write, Maintain, Admin — pick the lowest that does the job.
• Know the Azure DevOps groups. Readers, Contributors, Project Administrators, Project Collection Administrators, combined with access levels such as Stakeholder and Basic.
• Enforce ownership. CODEOWNERS plus required code owner review in GitHub; automatically included reviewers in Azure Repos.
• Remember the history tools. git lfs migrate moves old large files into LFS; git filter-repo removes data; both rewrite history.
• Memorize the four DORA metrics. Deployment frequency, lead time for changes, change failure rate, and time to restore service.

Keep Practicing for AZ-400

Continue with AZ-400 Questions 81-90: Containers, GitHub Actions, and Advanced Pipelines. For reference, GitHub’s documentation on code owners pairs well with Question 73.