A county tax system will store sensitive assessment data in Amazon RDS. Leadership requires encryption at rest and notes that RDS encryption cannot be turned on later for an already unencrypted instance. When should the architect enable encryption?

Amazon RDS encryption at rest for a county tax assessment database is a create-time property. When leadership requires encryption and correctly notes that you cannot flip encryption on an already unencrypted live instance, the architect must select encryption and a KMS key at DB instance creation—before production assessment data is loaded. That choice binds storage, automated backups, read replicas, and snapshots into an encrypted lineage. For municipal tax systems holding sensitive parcel and valuation data, getting this wrong forces a later snapshot-copy-encrypt-restore migration under outage pressure rather than a clean initial design.

A runtime toggle after go-live does not exist for classic RDS encryption: you cannot encrypt an unencrypted instance in place. Leaving the primary unencrypted while encrypting only read replicas fails confidentiality of the system of record and misunderstands replica inheritance—replicas of an unencrypted primary do not magically become a substitute for encrypting the primary. Enabling S3 default encryption and assuming RDS inherits it is a category error: S3 SSE settings do not encrypt RDS storage volumes. Each service has its own encryption controls.

Exam caveat: remember the painful remediation path—snapshot, copy with encryption, restore—versus enabling encryption at birth. Questions often bait candidates with “just enable it later.” Operational check: verify the RDS console/API shows storage encrypted, confirm the KMS key ARN, ensure automated backups inherit encryption, and rehearse restore of an encrypted snapshot into a non-production county account before cutover.