Hermes Wiki
Synthesis/certexams-rds-encryption-gotcha-preempts-a-localz-production-mistake

Synthesis: The SAA-C03 RDS-Encryption Gotcha Preempts a Mistake Localz's Own Stack Docs Are Currently Set Up to Make

The connection

CertExams/SAA-C03/AWS_Scope.md (substantially rewritten this window, +738 lines) contains an exam-critical callout under Amazon RDS that's unusually specific for what's normally a vendor-neutral architecture note: RDS encryption cannot be toggled on for a live unencrypted instance. The only supported path is snapshot → copy-with-encryption → restore-from-encrypted-snapshot → cutover → delete old instance. You cannot create an encrypted Read Replica from an unencrypted primary, and DMS is overkill for a single-database case. The note flags this as "heavily tested" because it's a one-way door: teams that provision RDS unencrypted "for now, we'll turn it on later" discover later that there is no "turn it on later" — only a migration.

Projects/Localz.md documents the exact provisioning decision this gotcha applies to: PostgreSQL (RDS/Aurora) is the chosen system of record for "bookings, payments, users, KYC, payouts, reviews, disputes, audit trails" (line 119) — chosen specifically over Mongo-only because money/booking lifecycle needs SQL transactions/constraints. The project's own security docs (line 198) list "encryption" as a cross-cutting must-have repeated across both security documents, and NFRs (line 97) name "encrypted payments, secure document storage" as an explicit goal. But nothing in Localz.md's current AWS-phase planning (the RDS/Aurora line, the AWS swap-in table at line 185) mentions RDS encryption-at-rest as a provisioning-time decision — it's currently bucketed with the general "encryption" must-have as if it's a setting that can be applied whenever.

Why this matters

This is precisely the failure mode the CertExams note exists to prevent, aimed at exactly the workload (payments, KYC, audit trails — the most encryption-sensitive data class in the whole project) that would be most expensive to discover the gotcha on after the fact. Localz is still pre-AWS-migration (Tech-Stack.md's "Minimal MVP slice" already assumes AWS-managed services per the existing 2026-08-09-incremental-localz opportunity note, but the project hasn't provisioned RDS yet) — which means this is a rare case where the exam prep material is catching a real architectural decision before it gets made wrong, not after. If Localz's RDS/Aurora instance for the payments/KYC data gets provisioned without --storage-encrypted true (or the Terraform/CloudFormation equivalent) at creation time, fixing it later means a full snapshot-copy-restore-cutover cycle on the production system of record for money movement — not a config flag flip.

What this suggests

  • Worth a one-line addition to Localz.md's AWS-phase RDS/Aurora line (or wherever the eventual IaC definition gets written) explicitly stating "encryption-at-rest must be enabled at instance creation — cannot be added after" — cheap now, expensive to discover during a payments-data migration later.
  • This is also a second, independent data point (after Architecture/Fundamentals/infrastructure-as-code.md's "how would we rebuild this from scratch" framing, already connected to Localz's Clerk/Keycloak drift in the 2026-08-09 opportunity note) that Localz's AWS-phase planning currently treats infrastructure provisioning details as fungible/deferrable when at least two of them (auth backend, RDS encryption) are actually one-way or hard-to-reverse decisions that need to be right at creation time, not patched in later.
  • General pattern worth naming for future CertExams↔Projects cross-checks: AWS's "cannot change after creation" class of gotchas (RDS encryption, S3 bucket region, VPC CIDR block) is a specifically high-value category to check against any project's pre-provisioning stack docs, since these are the decisions that are cheap to get right once and expensive to fix later — a stronger filter than checking CertExams material against Projects generally.
Hermes Wiki