ExamPark
Course menuSCS-C03

Exams / SCS-C03 / Study guide / Securing CloudFront origins and edge access (OAC, signed URLs, headers, CORS)

Securing CloudFront origins and edge access (OAC, signed URLs, headers, CORS): SCS-C03 study notes and practice questions

What to know about Securing CloudFront origins and edge access (OAC, signed URLs, headers, CORS) for the SCS-C03 exam, from the Infrastructure Security domain (18% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.

Last verified against current AWS documentation ·How we write our questions

What to know for the exam

These questions describe content served through CloudFront from an origin that must stay private, such as an S3 bucket of premium videos or an Application Load Balancer behind a CDN. You pick the mechanism that stops users from bypassing the distribution and that grants access only to the right viewers.

Lock the origin to CloudFront

  • Origin Access Control (OAC) is the current method for a private S3 origin. CloudFront signs its requests with SigV4, and OAC works with buckets encrypted with SSE-KMS, which the older origin access identity (OAI) method does not support.
  • The bucket policy grants the cloudfront.amazonaws.com service principal s3:GetObject, with a condition on AWS:SourceArn set to the distribution’s ARN. S3 Block Public Access stays on.
  • For an Application Load Balancer or API Gateway origin, use a custom origin header with a long random value that CloudFront adds to each request, and have the origin check it. Also limit the origin’s security group to the CloudFront managed prefix list for origin-facing traffic. Use both for defense in depth.
  • CloudFront VPC origins let a distribution reach an Application Load Balancer, Network Load Balancer or EC2 instance in a private subnet, so the origin needs no public address at all. Choose it when the requirement is that the origin must not be reachable from the internet.

Read the guide to restricting access to an S3 origin for the bucket policy pattern.

Restrict who can view content

  • Signed URLs grant access to one file until they expire. Signed cookies grant access to many files, such as a whole members-only path. Use URLs for one download and cookies for a site section.
  • Signing needs a trusted key group in CloudFront. The private key stays with your application, which signs at request time.
  • Keep expiry short. A signed URL is only as narrow as its path and its lifetime.
  • For country or address limits, add geo restriction or WAF rules.

Read about signed URLs and signed cookies before choosing between them.

Enforce HTTPS and response headers

  • Set the viewer protocol policy to redirect HTTP to HTTPS or to HTTPS only, and set the origin protocol policy to HTTPS only.
  • Response headers policies add security headers such as HSTS and a content security policy to every response. They can also set CORS headers without changing the origin.
  • Field-level encryption encrypts selected form fields in POST requests, so only the back end holding the private key can read them.

How to choose

Scenario wording Pick
Private S3 bucket that serves content only through CloudFront Origin Access Control with a bucket policy scoped to the distribution
Private bucket encrypted with SSE-KMS OAC, not OAI
Stop users reaching an ALB directly Security group limited to the CloudFront prefix list, plus a secret custom header
The origin must have no public address CloudFront VPC origin in a private subnet
One file for one customer for an hour Signed URL
Many files in one members-only path Signed cookies
Add HSTS and a content security policy to every response Response headers policy

Common traps

  • Making the bucket public so CloudFront can read it. OAC makes public access unnecessary.
  • Choosing OAI for a new bucket when the requirement includes KMS encryption.
  • A secret header that the origin never checks, or a secret that never rotates.
  • Signed URLs with long expiry or a wildcard path that shares more than intended.
  • Expecting WAF on the ALB alone to stop direct access. If the ALB accepts traffic from anywhere, attackers can skip CloudFront and its rules.

Try the 1 practice question

Practice Securing CloudFront origins and edge access (OAC, signed URLs, headers, CORS)Take the free practice exam

Question 1

Harder ·Link to this question (question 1)

A video streamer serves its catalog from an Amazon S3 bucket through an Amazon CloudFront distribution. The objects are encrypted with a customer managed AWS KMS key, because the studio's contracts require that key.

Viewers must reach the videos only through CloudFront. The bucket must not allow public access, and the setup must keep working for new objects that are encrypted with that KMS key.

Which configuration meets these requirements?

Choose one answer.

  1. A. Attach an origin access control to the distribution. Allow the CloudFront service principal to read for this distribution in the bucket policy, and to decrypt in the KMS key policy.
  2. B. Create a legacy origin access identity for the S3 origin, add it to the bucket policy as the only reader, and leave the KMS key policy unchanged, since CloudFront already reads the bucket.
  3. C. Make the bucket public for reads so that CloudFront can reach it, and add a bucket policy that denies requests that do not come from CloudFront IP ranges.
  4. D. Have the application generate a presigned Amazon S3 URL for each video, and let CloudFront pass the signed URLs to viewers, with no bucket policy change and no origin access setting on the distribution.
Show the answer and explanation

Answer: A

  • A. Right: Correct. Origin access control signs the requests to S3, and the bucket policy limits reads to this distribution. OAC works with SSE-KMS objects once the key policy allows CloudFront to decrypt, which the legacy identity does not support. Learn more: Restricting access to Amazon S3 origins (opens in a new tab)
  • B. Wrong: A legacy origin access identity cannot read objects that are encrypted with SSE-KMS, so the videos would fail to load. The key policy also still has to allow the reader to decrypt.
  • C. Wrong: Public read access breaks the no-public-access requirement, and IP ranges change over time. An IP-based deny is also a weak way to limit reads to one distribution.
  • D. Wrong: Presigned URLs are checked by S3 for each link, not by CloudFront, so the design leaves the distribution out of the access control. The bucket would also still need its public access blocked.

Explanation

Origin access control keeps the bucket private and limits reads to one distribution. It also covers SSE-KMS objects when the key policy grants decrypt to the CloudFront service principal. A legacy identity, a public bucket and presigned URLs each fail a stated requirement.

CloudFront with origin access control reading an SSE-KMS encrypted S3 bucket Users reach the objects through CloudFront, which signs its requests to the S3 bucket with origin access control. The bucket policy and the KMS key policy both allow the CloudFront service principal for this one distribution. A request straight to the S3 URL is denied. Users CloudFront signs with OAC S3 bucket policy: this distribution KMS key policy: this distribution Direct S3 URL denied
Origin access control signs CloudFront's requests, and both the bucket and key policies allow only this distribution.

Study

Want more on Securing CloudFront origins and edge access (OAC, signed URLs, headers, CORS)? The 5 full-length practice sets have 5 more Securing CloudFront origins and edge access (OAC, signed URLs, headers, CORS) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets

Study Securing CloudFront origins and edge access (OAC, signed URLs, headers, CORS)

More Infrastructure Security topics