Appendix E

Production Readiness Checklist

Scope. A launch review for one service about to carry production traffic, in the order a review is walked. Every row is a decision, a threshold, or a named owner that must exist before go-live. Prerequisites. None. Appendix D holds the security controls this review assumes have been walked. Verified against. Google Cloud console and API surface as of 2026-09, Cloud SDK 583.0.0; every section reference checked against the owning chapter; see sources at end.

This book carries three checklists and they are not interchangeable. Appendix D lists security controls across the estate, each with the command that proves it. The Complete GCP Production Checklist in the back matter sweeps twenty-six service domains as review prompts — things somebody should be able to explain. This appendix is neither. It is scoped to a single service, and every row is a decision, a threshold, or a name: the target, the ceiling, the trigger, the person, the date the test was last run.

That distinction is what keeps it short. A row belongs here only if the answer is a number, a named human, a date, or a choice between alternatives. If the answer is "run this command", the row is Appendix D's and is cited there instead.

On RTO and RPO. Both appear below as names for numbers you choose. Google publishes no failover RTO for the managed services in this book — the Cloud SQL high-availability documentation offers "about sixty seconds" and then says the duration varies by environment (§12.8). Treat every recovery figure here as yours to measure and defend, never as a platform guarantee.

E.1 Architecture §

The decisions everything else depends on. Most are cheap now and expensive later: a region, a failure domain, a project boundary. Get them written down before the service has data in it.

Decision, threshold, or owner	Why it must exist before launch	§
The named team that owns the service, and the project(s) it occupies	The project is the blast-radius, quota, and billing unit; an unowned project is an unowned incident	§1.5
The failure domain the design survives — machine, zone, region — chosen from one table	Every availability decision downstream is a consequence of this one; made implicitly it is made wrong	§1.21
Primary region, secondary region if any, and why those	Region choice is effectively permanent for stateful services and constrains residency and latency	§1.4
Confirmation the production project holds no non-production workload	Shared quota and a shared default IAM boundary make the separation structural, not cosmetic	§2.15
Network attachment: own VPC or Shared VPC service project, with the subnet and CIDR reserved	Subnet addresses are a shared capacity dependency between service projects	§5.29
Ingress path: which load balancer, global or regional, and what terminates TLS	Global and regional balancers differ in failover behavior, not only in reach	§7.2
Data classification and residency requirement for what the service stores	Determines region, encryption, logging, and perimeter decisions already listed above	§15.8
External dependency inventory: every service outside the boundary, and the behavior when each fails	A dependency nobody enumerated is a dependency nobody designed a fallback for	§1.21
Compliance scope: which framework, if any, this service is in scope for	In-scope changes evidence retention and access-review cadence, both of which cost money and time	§30.10

E.2 Availability §

An availability target is a number agreed with someone who will be unhappy if it is missed. Without it there is no definition of an outage, and every row below has nothing to be measured against.

Decision, threshold, or owner	Why it must exist before launch	§
The availability target as a number, over a stated period, agreed with whoever will be unhappy	Without a target there is no definition of an outage and no basis for any of the following rows	§18.12
The SLI: what counts as a good request, including the latency threshold	"Did not return 5xx" is not availability; the narrow definition must be agreed before it is measured	§18.13
The error budget figure and the named person empowered to enforce the stop	An unenforced budget trains the team to ignore the burn-rate alerts built on it	§18.14
Redundancy per tier: regional Cloud SQL yes/no, MIG across ≥3 zones yes/no	Retrofitting `REGIONAL` availability onto a live instance is a change with downtime	§12.8
The health-check definition — path, thresholds — and whether it tests dependencies	A health check that returns 200 while the database is unreachable removes the only failover signal	§7.7
The autohealing initial delay, sized to real startup time	Too short and the group recreates instances that were merely still booting	§8.13
The maintenance window, and who is reachable during it	Cloud SQL and GKE will patch on their own schedule if you do not choose one	§12.12
The GKE release channel chosen, and what it means for upgrade pace	The channel is the upgrade contract; the default is not always the right one for a service at launch	§9.35
Date and result of the last failover exercise for this service	An untested failover is a design, not a capability — and D.15 requires the test, not the number	§9.41

E.3 Scaling §

Scaling readiness is a set of ceilings and floors, each chosen deliberately. The ceiling that binds first is usually not the service's own.

