SOA-C02 Networking and Content Delivery Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Generate presigned URLs for all objects in the S3 bucket.

  Why it's wrong here

  Presigned URLs grant temporary, time-limited access to specific S3 objects, but they are issued to end users and allow direct downloads from S3, bypassing CloudFront entirely. If you generate presigned URLs for every object, viewers can access the bucket directly, defeating CloudFront's caching, logging, and protection benefits. Additionally, presigned URLs expire, so they are not a viable long-term content delivery mechanism. This approach does not restrict access to CloudFront; it actually opens a separate access path.

• ✓

  Configure the S3 bucket policy to grant the OAI s3:GetObject permission.

  Why this is correct

  Configuring the S3 bucket policy to grant the OAI s3:GetObject permission is the critical step that makes the origin access control effective. The policy explicitly identifies the OAI as the only principal allowed to read objects, which permits CloudFront to fetch content on behalf of viewers while denying all direct S3 access requests. This is the recommended pattern because it combines the OAI identity with the necessary authorization, ensuring that the S3 bucket remains private and only CloudFront can serve content.

• ✗

  Configure CloudFront signed URLs to limit viewer access.

  Why it's wrong here

  CloudFront signed URLs are used to restrict who can access your content through CloudFront by requiring a valid signature and expiration time, but they do nothing to protect the S3 origin itself. If the S3 bucket is publicly accessible or has a policy that allows other principals, users can bypass CloudFront and access the objects directly. Therefore, signed URLs are a viewer-access control and cannot be used as an origin-restriction mechanism. To secure the origin, you must use an OAI or OAC combined with a bucket policy that denies all other access.

• ✓

  Create an Origin Access Identity (OAI) for the CloudFront distribution.

  Why this is correct

  Creating an Origin Access Identity (OAI) is a necessary prerequisite for private S3 origins because it provides CloudFront with a dedicated principal identity that can be used to access the bucket. However, simply creating the OAI does not grant any permissions; you must also attach a bucket policy that allows the OAI to perform s3:GetObject. The OAI is often used in conjunction with bucket policies to ensure that only CloudFront can access the objects, but it must be explicitly authorized. Thus, this step alone is insufficient unless paired with the appropriate S3 bucket policy.

• ✗

  Set the S3 bucket policy to allow access only from the CloudFront distribution ID.

  Why it's wrong here

  S3 bucket policies support principals such as AWS accounts, IAM roles, and canonical user IDs, but they cannot reference a CloudFront distribution ID. The OAI is the principal that CloudFront assumes when accessing S3, and you must specify its canonical user ID or ARN in the bucket policy. Using the distribution ID as a principal is invalid and will cause the policy to be rejected or to have no effect. This is why the correct approach is to grant the OAI permission, not the distribution ID.

Go deeper

Related to this question