A parks permit site terminates HTTPS at an Application Load Balancer so browsers talk to the ALB over TLS. What type of encryption control is that primarily illustrating?
Select an answer to reveal the explanation.
Short Explanation
Data flying between the citizen’s browser and the ALB is on the wire — locking that path with TLS is encryption in transit. At-rest controls protect parked data on disks and volumes. Do not confuse the courier pouch with the vault.
Full Explanation
Encryption in transit protects data moving between the citizen's browser and the load balancer by using TLS on the wire. That is distinct from encryption at rest, which protects parked data on disks or in object storage after arrival. Municipal portals collecting personal information should treat HTTPS on the Application Load Balancer listener as a primary control for the browser-to-ALB segment of the journey. Distractors that label this path as only at-rest encryption, that claim transit protection is unnecessary because Regions cannot be physically breached, or that confuse disk encryption with courier-pouch protection of packets miss the lifecycle moment being asked. Exam caveat: many designs need both transit and at-rest encryption for sensitive permit or identity data; answering with the wrong moment is a frequent Cloud Practitioner miss even when both controls exist in the architecture diagram. Operational check: enforce HTTPS on public listeners, redirect HTTP to HTTPS, manage certificates appropriately (for example with ACM), disable weak protocols and ciphers per policy, and extend transit encryption expectations to service-to-service calls that carry sensitive data inside the VPC or across accounts so internal hops are not the weak link.