Decision, threshold, or owner	Why it must exist before launch	§
The peak load figure the service is sized for, and how it was arrived at	Every ceiling below is arbitrary without it	§18.13
The scaling ceiling: `--max-instances`, MIG max replicas, or node-pool max, as a number	Left unset, a client's retry loop is billed as capacity you agreed to buy	§10.10
The scaling floor and the cold-start latency it buys	Minimum instances trade money for latency; the trade must be a decision, not a default	§10.9
Concurrency per instance, and the memory it implies	Raising concurrency to cut cost without measuring per-instance capacity is the documented pitfall	§10.7
The autoscaler's signal and its target utilization value	The signal determines what the service scales on; CPU is often the wrong one	§8.12
The database's scale ceiling and what happens past it — read replicas, or a different engine	One instance's ceiling arrives suddenly and the migration off it is not a launch-week project	§12.26
The downstream limit that binds first when this service scales — connections, subnet addresses	The service's own ceiling is rarely the first one reached	§12.16
The per-consumer rate limit and quota values for any external API surface	One client's runaway retry loop otherwise consumes the capacity sold to everyone	§21.12
The project quotas this service can exhaust, with current headroom, and who watches them	Quota is counted per project and exhaustion presents as an outage with no error in the service	§1.5

E.4 Security §

This section asks one question in eight forms: did the security review happen, and where is its output? The controls themselves are Appendix D's, and repeating them here at service scope would change nothing but the word "this". A launch review confirms the walk-through occurred and that its exceptions have owners and expiry dates.

Decision, threshold, or owner	Why it must exist before launch	§
The date the Appendix D walk-through was completed for this service's projects, and by whom	An undated review is indistinguishable from no review; the controls themselves are D's subject, not E's	§D.3
Where the completed control record lives, and who can produce it on request	An auditor asks for the artifact, not the assertion	§29.2
Every control marked not-applicable, with the named person who accepted it	"Not applicable" is a risk acceptance; unowned, it is a gap with paperwork	§29.11
The exception register for this service: each exception, its owner, and its expiry date	An exception without an expiry is a permanent policy change made without review	§2.30
The service's trust boundaries, drawn — what crosses them and in which direction	Every network and IAM control below is an answer to a boundary question; undrawn, they cannot be checked for completeness	§35.1
The data classification of what this service stores, and the residency requirement it implies	Classification drives encryption, logging, perimeter, and region choices already made in E.1	§15.2
Who owns this service's Security Command Center findings, by rotation name	Findings routed to nobody are findings nobody triages	§D.13
The security escalation contact, distinct from the operational on-call	An operational responder must be able to hand off in one step when a fault turns out to be an intrusion	§18.18

E.5 Monitoring §

Monitoring readiness is about whether a human would find out. The signals that matter are the ones tied to the SLI, not the ones the platform emits by default.

Decision, threshold, or owner	Why it must exist before launch	§
One service dashboard exists, showing this service's SLIs and budget burn — not twenty	Dashboards multiply during incidents and are then abandoned; the reviewable one must pre-exist	§18.3
The specific metric for each of latency, traffic, errors, saturation for this service	"Metrics exist" is a prompt; the four named series are the artifact	§18.16
The metrics scope and the project the monitoring objects live in	Cross-project visibility is a configuration decision, not a default	§18.1
The repository and path holding this service's monitoring as code	A console-created alert policy has no author, no diff, and no recorded reason	§18.19
A `MetricAbsence` alert on every series an SLO consumes	A series that stops arriving looks identical to a series that never breaches	§18.13
Whether tracing is on, and the sample rate	Sampling is a cost and a fidelity decision that is hard to change during an incident	§18.10
Whether Managed Service for Prometheus or OpenTelemetry is in the path, and who owns the collector	A second metrics pipeline is a second failure domain and a second on-call surface	§18.7
The uptime or synthetic check target, its regions, and its period	An external check is the only signal that survives the service's own monitoring failing	§18.5

E.6 Logging §

Logs are evidence and they are also a bill. Both facts have to be decided before launch, because retention set after an incident does not reach backward.

