Amazon S3 Encryption Options, Policies, and Exam Traps – SAP-C02 Study Guide

Purpose of This Lesson

Amazon S3 supports multiple encryption models. The key decision is whether AWS or the application manages the encryption keys, and whether encryption and decryption occur inside Amazon S3 or on the client.

For the SAP-C02 exam, distinguish carefully between encryption in transit, encryption at rest, server-side encryption, and client-side encryption. Also understand how S3 bucket policies can enforce a required encryption method.

Key Concepts

Encryption in transit versus encryption at rest

When an object is uploaded to or downloaded from S3 using HTTPS, TLS protects the data while it travels between the client and S3. This is separate from encryption at rest.

With server-side encryption:

1. The client sends the object over TLS.
2. S3 encrypts the object before storing it on its underlying storage.
3. When the object is retrieved, S3 decrypts it and sends it over TLS if HTTPS is used.

TLS does not replace server-side encryption. Conversely, encryption at rest does not automatically protect data while it is transmitted.

SSE-S3: S3-managed keys

SSE-S3 is server-side encryption using keys managed by Amazon S3 and AWS. S3 performs the encryption and decryption within the service, using AES-256 encryption.

Characteristics:

• Key management is handled by AWS.
• The application does not manage or access the encryption keys.
• Encryption and decryption occur within S3.
• It is the default encryption method for new S3 objects when no different setting is specified.
• There is no additional charge for using this default S3-managed encryption.

SSE-S3 is appropriate when encryption at rest is required but the organization does not need customer-controlled KMS keys, key policies, or detailed KMS authorization controls.

SSE-KMS: AWS KMS-managed keys

SSE-KMS is server-side encryption using AWS Key Management Service. The data encryption and decryption still occur within S3, but S3 uses a KMS key to protect the object encryption process.

The KMS key can be:

• An AWS managed key for Amazon S3.
• A customer managed key, allowing more control over key policies, rotation configuration, and access administration.

SSE-KMS is useful when an organization needs centralized key governance, explicit permissions, auditing through AWS KMS activity, or the ability to disable or revoke access through a customer managed key.

A request using SSE-KMS generally specifies the desired encryption through the S3 request headers, such as x-amz-server-side-encryption: aws:kms. A customer managed KMS key may also be identified when required.

The caller must have the necessary S3 permissions and, when a customer managed KMS key is used, permissions granted by the KMS key policy and IAM policies. KMS request quotas and request charges can also become relevant in high-volume workloads.

SSE-C: customer-provided server-side keys

SSE-C means server-side encryption with customer-provided keys. The client supplies the encryption key with the request, while S3 performs the encryption and decryption.

Key characteristics:

• The encryption key is managed by the customer.
• S3 uses the key during the request but does not store the key for later retrieval.
• The client must provide the correct key for subsequent object access.
• HTTPS is required because the customer-provided key is sent with the request.

Losing the key can make the object inaccessible. SSE-C also increases operational complexity because the application must securely store, retrieve, rotate, and supply the key for every relevant request.

Client-side encryption

With client-side encryption, the application encrypts the data before uploading it to S3 and decrypts it after downloading it. S3 stores and returns only the encrypted object.

The client controls the encryption process and keys. Keys can be maintained entirely outside AWS, or an AWS KMS key can be used as part of the client-side encryption design. In either case, S3 does not perform the data decryption for the application.

Client-side encryption is appropriate when plaintext must never be exposed to S3 or when the application requires control over the encryption format and cryptographic workflow.

Default S3 encryption

New S3 objects are automatically encrypted at rest by default using SSE-S3 when no alternative encryption configuration is selected. This encryption is automatic and does not require application changes for basic use.

Default encryption does not retroactively transform every previously unencrypted object. Existing objects can be encrypted by:

• Copying each object to itself with the desired encryption settings.
• Using the S3 copy operation through the AWS CLI or API.
• Using S3 Batch Operations for large numbers of objects.

Enforcing encryption with a bucket policy

A bucket policy can deny uploads that do not specify the required encryption method. For example, to require SSE-KMS, the policy can deny s3:PutObject when the request’s s3:x-amz-server-side-encryption value is not aws:kms.

Conceptually, the condition is:

{
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "aws:kms"
    }
  }
}

This is a deny-based control: if the request omits the header or specifies another encryption method, the condition matches and the upload is rejected.

