You're diagnosing intermittent data problems on a two-year-old IoT sensor platform at a precision components manufacturer in Nagoya, and leaving the team with logging they can use after you're gone.
The discipline skills: defining a structured-logging standard for a team that isn't you, instrumenting an existing Lambda to emit JSON logs with consistent fields, configuring log retention as a cost decision, writing CloudWatch Logs Insights queries that answer specific diagnostic questions, forming hypotheses about where a problem lives, and testing them against recorded evidence rather than guessing.
The AI-direction lesson: AI writes Logs Insights syntax and Terraform for log retention competently. What it can't do is know that the real problem isn't in the Lambda code. AI's model of the problem is whatever it can see in the session, which is usually the code -- so when a Lambda is failing it proposes "add a try/catch" or "increase the timeout," even when the actual cause is an MQTT topic mismatch from a firmware update the factory-floor team did three months ago, or DynamoDB throttling during peak production. AI will suggest plausible fixes that aren't the actual cause. Evidence over plausibility is the discipline. This is also the first project where you produce an explicit decomposition plan before asking AI to act -- planning the work is the work.
Your Role
You're the cloud engineer. Yuki Tanaka's team of three can read logs but can't scroll through ten-thousand-line windows hunting for patterns. Production managers make decisions from a dashboard that's been showing stale readings, and the platform's original contractor is long gone. She needs somebody who can diagnose what someone else built, without taking the platform down while the factory runs 24/7.
Scaffolding holds at the same level as last time. What's different is the register shift. P6 was the first project where you responded to infrastructure already running -- but it was yours. This time the infrastructure is two years old and nobody on the team built it. There is no runbook. The problems already exist in the environment when you arrive.
With AI, the collaborative register deepens. You still supply workload context AI can't infer. You also now decompose the diagnostic work explicitly before asking AI to run queries, and you push back when AI proposes code fixes for problems that aren't in the code.
What's New
Last time at RideNaija you built alarms, dashboards, and an SNS notification routing from scratch for Chidi's Lagos ride-hailing platform, and responded to a staged alert using a provided runbook. The infrastructure you operated on was infrastructure you had just built.
This time there is no runbook and no staged failure. The symptoms are already there -- stale readings, missing sensors, worse during peak hours but not always. You form the hypotheses yourself, write a query or check a metric to test each one, and record what the evidence said.
Two things are genuinely new. First, structured logging as organizational infrastructure -- the logging standard you define is the deliverable Yuki's team uses to diagnose the next problem without you. Second, hypothesis-driven troubleshooting -- turning "the dashboard is wrong" into "are Lambda invocations timing out during peak hours?" -- a specific factual question a query can answer.
The hard part: AI will confidently propose fixes that sound right and aren't. The evidence is the only thing that resolves the disagreement. Trusting evidence over plausibility, and being able to explain why you set AI's suggestion aside, is the skill.
Tools
- Claude Code -- directing Terraform and Lambda instrumentation, drafting logging conventions, generating Logs Insights queries against specific hypotheses; plan mode used explicitly for decomposition planning (new usage)
- Terraform CLI -- log groups, retention configuration, Lambda environment changes (from P1)
- CloudWatch Logs and Logs Insights -- new in P7; the query surface for structured logs
- CloudWatch metrics -- carrying from P3/P6, used here for symptom confirmation
- AWS CLI -- inspecting IoT Core topic subscriptions, DynamoDB throttling metrics, Lambda configuration
- AWS Console -- visual verification of log groups, retention settings, Logs Insights runs
- checkov -- security scanning on the Terraform you write (from P4)
- Git and GitHub -- version control; troubleshooting journal and handoff doc live in the repo
- VS Code + Terraform extension -- code editor
Materials
In the project folder:
- Yuki's meeting notes (
first-contact.md) -- minutes from the kickoff, including the symptoms, what she wants, and the 24/7 operational constraint - Architecture summary (
architecture-summary.md) -- one-page description of the existing sensors -> MQTT -> Lambda -> DynamoDB -> dashboard pipeline, with approximate sensor rates you'll need for cost estimation - The contractor's inherited codebase (at the project root) -- the Node.js Lambda handler (
handler.js,package.json), the Terraform that provisions it (main.tf,lambda.tf,iot.tf,dynamodb.tf), and a minimalREADME.md. Two years old, undocumented, and never revised since the original 2024 build - Current logs sample (
current-logs-sample.log) -- a short slice of the wall of unstructured text Yuki's team faces today, emitted by the inherited handler - Recorded diagnostic evidence (
evidence/) -- Lambda and DynamoDB metric exports, an MQTT topic-subscription snapshot, and per-sensor reading counts from a representative 48-hour window. Enough to form and test diagnostic hypotheses against recorded data - Troubleshooting journal template (
troubleshooting-journal-template.md) -- the structure for recording each hypothesis, the query or check that tested it, the evidence, and the conclusion - Reference exemplars (
CLAUDE.md.reference,logging-standard.md.reference) -- finished examples of the governance file and the logging standard, kept separate so you don't copy them. You'll write your own first and use the references only to sanity-check your own work
No query templates, no retention recommendation, no diagnosis, no runbook, and no handoff template are provided. You define the logging standard, write the queries, make the retention call, record the findings, and write the handoff your client's team will actually use.