Decision, threshold, or owner	Why it must exist before launch	§
The retention period per log class, and the requirement that produced each figure	Retention is per bucket and shortening it later loses the history it would have kept	§17.13
The destination bucket and project this service's logs land in	Logs in the audited project do not survive the audited project	§17.12
The estimated log volume and the ingestion budget it implies	Ingestion is billed by volume; the estimate is the difference between a budget and a surprise	§17.21
The exclusion filter decision: what is deliberately not ingested	Health-check and framework noise is the single largest controllable line	§17.21
Whether Data Access logs are on for this service's data-bearing dependencies, and why	The most expensive logging decision in the estate, and one with a real threat-model answer	§17.3
The redaction list: what this application must never write to a log	Credentials and tokens in logs convert a log reader into a credential holder	§17.19
The export decision — BigQuery, SIEM, both, neither — and who queries it	An export nobody queries is cost; no export when responders need history is an investigation failure	§17.17
The named role that can retrieve historical evidence for this service	Evidence retrieval during an incident is not the moment to discover nobody has the log view	§29.10

E.7 Alerting §

An alert that nobody acts on is worse than no alert, because it teaches the team that alerts are noise. Every row here is about whether a page has a human and an action attached.

Decision, threshold, or owner	Why it must exist before launch	§
The on-call rotation by name, its members, and the expected acknowledgement time	A page to an unstaffed rotation is a metric, not a response	§18.17
The escalation path, in order, with the second name reachable if the first does not answer	Escalation invented at 3 a.m. is escalation that does not happen	§18.18
The burn-rate alert thresholds — the fraction consumed, over which window, at which severity	Alerting on the raw SLI pages on every blip; the burn rate is the number that must be chosen	§18.14
A named owner and a runbook link for every alert that pages	An alert with no runbook is a wake-up call with homework attached	§18.16
The date the page was fired end to end and a human confirmed receipt	Notification delivery is the one part of the chain that is never exercised by normal operation	§18.17
The `autoClose` duration on each policy	Without it, incidents on deleted resources stay open and mask new ones on the same policy	§18.16
The severity ladder, and which alerts page versus which file a ticket	Everything paging is the same as nothing paging, within about a month	§18.18
Who may snooze, for how long, and the standing rule that security policies are never snoozed	A maintenance window is when a change to a security control is least likely to be noticed	§18.16
Which channel is outside the shared-fate group, named — D.13 requires two, E records which	Redundancy that pairs two channels from the same internal service is not redundancy	§D.13

E.8 Backup §

Backups are a decision about acceptable loss, expressed as a number. The row that matters most is the one nobody fills in: when the restore was last actually performed.

Decision, threshold, or owner	Why it must exist before launch	§
The RPO figure, per data store, stated as a duration	Backup frequency is derived from it; chosen without it, frequency is a guess	§12.11
Backup cadence and retention count, shown to satisfy that RPO	The two numbers must be checked against each other, and almost never are	§12.10
The transaction-log retention in days, where point-in-time recovery is required	The daily backup fixes the floor; this number fixes how finely you can land between two of them	§12.11
Object storage location class chosen — regional, dual-region, multi-region — and the RPO it buys	Dual-region with turbo replication is the option that yields a nameable RPO rather than a hope	§11.6
Object versioning, soft-delete, and retention-policy durations, as figures	Each is a different recovery from a different failure; the durations are the decision	§11.17
The GKE backup plan's namespace scope, and who updates it when a namespace is added	A stale scope silently stops covering new work; D.15 requires the review, E records the scope	§9.40
Snapshot schedule cadence and retention for any persistent disk in the path	A disk with no resource policy attached has no schedule at all	§8.27
What is deliberately not backed up, and who accepted that	Unstated, this is discovered during the restore	§29.9

E.9 Recovery §

Recovery is where designs meet measurement. Appendix D requires that a restore test exists; this section requires the number it produced — which is the one thing a verification command cannot report.

Decision, threshold, or owner	Why it must exist before launch	§
The RTO figure, per data store and for the service as a whole	Restore process must be shown to support it, which cannot be done against an unstated target	§29.9
The measured restore duration, with the date it was measured, against that RTO	D.15 requires a dated restore test; E requires the number it produced and the comparison	§29.9
What proves the restored service is usable — the specific check, not "files exist"	A restore that produces bytes and not a working application has not been tested	§29.9
The recovery dependency list: KMS keys, DNS records, secrets, and state, each with its location	A restore blocked on a key in the destroyed project is the common failure and it is discoverable now	§14.13
Who declares a recovery event, by role, reachable in one step	The same decision incident management requires, applied to the case where the data is gone	§18.18
The region-loss procedure and its owner	The sequence — recreate from source, restore data, move traffic — has to exist as steps	§9.41
The rebuild-from-source path: which repository and root module reconstruct this service	If the answer is a person's memory, the estate has one point of failure and it is human	§26.18
The acceptable data loss for this service, stated, and by whom it was accepted	Recovery decisions during an incident trade data for time; the trade must be pre-authorized	§34.14

