AZ-400 Questions 1-10: DevOps Processes and Source Control

DevOps is mostly about people and flow, and the AZ-400 exam starts there. Before you write a single YAML pipeline, Microsoft expects you to choose a branching strategy, connect work items to code, measure how work moves, and protect the main branch from risky changes. Together, the processes and communications and source control domains make up roughly a quarter of the exam, and they are where many candidates lose easy points.

This is the first post in our new AZ-400 series (Questions 1-10). We focus on GitHub Flow and trunk-based development, Azure Boards metrics and traceability, branch policies, Git Large File Storage, recovering lost commits, and what to do when a secret lands in your repository. Every question is an original scenario written for practice — not a copy of a real exam item.

Commit to an answer before you reveal it. Then read the explanation for every option, including the ones you ruled out — on AZ-400, the wrong answers are usually real features used in the wrong place.

Question 1: Choosing a Lightweight Branching Workflow

Contoso’s web team deploys several times a day. They want a simple workflow: developers create a short-lived branch from main, open a pull request for review, and merge back to main, which is always deployable. Which workflow matches this description?

A) GitFlow

B) GitHub Flow

C) Release branching with long-lived version branches

D) Forking workflow with a separate repository per developer

👁 Reveal Answer

Correct Answer: B

Explanation: GitHub Flow uses a single long-lived branch (main) that is always deployable, plus short-lived topic branches that merge back through pull requests. That is exactly the cycle described. A, GitFlow, adds long-lived develop, release, and hotfix branches, which is heavier than this team needs. C keeps a branch per shipped version so older releases can be patched, which suits products with several supported versions, not continuous web deployment. D is common in open-source projects where contributors lack write access, but it adds overhead an internal team with shared access does not need.

Question 2: Azure Boards Flow Metrics

Fabrikam’s engineering manager adds an Azure Boards analytics widget to the team dashboard. She wants to know how long work items take from the moment a developer starts working on them until they are completed — not including the time they wait in the backlog. Which metric should she use?

A) Lead time

B) Cycle time

C) Velocity

D) Burndown

👁 Reveal Answer

Correct Answer: B

Explanation: In Azure Boards, cycle time measures how long a work item takes from when work starts (it first enters an In Progress state) until it is completed. A, lead time, starts earlier — when the work item is created — so it includes backlog wait time, which the manager wants to exclude. C measures how much work (for example, story points) a team completes per sprint, not how long items take. D shows remaining work over time within a sprint or release. Remember the pair for the exam: lead time starts at creation, cycle time starts when work begins.

Question 3: Linking GitHub Commits to Azure Boards

Northwind Traders plans work in Azure Boards but stores its code in GitHub. The Azure Boards app is already installed and connected to the GitHub repository. A developer wants a commit to appear on work item 482 automatically. What should the developer include in the commit message?

A) #482

B) AB#482

C) WI-482

D) fixes 482

👁 Reveal Answer

Correct Answer: B

Explanation: With the Azure Boards and GitHub integration, the AB#{ID} syntax in a commit message, pull request title, or description links that GitHub item to the Azure Boards work item. Adding a state keyword such as Fixes AB#482 in a pull request can also move the work item to Done when the PR merges. A references a GitHub issue or pull request number in that repository, not an Azure Boards item. C is not a recognized syntax. D has no AB# prefix, so nothing gets linked. Watch for A on the exam — #482 looks right but points to GitHub, not Azure Boards.

Question 4: Diagrams in an Azure DevOps Wiki

Your team documents its release process in an Azure DevOps project wiki. You want the process diagram stored as plain text so changes are reviewed in pull requests like any other Markdown file. Which option should you use?

A) Mermaid syntax inside the wiki page

B) An embedded Visio file

C) A PNG exported from a drawing tool

D) A PowerPoint slide linked from the page

👁 Reveal Answer

Correct Answer: A

Explanation: Azure DevOps wikis render Mermaid diagrams written as text in a ::: mermaid block. Because the diagram is just text in the Markdown file, every change shows up as a readable diff in a pull request — exactly what the team wants, and Mermaid syntax is named in the AZ-400 skills outline. B, C, and D are all binary files: they can be stored or linked, but a reviewer cannot see what changed line by line, and they drift out of date easily.

Question 5: Protecting the Main Branch in Azure Repos

Woodgrove Bank stores code in Azure Repos. Compliance requires that every change to main is reviewed by at least two people and passes an automated build before it is merged. Developers must still be able to push to their own feature branches. What should you configure?

A) Deny the Contribute permission on main for all developers

B) Branch policies on main: a minimum of two reviewers and a build validation policy

C) A service hook that emails reviewers when a commit is pushed

D) A scheduled pipeline that builds main every night

👁 Reveal Answer

Correct Answer: B

Explanation: Branch policies are the Azure Repos control for this requirement. Once any required policy is set on main, changes must arrive through a pull request; the minimum-reviewers policy enforces two approvals, and build validation queues a build and blocks completion if it fails. Feature branches stay unaffected. A blocks direct pushes but does not require reviewers or a passing build — and it can block pull request completion if set too broadly. C only notifies people; it does not enforce anything. D catches problems after they are already merged. The GitHub equivalent of B is branch protection rules (or rulesets) requiring reviews and status checks.

Question 6: Integrating Unfinished Work Safely