A production policy may also require a particular KMS key by checking s3:x-amz-server-side-encryption-aws-kms-key-id. Test the policy carefully because an overly broad deny can block legitimate service integrations or clients that do not send the expected headers.

Exam-Relevant Takeaways

• SSE-S3: S3 manages the keys and performs encryption inside S3.
• SSE-KMS: AWS KMS manages the keys, while S3 still performs the object encryption and decryption.
• SSE-C: The customer supplies the key, but S3 performs encryption and decryption. S3 does not retain the key.
• Client-side encryption: The client performs encryption and decryption. S3 stores ciphertext and cannot decrypt it.
• HTTPS/TLS protects data in transit; S3 encryption protects data at rest.
• New S3 objects are encrypted by default with SSE-S3 unless another option is selected.
• Default encryption does not automatically re-encrypt older objects.
• S3 Batch Operations and copy operations can be used to encrypt existing objects.
• Use a bucket policy with a deny condition to require SSE-KMS or another approved encryption setting.
• SSE-KMS introduces KMS authorization requirements and may introduce KMS request costs and quotas.
• If the required client-side or SSE-C key is lost, S3 cannot recover or decrypt the object for you.

Architecture Decision Guide

Requirement	Recommended approach	Why
Basic encryption at rest with minimal administration	SSE-S3	S3 manages the keys and encryption automatically
Centralized key governance and customer-controlled key policy	SSE-KMS with a customer managed key	Supports explicit KMS administration and access control
S3 performs encryption but the client supplies keys	SSE-C	The key remains under customer control and is not stored by S3
Plaintext must not be exposed to S3	Client-side encryption	Encryption occurs before the object reaches S3
Require all uploads to use KMS encryption	S3 bucket policy	Deny PutObject requests that do not specify the required encryption
Encrypt a large set of existing objects	S3 Batch Operations	Applies a copy or encryption operation at scale

Common Exam Traps

• Confusing SSE-KMS with client-side encryption: SSE-KMS is still server-side encryption. S3 performs the data encryption and decryption.
• Assuming TLS encrypts stored objects: TLS protects network traffic only. It does not define the at-rest encryption configuration.
• Assuming default encryption is retroactive: New uploads are encrypted automatically, but existing objects require a separate operation.
• Assuming SSE-C keys are stored by S3: The customer must retain and provide the key. S3 cannot recover a lost SSE-C key.
• Choosing SSE-KMS when no customer key control is needed: SSE-S3 may satisfy the requirement with less operational overhead.
• Forgetting KMS permissions: Access to an S3 object encrypted with a customer managed KMS key also depends on KMS authorization.
• Using the wrong policy condition: To require SSE-KMS, test the s3:x-amz-server-side-encryption request condition for aws:kms; do not rely only on the bucket’s default encryption setting.
• Treating bucket default encryption as a complete enforcement control: A bucket configuration communicates the default, while a policy can actively deny noncompliant upload requests.

Real-World Engineer Notes

• Prefer SSE-S3 when the requirement is simply encryption at rest and there is no need for customer-managed key governance.
• Use SSE-KMS when key ownership, explicit key policies, auditability, or the ability to disable a key is important.
• Account for KMS API quotas and request costs in high-volume object workloads. Validate the expected request rate before selecting a KMS-heavy design.
• Establish a durable key-management process for SSE-C and client-side encryption. Data recovery depends on the continued availability of the required keys.
• If client-side encryption is used, define how encrypted object metadata, encryption context, key identifiers, and key rotation are managed.
• When enforcing encryption through a bucket policy, test uploads from all approved producers, including AWS services and automation pipelines. A policy that expects a header unavailable to a producer can cause unexpected failures.
• Use S3 Batch Operations for large-scale remediation rather than manually copying objects one at a time.

Quick Reference Summary

• SSE-S3: AWS/S3-managed keys; server-side encryption; default for new objects.
• SSE-KMS: KMS-managed keys; server-side encryption; supports stronger key governance.
• SSE-C: Customer-provided keys; S3 encrypts and decrypts; key is not stored by S3.
• Client-side encryption: Application encrypts and decrypts; S3 sees ciphertext only.
• TLS: Protects data in transit.
• Default encryption: Applies to new uploads, not automatically to existing objects.
• Enforcement: Use a bucket policy that denies noncompliant PutObject requests.