E.10 Deployment §

How the service reaches production, who approves it, and what the pipeline is allowed to do without a human. The mechanics belong to Chapters 23 and 25; what belongs here is the choice.

Decision, threshold, or owner	Why it must exist before launch	§
The strategy chosen — standard, canary, or blue/green — and why this service is not the default	Canary is the better default; blue/green is for changes that cannot be partially deployed	§25.7
The canary phase percentages and the duration of each phase	The percentages are the risk decision; unset they are whatever the example used	§25.7
What the verify step actually asserts, in terms of the SLI	A verify step that checks the process is running is not a verification	§25.7
The named approver for production, and confirmation they are not the person promoting	Approval by the requester is a log entry, not a control	§25.4
The promotion path: the ordered list of targets a release passes through	Promotion order is the environment contract and must not be improvisable	§25.3
The DNS and certificate cutover plan, including the TTL used for the cutover	A long TTL turns a bad cutover into an hour with no lever	§7.9
The emergency deployment path, its authorizer, and where its use is recorded	The path exists whether or not it is written down; unwritten, its use is invisible	§25.14
Whether the change is backward-compatible with the state it touches, per release	It is the precondition for E.11 being possible at all	§25.9

E.11 Rollback §

Rollback is the plan you write while calm. Its two hard parts are the trigger — stated in advance, so nobody debates it at 03:00 — and the data, which does not roll back with the code.

Decision, threshold, or owner	Why it must exist before launch	§
The rollback trigger: the specific metric and threshold at which rollback happens without a meeting	Deciding during the incident costs the minutes the budget was supposed to buy	§18.14
Whether rollback is automatic or manual, decided per stage	Both are defensible; "we never decided" is not	§25.7
Who may execute a rollback at any hour, without approval, by role	An approval gate on rollback converts a two-minute recovery into a paging exercise	§25.9
The measured rollback duration, with the date	D.15 requires the rehearsal; E requires the number, which is what the trigger threshold is sized against	§25.9
How many releases back rollback is possible, given the artifact retention policy	Retention decides how many releases back you can actually reach, so the two numbers must be chosen together	§24.11
The state-compatibility window: how long the previous version can still read current data	Rollback of code is fast; rollback of a schema is not, and the two are often confused	§25.9
The infrastructure rollback procedure, stated as distinct from the application one	Reverting a Terraform apply is not a redeploy, and treating them alike destroys data	§26.21
What rollback does not fix — the written list, including data written by the bad release	The team will believe rollback restored the state unless told otherwise, in writing, in advance	§26.22

E.12 Documentation §

Documentation readiness is not about volume. It is about whether the person paged at 03:00, who did not build this, can act.

Decision, threshold, or owner	Why it must exist before launch	§
The service owner and a second named contact, recorded where a responder will find them	Attribution and detection scoping both key on ownership metadata, not on tribal knowledge	§2.12
The architecture diagram with trust boundaries marked, and the date it was last accurate	An undated diagram is a claim about a system that may no longer exist	§1.25
The runbook inventory: which incidents have one, and which knowingly do not	An undocumented incident is one the responder improvises through, at the worst possible hour	§34.1
The authoritative configuration location — repository, path, module	Two sources of truth means the wrong one is edited under pressure	§26.5
Where change records for this service can be reconstructed, and over what window	An audit asks for a history that spans several systems, each keeping its own retention	§29.5
The known-debt register, each entry with an owner and a review date	Debt without a date is debt that is never revisited	§29.11
The trigger that requires the documentation to be re-reviewed	Otherwise the diagram ages until the next incident discovers it	§29.5
The dated handover walkthrough: who other than the implementer deployed and recovered the service	The only real test that the documentation is sufficient	§34.1
The go-live sign-off record: who declared it ready, when, and where the record lives	The review has no effect if its output is a conversation	§29.5

Sources §

Every row in this appendix points at the section of the book that owns the concept behind it, and those chapters carry their own sources. The appendix asserts no Google Cloud fact of its own beyond the section references themselves, and therefore cites no external page; the three-way split against Appendix D and the back-matter checklist is recorded in .build/verify/appE.md.