Data Protection

TL;DR

• “Encrypted” is not a single checkbox — it requires at-rest encryption, in-transit encryption (TLS), and correct key governance together; any one alone leaves a real gap.
• Envelope encryption is the mechanism behind most AWS at-rest encryption: KMS encrypts a locally-generated data key rather than the data directly, avoiding per-byte KMS API calls and throughput limits.
• KMS key policies should separate key administrators (lifecycle management) from key users (encrypt/decrypt) — collapsing both into one grant removes a real separation-of-duties control.
• Explicit Deny in a policy set always overrides Allow, including a broad grant in a KMS key policy itself.
• ACM auto-renewal depends on DNS validation continuing to succeed — it is not unconditional, and imported certificates don’t get the same auto-renewal path.

Core Concepts

Encryption at rest

Protects against a specific, narrow threat: physical media theft, improper disk disposal, unauthorized access to the underlying storage layer. Enabling it (close to a one-click operation on most AWS services) addresses only that threat — it does nothing for data moving across the network and nothing against a legitimately authenticated identity misusing its own query access.

Encryption in transit (TLS)

Covers the network gap at-rest encryption leaves open: data moving between application and database, between services, between client and API. A design encrypted at rest but sending unencrypted traffic between application and database inside a “trusted” VPC leaves a real gap exposed by an internal network compromise or a misconfigured security group.

Envelope encryption mechanics

KMS keys never leave the KMS service boundary and have real throughput limits, so encrypting large volumes of data directly against a KMS key doesn’t scale. Instead: KMS generates and encrypts a data key; that data key, briefly available in plaintext locally, encrypts the actual data at full local performance; only the encrypted data key is stored alongside the encrypted data. Decryption reverses the order — KMS decrypts the data key first, then the data key decrypts the data. This is what lets services encrypt large data volumes without a KMS API call per byte.

KMS key policies: administrator/user separation

A well-designed key policy separates key administrators (rotate, disable, schedule deletion — lifecycle management) from key users (encrypt/decrypt using the key, cannot change its configuration). Collapsing both into one broad grant removes a genuine separation-of-duties control against insider risk and accidental misuse. The standard IAM policy-evaluation rule applies here too: an explicit Deny anywhere in the evaluated policy set overrides any Allow, including a broad grant in the key policy itself.

ACM certificate management

Handles issuance and automatic renewal of TLS certificates. Auto-renewal depends on DNS validation continuing to succeed — it is not unconditional. A DNS validation record removed during an unrelated domain reconfiguration silently breaks ACM’s ability to auto-renew, surfacing only when the certificate has actually expired. Certificates imported into ACM from an external CA (rather than issued by ACM directly) do not get the same auto-renewal behavior.

At-Rest vs In-Transit vs Key Governance

Command / Configuration Reference

# KMS key policy separating administrators from users (partial)
{
  "Statement": [
    { "Sid": "AllowKeyAdministration", "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::ACCOUNT:role/KeyAdmins"},
      "Action": ["kms:Create*","kms:Describe*","kms:Enable*","kms:Disable*","kms:ScheduleKeyDeletion"],
      "Resource": "*" },
    { "Sid": "AllowKeyUsage", "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::ACCOUNT:role/AppRole"},
      "Action": ["kms:Encrypt","kms:Decrypt","kms:GenerateDataKey*"],
      "Resource": "*" }
  ]
}
# separates lifecycle management from encrypt/decrypt usage

aws kms encrypt --key-id alias/my-key --plaintext fileb://secret.txt --output text --query CiphertextBlob
# direct KMS encryption — fine for small payloads, not for bulk data

aws kms generate-data-key --key-id alias/my-key --key-spec AES_256
# returns plaintext + encrypted data key — the envelope encryption primitive

aws acm request-certificate --domain-name example.com --validation-method DNS
# issues a cert requiring DNS validation records for auto-renewal to keep working

aws acm describe-certificate --certificate-arn arn:aws:acm:...
# check RenewalSummary.RenewalStatus to confirm auto-renewal is actually succeeding

Common Pitfalls

• Pitfall: “Encrypted” treated as a single checkbox. Why: At-rest, in-transit, and key governance are conflated into one blanket claim. Fix: Verify all three explicitly and independently in any design review.
• Pitfall: KMS key policies grant the same broad access to administrators and users. Why: Simpler to write one grant than to separate lifecycle management from usage. Fix: Split key policy statements explicitly between administrator and user roles.
• Pitfall: Internal service-to-service traffic left unencrypted inside a VPC. Why: The network boundary is assumed to be sufficient protection on its own. Fix: Enable TLS between internal services regardless of VPC trust boundaries.
• Pitfall: An ACM certificate silently fails to auto-renew. Why: A DNS validation record was removed by an unrelated change, or the certificate was imported rather than ACM-issued. Fix: Monitor DNS validation record presence and RenewalSummary.RenewalStatus; avoid importing certificates that need ACM-managed renewal.

Interview Questions

• Explain envelope encryption and why AWS services use it instead of encrypting data directly against a KMS key. — tests genuine mechanical understanding, not just the term.
• Design a KMS key policy for a workload where a platform team manages the key and an application team only needs to use it. — tests whether administrator/user separation is applied correctly.
• A load balancer’s ACM certificate expired unexpectedly last week despite auto-renewal being enabled. Walk through the root-cause investigation. — tests real operational debugging instinct around a common failure mode.
• A KMS key policy grants kms:* to the account root, and a separate IAM policy denies a specific role from using the key. Who wins, and why? — tests understanding of explicit-Deny precedence in policy evaluation.