The blueprint
A mock exam here has 50 questions in 100 minutes, split across the domains in the same proportions as the official exam guide. The official pass mark is 700 of 1,000 (scaled). FixOps scores practice against a target of 72%.
-
01
Design and Implement Processes and Communications
-
02
Design and Implement a Source Control Strategy
-
03
Design and Implement Build and Release Pipelines
-
04
Develop a Security and Compliance Plan
-
05
Implement an Instrumentation Strategy
Sample questions
Three of the 10 questions in the free diagnostic. Open one to see the answer and why.
A team wants a lightweight workflow: short-lived branches from main, a pull request for every change, and main always deployable. Which flow describes this?
- A long-lived branch per environment
- Committing directly to main with tags
- GitHub Flow
- Gitflow with develop and release branches
Answer: GitHub Flow. GitHub Flow keeps one long-lived branch, main, and does all work in short branches merged through reviewed pull requests. Gitflow adds develop, release and hotfix branches, which suits scheduled releases rather than continuous delivery.
A team deploys several times a day and wants to avoid painful merges. Which branching strategy fits?
- A release branch for every commit
- Developing each feature for months in its own long-lived branch
- One long-lived branch per developer
- Trunk-based development with short-lived branches
Answer: Trunk-based development with short-lived branches. Trunk-based development merges small changes into main often, hiding unfinished work behind feature flags, which keeps merges small and main releasable.
A company hosts its code in GitHub and wants private npm and container packages next to the repositories, with access controlled by the same permissions. What fits?
- A shared network drive
- Azure Artifacts with a public feed
- GitHub Packages
- Pipeline artifacts kept for 30 days
Answer: GitHub Packages. GitHub Packages hosts npm, NuGet, Maven, RubyGems and container images (ghcr.io) with GitHub's permission model. Azure Artifacts fits teams centered on Azure DevOps.
Revision notes: Design and Implement Processes and Communications
The notes for one domain, free to read here and in the app. FixOps Pro has them for all 5 domains.
Planning and tracking work in Azure Boards and GitHub, linking work to code and builds, measuring flow and delivery, and keeping documentation and notifications close to the work.
Processes and work items
- Each Azure DevOps process has its own backlog item: Agile uses User Stories, Scrum uses Product Backlog Items, CMMI uses Requirements and Basic uses Issues.
- Scrum adds Impediments; CMMI adds Change Requests, Risks and Reviews.
- GitHub Flow keeps main always deployable, with short-lived branches merged through reviewed pull requests. Gitflow adds develop, release and hotfix branches for scheduled releases.
- Tree queries show parent and child items nested; flat lists show items without links; direct links queries show other link types such as related or dependency.
- Query charts are built on flat-list queries and can be added to dashboards, where they update with the data.
Linking GitHub and Azure Boards
- Connect the Azure DevOps project to GitHub repositories through the Azure Boards app before any linking works.
- AB#125 in a commit message, pull request description or issue description links that item to work item 125. A bare #125 refers to a GitHub issue instead.
- A keyword such as Fixes, Fix or Fixed before AB#412 moves the work item to its done state when the pull request merges.
- A branch policy that requires linked work items, plus builds that record their commits, lets you trace a requirement to the deployment that shipped it.
Flow and delivery metrics
- Lead time starts when a work item is created; cycle time starts when work on it begins. Both end when it is completed.
- A cumulative flow diagram stacks items per state over time. A band that keeps widening shows work piling up in that stage.
- Work-in-progress limits on board columns make overload visible and push the team to finish before starting more.
- The DORA metrics pair speed (deployment frequency and lead time for changes) with stability (change failure rate and time to restore service).
- Pipeline test analytics show pass rates, failing tests and flaky tests over time. Mean time to remediate, by severity, tracks security work.
Documentation and communication
- A code wiki publishes a folder of a repository branch, so pages are versioned and changed through pull requests. The project wiki lives in its own repository.
- The wiki renders Mermaid diagrams written as text in a ::: mermaid block, such as flowcharts and sequence diagrams.
- Release notes and changelogs can be generated in the pipeline from linked work items, commits and structured commit messages such as Conventional Commits.
- Service hooks send events such as build completed or work item updated to web hooks, Teams, Slack and other services.
- The Azure Boards app for Teams and the GitHub app for Teams bring work items and repository events into channels.
- Personal and team notification subscriptions decide which events, such as build failures, send email.
Easy to mix up
- AB#125 links to Azure Boards; #125 links to a GitHub issue in the same repository.
- Lead time is the customer's wait from creation; cycle time is the team's working time from the first active state.
- A service hook sends an event to another service; a notification subscription sends an email to people.
- Project wiki: its own hidden repository. Code wiki: Markdown published from your repository and reviewed in pull requests.