SOA-C02 Networking and Content Delivery Practice Question

A SysOps administrator is configuring Amazon CloudFront to serve content from an Amazon S3 bucket. The content is sensitive and should be encrypted at rest. Which option ensures that content is encrypted at rest in S3?

⚠ Common exam trap

It's easy for candidates to confuse encryption in transit (HTTPS) or access control mechanisms (signed URLs) with encryption at rest, leading them to select options that only protect data during transfer or restrict access rather than securing stored data.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Enable server-side encryption (SSE-S3) on the S3 bucket

Enabling server-side encryption (SSE-S3) on the S3 bucket ensures that objects are encrypted at rest using AES-256 encryption managed by Amazon S3. This directly addresses the requirement for content to be encrypted while stored in S3, independent of how CloudFront accesses the bucket.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Enable server-side encryption (SSE-S3) on the S3 bucket
Why this is correct
Server-side encryption with S3-managed keys (SSE-S3) encrypts each object at rest using AES-256 before it is written to disk in the S3 bucket. When CloudFront makes a legitimate origin fetch, S3 transparently decrypts the object and serves it over the configured protocol, so the encryption does not interfere with content delivery. This directly satisfies an encryption-at-rest requirement for the origin storage.
✗
Enable CloudFront HTTPS-only access to the S3 bucket
Why it's wrong here
Configuring HTTPS-only access forces CloudFront to communicate with the S3 bucket using TLS, protecting the object as it travels across the network, but it has no effect on how the bytes are stored on S3's infrastructure. The requirement is specifically about data at rest within the bucket, and HTTPS encryption only covers data in transit between CloudFront and the bucket or viewer. Therefore, this option does not meet the stated encryption-at-rest requirement.
✗
Configure signed URLs for the distribution
Why it's wrong here
Signed URLs are a CloudFront access-control mechanism that appends authentication policies and signatures to individual URLs, restricting who can fetch specific objects for a limited time. They do not perform any cryptographic transformation on the S3 objects themselves, so the underlying data remains unencrypted while stored. Using signed URLs only addresses authorization, not the requirement to encrypt data at rest in the S3 bucket.
✗
Use CloudFront field-level encryption
Why it's wrong here
CloudFront field-level encryption protects sensitive information submitted through POST/PUT requests by encrypting specific fields (such as credit card numbers) at the edge before they are forwarded to the origin. This protects data as it is being uploaded or passed through CloudFront, but it does not encrypt objects already stored in the S3 bucket or alter how S3 stores data at rest. It is designed for edge data protection, not origin storage encryption.

Quick reference

Symmetric Encryption Algorithm Comparison

Algorithm	Key Size	Block Size	Status	Notes
AES-128	128-bit	128-bit	Current standard	NIST approved; WPA3, TLS
AES-256	256-bit	128-bit	Current standard	Preferred for sensitive / govt data
3DES	112-bit effective	64-bit	Deprecated (2023)	Replaced by AES
DES	56-bit	64-bit	Broken	Cracked in < 24 h; never deploy
ChaCha20	256-bit	Stream cipher	Current	TLS 1.3, WireGuard

Go deeper

SOA-C02 Networking and Content Delivery Practice Question

Why each option matters

Option-by-option breakdown

Symmetric Encryption Algorithm Comparison

Related to this question