Harness Certified Chaos Engineering study plan

Define chaos engineering in your own words and distinguish it from related but different practices such as high-availability testing, fault injection for QA, and disaster recovery drills.

Write out the core experiment loop (hypothesis, steady-state definition, fault injection, observation, comparison, learning) and give one original worked example for each stage.

Explain why a hypothesis-driven approach matters and describe what makes a hypothesis falsifiable in a distributed system.

List the common failure modes chaos programs fall into (no steady-state baseline, unclear blast radius, no rollback, experiments run only in production without approval) and note one mitigation for each.

Map out the organizational prerequisites for running experiments safely: ownership, on-call awareness, change management, and stakeholder sign-off.

Compare the main fault categories (network latency and loss, resource stress, process and pod termination, dependency unavailability, clock and DNS faults) and note what each one actually tests.

Identify which steady-state signals (latency percentiles, error rate, saturation, throughput) are meaningful for each fault category.

Describe how to scope an experiment so it tests one variable at a time and explain why combining faults early is risky.

Draft a reusable experiment template with sections for hypothesis, scope, steady state, fault, abort criteria, and result.

Estimate the blast radius of two sample experiments and justify your containment decisions.

Design an experiment that tests a specific resilience hypothesis about a service's behavior when one dependency becomes slow rather than unavailable.

Write explicit abort conditions and rollback steps for that experiment, including who can trigger them and how quickly.

Define the minimum and maximum blast radius for three scenarios (single pod, single node, single availability zone) and state what each one can and cannot prove.

Practice writing hypotheses that are falsifiable and observable, and rewrite three vague ones into testable form.

Build a pre-flight checklist for experiment approval that a reviewer could apply without prior context.

Outline the end-to-end workflow for configuring and running an experiment in a resilience testing platform: define target, choose fault, set parameters, attach probes, schedule, and review results.

Describe how target selection works (by service, environment, tag, or infrastructure scope) and explain why narrowing targets is the primary blast-radius control.

Explain the role of health checks and validation probes in determining whether an experiment succeeded, and distinguish them from steady-state monitoring.

Plan a gated rollout: run in a non-production environment first, then a small production scope, then expand only on evidence.

Document how experiment results feed back into backlog items and runbooks rather than ending as a report.

Compare experiment governance options such as approval gates, scheduling windows, and environment restrictions, and state when each is appropriate.

Describe how to integrate experiments into a CI/CD pipeline safely, including which stages should block a release and which should only report.

Explain how to manage secrets, credentials, and least-privilege access for the tooling that injects faults.

Draft a policy for who may run which experiments at which scope, and how exceptions are approved.

Identify the configuration details that most often cause experiments to fail for the wrong reason (wrong target, missing probe, timeout too short) and how to catch them before execution.

Define steady state precisely for a chosen service using measurable indicators, thresholds, and the time window over which they must hold.

Explain the difference between steady-state validation and simple alerting, and describe how automated validation decides pass or fail.

Design a blast-radius control matrix mapping experiment scope to required approvals, monitoring depth, and abort speed.

Describe how to observe an experiment in progress: which dashboards, traces, and logs you watch, and what a signal of unexpected impact looks like.

Write an abort decision tree that a responder can follow under time pressure.

Analyze a sample experiment result set and determine whether the hypothesis was supported, refuted, or inconclusive, and justify the call.

Distinguish a genuine resilience gap from a measurement artifact such as a noisy baseline or a probe that timed out too early.

Explain how to communicate experiment outcomes to engineering leadership without overstating or understating risk.

Describe how to build a repeatable experiment cadence and track program maturity over time.

Review your week 1 primer and correct anything the later weeks showed to be wrong or incomplete.

Consolidate all four domains into a single reference sheet of the concepts you most often confuse.

Re-derive the experiment loop, blast-radius controls, and steady-state validation from memory and check against your notes.

Work through practice scenarios that require choosing a fault type, scoping it, defining steady state, and setting abort criteria.

Identify your two weakest areas and write a targeted remediation plan for each.

Draft a 30-day plan for running your first real experiment at work.