How does Atlas encrypt data at rest by default, and what changes with your own KMS key?

## The default: already encrypted Atlas encrypts cluster storage at rest by default, using the underlying cloud provider's volume encryption with keys the provider and Atlas manage. It is on for every cluster, requires no configuration, changes nothing about queries or connection strings, and costs nothing extra. When a compliance questionnaire asks "is data encrypted at rest", the answer for a stock Atlas cluster is yes. What that buys is protection against the physical and storage-layer threats: a decommissioned disk, a stolen volume image, raw storage accessed out of band. What it does not buy is protection against anything that arrives through the normal path — a leaked database credential, an over-broad IP access list, a compromised application — because for those the storage layer decrypts as designed. ## Customer key management For organizations that need key custody, Atlas offers **Encryption at Rest using your Key Management** on dedicated clusters, integrating with AWS KMS, Azure Key Vault, or Google Cloud KMS. Atlas runs the encrypted storage engine with an internal master key that is itself wrapped by your customer master key. The key material stays in your KMS; Atlas asks it to unwrap. What this genuinely changes: - **Custody and auditability.** The key lives in an account you control, under your IAM policy, and every unwrap is visible in your own KMS audit log. That is the requirement most compliance regimes actually express. - **Revocation as a control.** Disabling or scheduling deletion of the key removes Atlas's ability to use the data. That is a deliberate, powerful lever — and a foot-gun of the same size. - **Snapshots inherit it.** Backups taken while the feature is enabled are protected under that key, which is what makes the guarantee end-to-end rather than live-cluster-only. ## The operational consequences These are what a senior candidate is expected to volunteer. **Your KMS becomes a production dependency of your database.** A misapplied key policy, a deleted alias, an expired grant, or a disabled key does not degrade the cluster gracefully — it removes access to the data. The key's IAM policy therefore needs the same change control as the database itself, and it should not be editable by whoever happens to have broad cloud-account rights. **The key must outlive your snapshots.** If you retain snapshots for a year, the key that protects them must remain usable for a year. Deleting or rotating out a key without accounting for backup retention silently converts your recovery path into unreadable bytes — and you discover it during an incident, which is the worst possible moment. This is the single most common real failure with bring-your-own-key. **Rotation is a scheduled operation.** Atlas surfaces when a customer key is due to be rotated, and rotation must be planned rather than improvised. Treat it as a routine maintenance task with a runbook, not an annual scramble. **Test the whole path.** Restore a snapshot into a scratch cluster while the feature is enabled, to prove the key grants actually permit a restore. Otherwise your first attempt happens under pressure. ## What it does not solve A recurring misconception is that customer-managed keys hide data from the platform. They do not. The database still decrypts documents to evaluate queries and build indexes, so anything with a valid credential and a network path reads plaintext, and the running server necessarily sees plaintext. If the requirement is that specific fields remain unreadable to the database server itself, the mechanism is **client-side field level encryption**, or **Queryable Encryption**, where the driver encrypts field values before they leave the application and holds keys the server never receives. That is a data-modelling and query-capability decision, not an infrastructure toggle: encrypted fields support a restricted set of query operations, and the key-management burden moves into your application. Similarly, at-rest encryption is orthogonal to transport security — Atlas requires TLS for client connections regardless — and orthogonal to authorization. A cluster with customer-managed keys, an unrestricted access list, and a shared credential holding broad roles is not secure; it just has excellent disk hygiene. ## How to answer Say that Atlas is encrypted at rest by default and that bring-your-own-key changes *who holds the key*, not *what is encrypted*. Then name the price: KMS availability becomes a database dependency, the key must survive as long as the snapshots, rotation is a planned operation, and restores must be tested through the key path. Finish by distinguishing at-rest encryption from field-level encryption, because that distinction is what separates a memorised feature list from someone who has thought about the threat model.