How Do You Enforce HTTPS for a CloudFront Custom Domain on AWS?

Why the Answer Is Correct

CloudFront encrypts traffic between viewers and edge locations only if two independent things are true, and options A and C supply exactly those two things. Option C attaches www.example.com to the distribution as an alternate domain name (CNAME) and binds the ACM-issued custom certificate, so the edge can complete a TLS handshake for that hostname instead of falling back to the default *.cloudfront.net certificate. Option A then forces the protocol decision at the edge: setting the Viewer Protocol Policy to Redirect HTTP to HTTPS on every cache behavior guarantees no viewer can complete a request over plaintext HTTP. Because CloudFront evaluates Viewer Protocol Policy per cache behavior, the setting must be applied to all of them, which is why the option is phrased 'for each cache behavior'. Together, C makes HTTPS possible for the custom domain and A makes it mandatory, which is precisely the requirement that all traffic be encrypted in transit. Community member Bad_Mat reached the same conclusion, stating "The correct combination of steps is A and C."

Why the Other Options Are Wrong

Option B is the classic distractor: allowing both HTTP and HTTPS leaves an unencrypted path open, so any viewer (or an attacker rewriting links) can still send cleartext requests, violating the 'all traffic must be encrypted' requirement. Option D is unrelated to transport encryption — an AWS WAF web ACL filters malicious requests at layer 7 and does not change the TLS or HTTP/HTTPS behavior of the distribution. Option E is also unrelated: Origin Shield adds a centralized caching layer between edge locations and the origin to reduce origin load and improve cache hit ratio, but it has no effect on the viewer-to-edge protocol. Neither D nor E supplies the certificate binding or the HTTP-to-HTTPS redirect that the scenario demands.

Community Comment Notes

The only recorded learner input on this item, from Bad_Mat, endorses the same pairing of steps (A and C), which matches what the CloudFront console actually enforces. That agreement is a sanity check rather than the reason to choose: the decisive evidence is that the scenario names an existing ACM certificate for www.example.com, which is otherwise unusable unless the hostname is added as an alternate domain name. Note also that ACM certificates used with CloudFront must reside in us-east-1, a detail worth remembering when a scenario mentions a certificate that will not attach.