Appendix D - Worked Exercises and Design Solutions

A useful exercise produces an artifact another reader can inspect: a state trace, a calculation, a failing boundary, a test result or a recovery decision. It does not reward repeating the word reliable. The chapter exercises introduce mechanisms where they are taught; this appendix adds twenty-four substantial practice problems that combine those mechanisms and keep questions separate from worked answers.

There are eight developer, eight DevOps and eight architect exercises. Each has a stable ID, prerequisites, an estimated duration, a pinned source mechanism, a required artifact, hints and three objective scoring criteria worth two points each. Full credit is six points. A correct answer can conclude that the requested guarantee is absent; inventing missing persistence or enforcement loses credit even if the proposed design sounds plausible.

The eight developer entries are executable offline through existing pinned tests. Their tasks are source analysis and test-oracle interpretation, so no incomplete coding scaffold is required. Tests run in a separate module copy because Go internal-package rules and immutable evidence prohibit treating the Jekyll root as the application module. The GitOps test creates only a temporary local Git repository. None of these eight entries requires a Docker daemon, PostgreSQL connection or live registry.

Additional practice index

Read the separate practice questions first, then compare your artifact with the worked practice solutions. A hint should help locate an enforcing boundary without handing you a fictional result. Estimated times assume the stated prerequisites are available; missing tools are a setup issue to record, not a reason to assert a pass.

How to attempt an offline exercise

Make a disposable copy of the locked Orch module and use Go 1.25.0 with its declared dependencies. Run the exact test filter named in the question. Preserve command, working directory, source SHA, Go version, UTC timestamps and exit code. Read the assertion that would reject the specified incorrect behavior; a package-level pass with zero matching tests is not completion.

The delivered exercise check actually ran all eight selected command groups and observed nine requested test passes, because the cron entry intentionally includes two tests. This is evidence for those deterministic package fixtures. It does not establish Docker execution, cross-process durability or an actual production incident. A separate artifact grader accepts the serialized expected outcomes and rejects an intentionally wrong field for each executable entry; this checks grading discrimination. Separately, eight controlled semantic mutations in disposable source copies were each rejected by the selected package tests, as recorded in the mutation results. Those counterexamples demonstrate sensitivity to eight specified faults; they do not establish exhaustive mutation coverage.

When a fixture uses an injected clock, name that seam. The cron package does; not every subsystem exposes the same interface. Concurrent tests may guarantee one winner while leaving the winner’s identity nondeterministic. Preserve that distinction in your answer instead of relying on timing or sleeping until a preferred goroutine wins.

Traces, calculations and operational artifacts

For a task trace, include ID, DesiredStatus, ActualStatus, owning NodeID, service/deployment version and relevant conditions. Conditions such as node_lost remain separate metadata. Show the initial state, message or policy decision, authorization check and resulting state. Do not move failed directly to healthy to simplify a diagram: replacement gets a new identity, while cleanup has its own permitted edge.

For resource arithmetic, keep CPU in integer millicores and memory in bytes. Five replicas at 250 millicores and 128 Mi reserve 1250 millicores and 671088640 bytes. State whether other namespace reservations exist before asserting a quota decision. Requested capacity, limits forwarded to Docker and observed process consumption are three different artifacts. Arithmetic can be correct while propagation is missing.

Operational answers need a bounded target, a verification step and a stop condition. A restore plan must retain the matching envelope key and compare canary content, not merely show a successful database process exit. A memory-server restart plan must acknowledge that live intent was never written into that database. A node-loss plan must address an old process that can still run after its heartbeat expires.

Architecture answers should label proposals. A dependency graph connecting a durable service/store, transactional claim path and leader-loss cancellation is a future composition unless the source actually constructs it. Describe the smallest change and a falsifying crash window. A consensus paper or package interface supplies useful vocabulary; neither supplies proof that the default binary has activated HA.

Chapter exercise and answer map

Use this map to revisit each chapter’s original exercises and independently worked companion. Chapter answers are separate from the twenty-four additional practice solutions, so readers can attempt either set without immediately exposing the other.

Self-review and instructor guidance

First attempt a question using only its stated prerequisites. If the solution depends on an unstated constructor, clock, namespace context or resource unit, revise the question before grading. The second pass should compare every rubric criterion against the actual artifact, not against an impression that the answer sounds experienced. For a trace, distinguish wrong ownership from wrong arithmetic: both matter, but they require different feedback.

An operational artifact earns credit when another person can identify the exact disposable target, evidence origin, decision point and safe stop. It does not need to mutate a real service. An architecture artifact earns credit when it specifies state owners, failure domains and a test that could disprove the desired property. A proposal that simply adds PostgreSQL or a leader flag without changing callers is incomplete.

These exercises can be adapted to a future durable extension by adding explicit store construction, schema/key recovery and leadership fencing assumptions. Retain the original source-derived answer beside the extension answer. That comparison teaches how composition changes a guarantee without rewriting history or silently repairing the immutable baseline.

The exercise catalog is versioned with stable IDs and chapter links. Keep answers explicit about inspected, executed, expected and proposed evidence. Future revisions may change code and prerequisites; they must not turn the current edition’s bounded observations into universal production promises.

Source-backed boundary statements for this appendix are indexed in the appendix claim record. Detailed command, state, exercise and reference tables retain their own source provenance.