A city council member asks whether requiring HTTPS to DynamoDB means citizen records are encrypted on disk inside AWS. What should the developer explain?
Select an answer to reveal the explanation.
Short Explanation
HTTPS is the armored truck on the road; at-rest encryption is the locked vault in the warehouse. Council needs both stories—TLS does not magically encrypt disks. DynamoDB SSE/KMS covers storage separately.
Full Explanation
HTTPS to DynamoDB encrypts data in transit between the application and the service endpoint. Encryption at rest is a separate control: DynamoDB server-side encryption with AWS owned keys, AWS managed KMS keys, or customer managed KMS keys protects stored citizen records on disk inside AWS. A council member who hears “we require HTTPS” should not conclude that at-rest encryption was thereby configured or proven.
HTTPS does not automatically encrypt disks. TLS and at-rest encryption are not the same setting toggled by enabling HTTPS. Modern DynamoDB encrypts data at rest with SSE options; claiming the service never encrypts at rest is incorrect relative to current behavior emphasized on exams.
Exam caveat: in-transit TLS and at-rest SSE/KMS answer different threat models—network interception versus storage/media and key-control requirements—and security questionnaires often require explicit answers for both. Operational check: confirm clients use HTTPS endpoints, show the table’s SSE configuration in console or CLI, and document whether city policy mandates customer managed keys for tables holding citizen PII. For municipal workloads, document the chosen pattern in the runbook so the next on-call engineer applies the same control instead of inventing a weaker shortcut under pressure.