Skip to content

Production Readiness Review: Scoring Guide

How to Score

For each of the 50 questions in the assessment, rate yourself honestly:

Score Level Meaning
3 Strong Could answer confidently in an interview or incident with specific commands, steps, and reasoning. Could teach this to a teammate.
2 Adequate Know the general approach and key concepts but would need to look up specific commands, flags, or configuration details.
1 Weak Have heard of this area but could not walk through the troubleshooting steps or explain the underlying mechanism.
0 No idea Completely unfamiliar with this topic. Would not know where to start.

Scoring Tips

  • Be brutally honest. This assessment is for your benefit, not a performance review.
  • If you could "figure it out with enough Googling," that is a 1, not a 2. On-call does not wait for you to Google.
  • A 2 means you have done it before but not recently. A 3 means you could do it right now from memory under pressure.
  • Score based on the specific architecture described in architecture.md, not a generic environment.

Score Sheet

Copy this table and fill in your scores.

Section Questions Max Score Your Score
1. Kubernetes Operations Q1 -- Q10 30 ____
2. Observability Q11 -- Q18 24 ____
3. Networking Q19 -- Q25 21 ____
4. Linux & Infrastructure Q26 -- Q32 21 ____
5. Security Q33 -- Q38 18 ____
6. CI/CD & DevOps Tooling Q39 -- Q44 18 ____
7. Cross-Domain & Incident Response Q45 -- Q50 18 ____
TOTAL 50 questions 150 ____

Per-Section Thresholds

Use these to identify which sections need work:

Section Strong Adequate Needs Work Critical Gap
Kubernetes Operations (30) 24+ 18-23 10-17 < 10
Observability (24) 19+ 14-18 8-13 < 8
Networking (21) 17+ 12-16 7-11 < 7
Linux & Infrastructure (21) 17+ 12-16 7-11 < 7
Security (18) 14+ 10-13 6-9 < 6
CI/CD & DevOps Tooling (18) 14+ 10-13 6-9 < 6
Cross-Domain (18) 14+ 10-13 6-9 < 6

Readiness Levels

120-150: Ready

Verdict: You can go on-call with confidence.

You have strong practical knowledge across all domains. You know the system well enough to triage most incidents without escalation, and you understand the dependencies and failure modes that cause cascading issues. You are comfortable with the observability stack, can write PromQL queries, and know where to look when things break.

Next steps: - Shadow the current on-call for one rotation to learn team-specific procedures - Review the last 5 postmortems to understand recent failure patterns - Bookmark key Grafana dashboards and runbook entry points - Do one DR failover drill before your first solo rotation

90-119: Almost Ready

Verdict: You are close. Focus on your weak sections for 1-2 weeks.

You have a solid foundation but have gaps in 1-2 areas that would slow you down during an incident. These gaps are addressable with targeted study.

Next steps: - Identify sections scoring below the "Adequate" threshold - Follow the targeted study plan in study_plans.md for those sections - Re-take just the weak sections after 1-2 weeks - Shadow the current on-call, specifically requesting to handle incidents in your weak areas

60-89: Needs Work

Verdict: Significant gaps remain. Follow the structured study plan for 4-6 weeks.

You understand some areas well but have multiple domains where you would struggle during an incident. Going on-call now would mean frequent escalations and slow resolution times.

Next steps: - Follow the 4-week Fast Track study plan - Complete at least 3 case studies per week from the weak domains - Practice with hands-on labs and exercises, not just reading - Schedule a re-assessment after completing the study plan

0-59: Not Ready

Verdict: Start with the foundational learning path. On-call is not imminent.

Major gaps exist across most domains. This is completely normal for engineers new to production operations or transitioning from a different specialization.

Next steps: - Follow the 8-week Deep Track study plan - Start with the primer material for each topic before attempting street_ops or case studies - Focus on one domain per week rather than trying to cover everything at once - Build hands-on muscle memory with exercises and drills daily - Re-take the full assessment at weeks 4 and 8 to track progress


Score Interpretation Matrix

Use this matrix to understand the relationship between your total score and per-section scores:

High total, one low section

Example: Total 125, but Security section is 6/18.

This is the most dangerous pattern. Your overall confidence may mask a critical blind spot. A security incident would hit this gap hard. Prioritize the weak section immediately.

Even scores across all sections

Example: Every section scores "Adequate" (total ~100).

You are a generalist who needs depth. Pick the two sections most likely to cause 3 AM pages (usually Kubernetes Operations and Observability) and drive those to "Strong" first.

High Kubernetes, low everything else

Example: Kubernetes 28/30, all others below Adequate.

Common for engineers coming from a pure Kubernetes background. You can keep pods running but may struggle when the problem is in the network, the OS, the pipeline, or the security layer. Broaden systematically.

Low Kubernetes, high Linux/Networking

Example: Kubernetes 12/30, Linux 19/21, Networking 18/21.

Common for engineers transitioning from traditional ops. Your fundamentals are strong. Kubernetes-specific concepts (PDBs, HPAs, CNI, Ingress controllers, Helm, ArgoCD) are the gap. The Kubernetes Operations study plan will close this quickly because you already understand what Kubernetes abstracts.

Low Cross-Domain

Example: Cross-Domain section below 10/18 regardless of other scores.

Indicates lack of incident response experience. Technical knowledge is present but the ability to synthesize across domains during pressure is not. Case studies and incident simulations are the remedy.


Re-Assessment Guidelines

  • Minimum interval: 2 weeks between full re-assessments (less time and you are testing memory, not understanding)
  • Partial re-assessment: Re-take only the sections you studied. Keep previous scores for untouched sections.
  • Score tracking: Record your date and scores each time. Progress should be visible.
  • Goal: All sections at "Adequate" or above before going on-call. At least 2 sections at "Strong."
Date K8s Obs Net Linux Sec CI/CD Cross Total Level
_-_- __ __ __ __ __ __ __ ___ _____
_-_- __ __ __ __ __ __ __ ___ _____
_-_- __ __ __ __ __ __ __ ___ _____