The GitOps Readiness Audit: Twelve Checks and a Score

A platform lead I will call Anouk — not her real name, though the situation is real enough — opened our coaching call with a question that deserved better than a shrug: “My director read about GitOps and now wants to know how ready we are. How do I answer that without guessing?” We spent the session turning her hunch into an audit. This post is that audit, written up so you can run it on your own team this week: a maturity ladder to locate yourselves on, twelve concrete checks, honest scoring bands, and the plan Anouk actually followed when her score came back mediocre. Print it, argue with it, mark it up — a checklist you disagree with is still more useful than a vibe.

First, Find Your Rung: The GitOps Maturity Ladder

Readiness only means something when measured against a scale, and the community has converged on a five-rung ladder that is easy to explain in a corridor conversation:

• Level 0 — Scripted. Deploys run from scripts and pipelines; nothing states what should be running. Most teams start here without shame.
• Level 1 — Declared. configuration lives as declarative files in a versioned store, even if nothing enforces the match yet.
• Level 2 — Reconciled. an agent pulls the declaration and corrects the difference continuously. This is where the model starts paying rent.
• Level 3 — Governed. authority is scoped, deletion is guarded, drift has a written policy, and break-glass paths are rehearsed.
• Level 4 — Assured. the practice is verified regularly: rebuild drills from the repository alone, rotated keys, measured recovery.

Anouk’s team, she admitted midway through describing their setup, sat between levels one and two — everything declared, a couple of clusters reconciled, nothing governed. The ladder matters because it converts a vague management question (“are we doing GitOps?”) into an honest one (“which rung are we on, and what would move us up?”). The Ops Atlas GitOps guide uses the same shape of progression in its adoption material, which made the vocabulary easy to defend upstairs.

The Twelve Checks of the GitOps Readiness Audit

Run each check and record pass, partial or fail. Evidence beats memory — ask to see the thing, not the intention.

1. A single declared store exists. One repository (or registry) holds what should run. If configuration is scattered across repos, wikis and someone’s laptop, fail.
2. The store is versioned and effectively immutable. Force-pushes disabled, history preserved. A store that forgets cannot be a source of truth.
3. An agent reconciles at least one real environment. Not a sandbox. The reconciler must be pulling and correcting somewhere production-adjacent.
4. The reconciler manages its own configuration. The day the tool upgrades itself through the repository is the day you stop maintaining it by hand.
5. Environments are directories, not branches. Look at the repository layout. Long-lived environment branches mean silent divergence.
6. No secrets sit in plaintext. Scan history if you must. Encrypted-in-repo or operator-synced credentials pass; a values file with a password does not.
7. Agent authority is scoped. Check the service accounts: if the reconciler holds cluster-admin across every namespace, mark partial and schedule the narrowing.
8. Deletion is guarded. Pruning off during migration, retain policies on volumes, and a review step that flags removed namespaces — at least one of these, ideally all.
9. Drift has a written policy. The policy should say, resource by resource, whether a difference is rolled back, accepted, or simply reported. Autoscaler-managed replica counts are the classic acceptance case; everything else needs a named owner. Unwritten policy means every drift becomes an argument.
10. A break-glass path exists and has been rehearsed. Suspending sync during an incident should be a drilled, documented action, not folklore.
11. Mutable references are banned and checked. A pipeline check for floating tags and unpinned charts earns the pass; good intentions do not.
12. Delivery is measured. Time from merge to healthy, drift counts, revert counts. Without numbers the audit is an opinion survey.

Three failure patterns show up again and again when teams run this audit on themselves, so name them before they surprise you. The first is the pilot illusion: a gleaming reconciled sandbox earns a pass on check three while nothing production-adjacent is actually managed — read that check strictly. The second is secret archaeology: credentials committed years ago survive in history even after the file is deleted, which is why the check says scan history if you must. The third is the unrehearsed break-glass: the runbook exists, everyone believes it works, and nobody has pressed the button outside an incident. That last one is the most expensive, because it fails precisely when the team can least afford failure.

Scoring Without Flattery

Score each check one point, half for partial, and read the total against three bands. Below six: the fundamentals are missing, and the honest move is to say so in the director’s meeting — adoption starts at level one, not level three. Six to nine: the engine runs but the guardrails lag, which is the most common shape and the most fixable. Ten or above: you are past adoption and into assurance, where the work is drills and measurement rather than installation. Anouk’s team scored seven, with two of the lost points on deletion guards and one on the unrehearsed break-glass path — a typical profile, and a good deal healthier than she had feared.

Two ground rules keep the score honest. First, evidence outranks intention: a check passes because you can show the configuration, the drill log or the dashboard, not because the person responsible is confident. Second, re-run the audit quarterly. Readiness decays quietly — a reorganisation re-scopes permissions, a migration reintroduces a branch, a hiring freeze empties the review queue — and a score that stood in spring can mislead by autumn. Anouk’s team put theirs in the quarterly review calendar next to key rotation, which is exactly the company it should keep.

Her 30/60/90 After a Mediocre Score

The plan that followed fits any team in the middle band, and it sequenced cleanly in her calendar. In the first month: write the decision record, adopt the directory layout, and put drift alerts on the reconciled staging environment — alerts before automation, so people learn what drift looks like. In the second: switch staging to automated sync, move secrets off plaintext, lock down tenant permissions, rehearse the break-glass suspension, and retire the CI pipeline’s cluster credentials. In the third: turn automated sync on for low-risk production services, add the prune guards, stand up a delivery dashboard, and run the first exercise of rebuilding a cluster using nothing but the repository. Ninety days, no heroics, and every step visible to the director who asked the original question. Anouk’s parting observation is the best summary I can offer: the audit did not make her team adopt GitOps — it made the adoption sequence obvious, which is most of what readiness means.

If this kind of structured self-assessment appeals, two resources on this site extend it well: the career path from junior to senior DevOps engineer, where audit-and-fix skills mark the senior step, and the roundup of certifications that accelerate a DevOps career, useful once the twelve checks have shown you which gaps are knowledge rather than process.