The setting

Pinwheel Tickets sells tickets for about 120 regional theaters and music venues. A six-person engineering team runs a Node web app plus two services on a small Kubernetes cluster, and big on-sale mornings can multiply traffic five times over.

Every mission on this path happens at the same company, so context carries over the way it does in a real job: the data you cleaned in mission two is the data the finance lead questions in mission four.

The missions

1. pipeline designstarter

Redesign the slow, flaky CI pipeline at Pinwheel

You are the DevOps engineer at Pinwheel Tickets. Every merge to main takes about 25 minutes to reach production, engineers have started batching changes to avoid the wait, and one flaky test keeps failing runs that pass on retry.

You deliver: A pipeline design document that restructures stages, caching, artifacts, and branch rules, with a timed estimate under 15 minutes.

Scored on: Finds the real waste, Flake handling, Branch and deploy rules, Credible time estimate.

Working from: ci_config.md, pipeline_runs.csv.

2. container checkstarter

Review the checkout service container before it ships

A teammate is containerizing pinwheel-checkout, the service that takes card payments, and asked you to review before it goes to the cluster. Checkout is the one service Pinwheel cannot afford to get wrong.

You deliver: A ranked container review note listing each issue with its source line and a concrete fix.

Scored on: Catches the blockers, Image hygiene, Concrete fixes, Fair review.

Working from: dockerfile_review.md, deploy_manifest.md.

3. deployment plancore

Plan the seat map service launch around on-sale week

The new seat map service must be live and stable before the Harbor Amphitheater general sale on Saturday August 1 at 10:00, the biggest sale of the summer at an expected 4,600 requests per second. A botched deploy during any on-sale burns real ticket revenue and venue trust.

You deliver: A deployment plan with sequenced steps, a justified time window, a flag ramp, verification checks, and abort criteria.

Scored on: Correct sequence, Window choice, Flag ramp, Abort criteria.

Working from: release_notes.md, on_sale_calendar.csv.

4. rollbackcore

Rewrite the rollback runbook after the release 2.31 mess

On May 14 a rollback that should have taken five minutes took nearly an hour of degraded checkout, 41 support tickets, and a silent status page. The postmortem is done; your job is the fix. The current rollback checklist is four lines long and missed everything that actually went wrong.

You deliver: A rollback runbook with preconditions, decision criteria, ordered owned steps, and communications, each grounded in the May 14 incident.

Scored on: Closes the real gaps, Migration compatibility gate, Communication steps, Grounded and owned.

Working from: incident_timeline.md, rollback_checklist.md.

5. monitoringstretch

Build the monitoring plan before on-sale season

On-sale season starts in six weeks and traffic will run five times normal. The last two incidents were both discovered by people, not alerts: customers found the June 2 checkout outage and an engineer found the June 19 batch failure the next morning. Meanwhile the on-call phone rings for CPU spikes nobody acts on.

You deliver: A monitoring plan with checkout SLOs, add/retune/delete alert lists justified by the fire-and-action data, and a paging policy.

Scored on: Covers checkout, Cuts the noise, Fixes dead and late alerts, Paging policy.

Working from: alert_inventory.csv, incident_review.md.

How the scoring works

Each deliverable is graded against the rubric written for that mission. Separately, every mission on every path is graded on how you used AI, against the same four criteria:

  • Understood the task. The learner framed the goal for the assistant clearly instead of pasting the brief and hoping.
  • Grounded in the material. The learner directed the assistant into the provided files and based the work on them, not on invented facts.
  • Verified the output. The learner checked claims, numbers, or coverage against the source material before submitting.
  • Iterated with judgment. The learner refined weak parts of the draft with specific follow-ups rather than accepting the first answer.

Both scores, with the work behind them, go on your proof profile. That is what makes a claim like "I can use AI for devops" something an employer can check.