Run Production Infrastructure Reliably

Proof required

Submit a GitHub repository (or a link to the pipeline config in an existing repo) showing the automation scripts or config files, a pipeline run log or screenshot proving it executed without human input, and a 200-word description of what was manual before and what the automation eliminates.

What gets checked

• Pipeline run log or screenshot shows a successful automated run with no manual steps — a config file alone does not prove the automation works
• The 200-word description names the specific manual steps that were eliminated — 'it automates deployment' is not specific; 'eliminates the manual step of SSHing into the server and running git pull + pm2 restart' is
• The automation is committed to version control and could be reproduced by someone else reading only the config files

Common mistakes

• Automating a process that does not matter — a deployment pipeline for a personal project no-one else uses has lower credibility than automating a real team process
• An automation that still requires a manual trigger other than code merge (e.g. a script someone has to run manually) — true CI/CD is triggered by code events, not humans
• Config files with hard-coded secrets — any secret in version control is a security failure regardless of whether the automation itself works

Resources

What a verifier looks for

• Push a trivial commit to the repository and observe the pipeline run without any manual steps — if it requires manual input, the automation is incomplete
• Check the config files for hard-coded secrets — any credential in plaintext is a disqualifying security failure
• Ask the submitter what happens when the automated pipeline fails — error handling and alerting are the indicators of production-readiness vs toy automation
• Ask what was the most difficult part of the automation — genuine automation work always encounters unexpected environment or permission issues that required debugging

Proof required

Submit a screenshot of the dashboard showing all 3 metrics with real data, a log sample (3–5 lines showing the structured JSON format and request ID tracing), and a screenshot of the alert configuration with the condition and notification channel. Include a 150-word description of what each metric measures and what the alert fires on.

What gets checked

• Dashboard shows real production data — not sample or synthetic data; dates and values should be consistent with a real running system
• Log sample shows a request ID (or trace ID) that appears in every log line for a single request — this is the minimum for structured tracing
• Alert condition is on a real operational signal (error rate > 5%, p95 latency > 2s) not a trivial test condition (CPU > 1%)

Common mistakes

• Adding logs that emit raw text strings — structured logging means machine-parseable JSON; grep is not an observability tool
• A dashboard that shows system metrics (CPU, memory) but no application-level metrics — operational observability requires application-level signals
• An alert that was configured but has never actually fired — confirm the alert fires by triggering the condition deliberately and documenting the notification

Resources

What a verifier looks for

• Ask the submitter to explain what each metric on the dashboard measures and when it would indicate a problem — if they cannot answer without referring to documentation, the metrics were added without understanding
• Trigger the alert condition deliberately during the review session and confirm the notification arrives — an alert that has never fired is not a working alert
• Check the log sample for request ID propagation — ask the submitter to find all log lines for a single user request by searching by request ID
• Ask what the most painful production incident was that the new observability would have detected faster — genuine observability work is driven by past pain

Proof required

Submit the reviewer's written assessment: the design decision they challenged and your response, the reliability risk they identified, the hypothetical incident and your step-by-step diagnosis using your actual observability setup, and their sign-off confirming their role and a live session.

What gets checked

• Hypothetical incident diagnosis uses the actual dashboard, logs, and alerts documented in M2 — not a general description of how you would investigate
• Reliability risk identified by reviewer is a real gap (not a configuration detail) — a risk about what happens when the CI runner goes down or the database has a slow query
• Reviewer sign-off confirms 5+ years of production infrastructure experience (SRE, platform engineering, or DevOps in production environments)

Common mistakes

• Incident diagnosis that describes general debugging principles rather than specific steps using the specific observability tools built in M2
• A reviewer who is a software engineer with some DevOps exposure rather than someone who owns production infrastructure
• Design decision challenge response that describes what the tool does rather than why it was chosen over the alternatives

Resources

What a verifier looks for

• Prepare the hypothetical incident by reading the M2 observability setup first — it should be a realistic failure scenario (a slow database query, a memory leak, a failed deployment) that the submitter's specific dashboards and alerts would surface
• Ask the design decision question about a specific tool choice that has an obvious alternative — 'why GitHub Actions over CircleCI?' tests whether the choice was considered or just default
• Reviewer minimum qualification: 5+ years of production infrastructure ownership in a team context — not just personal server management
• Ask the submitter what they would add to their observability setup before going on-call — this tests whether the M2 work produced genuine operational thinking