Adventure Works wants developers to merge into main at least once a day to avoid painful merge conflicts. However, some features take several weeks to finish and must not be visible to customers until they are ready. Which approach meets both goals?

A) Long-lived feature branches merged at the end of each feature

B) Trunk-based development with feature flags

C) A separate release branch for every feature

D) Cherry-picking finished commits into main weekly

👁 Reveal Answer

Correct Answer: B

Explanation: Trunk-based development keeps everyone merging small changes into main frequently, which keeps conflicts small. Feature flags (for example, with Azure App Configuration) let unfinished code ship to production turned off, so customers never see it until the flag is switched on. A is the pattern that causes large, painful merges — the problem the team is trying to avoid. C multiplies long-lived branches. D delays integration and makes it hard to know which commits depend on each other.

Question 7: Large Binary Files in Git

A game studio at Tailspin Toys commits large texture and audio files to its Git repository. Clones now take a long time and the repository keeps growing with every new version of each asset. The team wants to keep these files under version control. What should you implement?

A) Git Large File Storage (LFS)

B) Git submodules

C) Running git gc after each commit

D) A .gitignore rule for the asset folders

👁 Reveal Answer

Correct Answer: A

Explanation: Git LFS replaces large files in the repository with small pointer files and stores the actual content on a separate LFS server. Clones download only the versions they need, so repository size and clone time stay manageable while the files remain versioned. Both Azure Repos and GitHub support LFS. B splits code into separate repositories but does not reduce the cost of binary history. C compresses objects but cannot avoid storing every version of every large file. D stops tracking the files entirely, which breaks the requirement to keep them under version control.

Question 8: A Secret Committed to the Repository

A developer at Litware accidentally committed a storage account key to a shared repository and pushed it. The commit is already on the remote. What should you do first?

A) Rewrite the repository history with git filter-repo and force-push

B) Revoke or rotate the exposed key

C) Add a new commit that deletes the file containing the key

D) Make the repository private

👁 Reveal Answer

Correct Answer: B

Explanation: Once a secret is pushed, assume it is compromised — anyone who cloned or fetched the repository already has it. Rotating or revoking the key is the only step that actually removes the risk, so it comes first. A is the right follow-up to remove the key from history, but it does not invalidate copies that already exist. C leaves the key fully visible in earlier commits. D limits future exposure but does nothing about people who already have it. To prevent a repeat, enable secret scanning with push protection and store secrets in Azure Key Vault instead of code.

Question 9: Recovering a Lost Commit

A developer ran git reset --hard on their local branch and lost two commits that were never pushed. They need to get those commits back. Which command helps them find the lost commits?

A) git reflog

B) git log --all

C) git revert HEAD~2

D) git fetch --prune

👁 Reveal Answer

Correct Answer: A

Explanation: The reflog records every position HEAD and branch tips have pointed to in the local repository, including commits no longer reachable from any branch. The developer can find the commit hash in git reflog, then restore it with git reset --hard <hash> or git branch recovered <hash>. B only shows commits reachable from existing references, so the orphaned commits do not appear. C creates new commits that undo earlier ones — the opposite of recovery. D talks to the remote, which never received these unpushed commits.

Question 10: Pipeline Alerts in Microsoft Teams

Coho Winery’s operations team wants a message in their Microsoft Teams channel whenever an Azure Pipelines run fails. They want to configure this from Teams with no custom code. What should they use?

A) The Azure Pipelines app for Microsoft Teams with a subscription for failed runs

B) An Azure Function that polls the Azure DevOps REST API every minute

C) Personal email notifications forwarded to the channel by each engineer

D) A wiki page that lists the latest pipeline results

👁 Reveal Answer

Correct Answer: A

Explanation: The Azure Pipelines app for Microsoft Teams lets a channel subscribe to pipeline events — such as failed runs — and posts a notification card each time one occurs, all configured from Teams without code. B works but is custom code that someone has to maintain, which the scenario rules out. C depends on individuals and is unreliable. D is passive documentation; nobody gets alerted. For other events, the same idea applies: the Azure Boards app for Teams covers work items, and service hooks or webhooks handle integrations the apps do not cover.

Study Tips for AZ-400 Processes and Source Control

• Know the branching strategies by their trade-offs. GitHub Flow and trunk-based development favor frequent integration; release branches support several shipped versions; GitFlow is the heaviest.
• Memorize lead time versus cycle time. Lead time starts when the work item is created; cycle time starts when work begins.
• Map each control to its platform. Azure Repos uses branch policies; GitHub uses branch protection rules and rulesets. The goals are the same, but the names appear in different answers.
• Treat leaked secrets as compromised. Rotate first, clean history second, prevent recurrence third.
• Practice the Git recovery commands yourself. Run git reflog, git reset, and git revert in a test repository so the exam options feel familiar.

Keep Practicing for AZ-400

Build and release pipelines make up about half of the AZ-400 exam, so that is where this series goes next, in Questions 11-20. Meanwhile, review the official AZ-400 study guide to see every skill measured, and read Microsoft’s guide to branch policies and settings alongside Question 5.

AZ-400 builds on administrator-level Azure knowledge. If you need to strengthen that foundation, work through our AZ-104 identities and governance questions and the AZ-104 monitoring and recovery set, which pairs well with the instrumentation domain of AZ-400.