An attacker obtains the application's database credential from a leaked environment file and runs a SELECT against the customer table. Every volume is encrypted at rest with a managed key service and every connection uses TLS. What does that encryption prevent here?

The mechanism

Encryption at rest protects data when it is at rest and separated from the running system. The database process holds the data encryption key in memory and decrypts pages transparently as it serves queries. A query arriving with valid credentials is indistinguishable from a legitimate one, so it gets plaintext rows.

This is not a flaw. It is the design: at-rest encryption exists to defeat a specific set of threats, and an authenticated query is not among them.

What at-rest encryption actually buys

• A stolen or improperly decommissioned disk is unreadable.
• A snapshot or backup copied to the wrong place is useless without the key, which is why it is the single strongest control over the backup sprawl most organisations have.
• A misconfigured object store bucket exposes ciphertext rather than data, provided the key is not also exposed.
• Key destruction becomes a deletion mechanism: destroy the key and the ciphertext is unrecoverable, which is how many organisations satisfy erasure obligations for backups that cannot be edited.

Each of those is a real difference at 3 am. None of them is about a live credential, which is why every serious threat model written since the 2013 wave of disk-loss disclosures treats at-rest encryption as a media control and nothing more.

Why the other options fail

• The key service denying an unknown caller confuses two layers. The key service authorises the database host, which is a legitimate caller and stays legitimate. It never sees the application's query or its credential. This is the most instructive wrong answer because the control it imagines - per-query authorisation at the key layer - is exactly what field-level encryption with a separate key authority provides, and the point is that ordinary volume encryption does not.
• Rotation on the next schedule misunderstands rotation. Rotating a data encryption key re-encrypts data; it does not revoke a database credential. The attacker keeps reading throughout. Rotating the credential is the correct response, which is a different control.
• The attacker only sees ciphertext describes what happens when someone reads the files directly, not when they query through the engine. The engine's whole job is to decrypt.

What would have stopped it

1. Short-lived credentials issued per workload, so a leaked environment file expires in hours instead of never. This is the control that matches this threat.
2. Field-level or application-layer encryption for the highest-sensitivity columns, where the key is held by a service that authorises the caller rather than the host. Now a stolen database credential yields ciphertext. It costs you indexing and searching on those columns, which is why it is applied to a few fields and not to everything.
3. Query-shape alerting. A credential that has only ever issued point lookups suddenly performing a full table scan is a detection that works regardless of how the credential was obtained.

When this is still the right first spend

When the realistic threat is media, snapshots and backups leaving your control, which for most organisations it is, and when a compliance regime requires it. Prefer it as the first spend because it costs roughly 0 ms of added query latency on modern hardware and covers a threat you cannot otherwise address. Do it, and then be honest in the threat model about what it does not cover, because the common failure is a team that believes the row is protected against a compromised application.