Flashcards

1. Q: What does SSE-S3 provide?

A: Server-side encryption using S3-managed AES-256 keys, with encryption and decryption performed within S3.

1. Q: What is the primary distinction between SSE-S3 and SSE-KMS?

A: SSE-S3 uses S3-managed keys, while SSE-KMS uses keys managed by AWS KMS.

1. Q: Where does encryption occur with SSE-KMS?

A: Within Amazon S3; KMS manages the key used by the encryption process.

1. Q: Who supplies the key with SSE-C?

A: The customer supplies the key with the request, and must retain it for future access.

1. Q: Can S3 decrypt an SSE-C object if the customer loses the key?

A: No. S3 does not retain the customer-provided key.

1. Q: What is the defining feature of client-side encryption?

A: The application encrypts before upload and decrypts after download; S3 stores ciphertext only.

1. Q: What encryption is applied by default to new S3 objects?

A: SSE-S3, unless a different encryption configuration is selected.

1. Q: Does enabling default S3 encryption encrypt existing objects?

A: No. Existing objects require a copy operation or S3 Batch Operations.

1. Q: Which request action is commonly denied to enforce upload encryption?

A: s3:PutObject.

1. Q: Which S3 condition key identifies the requested server-side encryption method?

A: s3:x-amz-server-side-encryption.

1. Q: What value commonly identifies SSE-KMS in an S3 upload request?

A: aws:kms.

1. Q: What does HTTPS protect for an S3 request?

A: Data in transit between the client and S3, not the object’s at-rest encryption configuration.

Practice Questions

Question 1

A company must encrypt all new S3 objects at rest. It does not need customer-managed keys, custom key policies, or application changes. Which solution best meets the requirement with the least operational overhead?

A. SSE-C
B. Client-side encryption
C. SSE-S3
D. A customer managed KMS key with SSE-KMS

Correct answer: C. SSE-S3

SSE-S3 provides server-side encryption with AWS-managed keys and is the default encryption method for new S3 objects. SSE-C and client-side encryption require customer key-management processes, while SSE-KMS adds KMS administration that is not required by the scenario.

Question 2

A regulated workload requires encryption keys to be governed through AWS KMS. Security administrators must be able to manage key policies and revoke access independently of the S3 bucket policy. Which option should be selected?

A. SSE-S3
B. SSE-KMS using a customer managed KMS key
C. SSE-C using an application-generated key
D. TLS-only uploads

Correct answer: B. SSE-KMS using a customer managed KMS key

SSE-KMS integrates S3 encryption with KMS key administration. A customer managed key provides control over key policies and lifecycle decisions that are not available with SSE-S3.

Question 3

An organization wants S3 to reject any PutObject request that does not use SSE-KMS. Which control is most appropriate?

A. Enable versioning on the bucket
B. Configure an S3 bucket policy with a deny condition on s3:x-amz-server-side-encryption
C. Require MFA Delete
D. Enable TLS on the client only

Correct answer: B. Configure an S3 bucket policy with a deny condition on s3:x-amz-server-side-encryption

A bucket policy can explicitly deny uploads when the encryption header is missing or does not equal aws:kms. Versioning, MFA Delete, and TLS do not enforce the required at-rest encryption method.

Question 4

An application encrypts files locally using keys stored in its own key-management platform. S3 must never receive plaintext and must not be responsible for decryption. Which encryption model matches this requirement?

A. SSE-S3
B. SSE-KMS
C. SSE-C
D. Client-side encryption

Correct answer: D. Client-side encryption

With client-side encryption, the application encrypts before uploading and decrypts after downloading. S3 stores the encrypted object and cannot decrypt it. SSE-C still has S3 perform the encryption and decryption.

Question 5

A team enabled S3 default encryption but discovered that older objects remain unencrypted. What is the correct remediation approach?

A. Re-enable default encryption; it will process all existing objects
B. Use S3 Batch Operations or copy the objects with the desired encryption settings
C. Rotate the S3 bucket name
D. Download and delete the objects without re-uploading them

Correct answer: B. Use S3 Batch Operations or copy the objects with the desired encryption settings

Default encryption applies to new uploads. Existing objects must be rewritten, typically through S3 copy operations or S3 Batch Operations, to apply the selected encryption setting.