SAA-C03 Design Secure Architectures 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.

• ✓

  Remove public access from the bucket and update the bucket policy to allow GetObject only from CloudFront using the distribution’s SourceArn (and use CloudFront origin access control or origin access identity).

  Why this is correct

  Configure the S3 bucket to block all public access, then attach a bucket policy that grants s3:GetObject only to the CloudFront origin access control (OAC) identity, using the aws:SourceArn condition to restrict the principal to the exact CloudFront distribution ARN. This creates a hardened origin where the S3 bucket rejects any direct anonymous requests from the internet, while CloudFront's authenticated requests are permitted. Using OAC or OAI ensures the bucket owner has to intentionally authorize only that distribution, eliminating the common mistake of leaving objects publicly readable.

• ✗

  Enable S3 static website hosting and disable CloudFront, because website hosting blocks direct object URL access.

  Why it's wrong here

  S3 static website hosting exposes objects through the website endpoint (e.g., bucket.s3-website-region.amazonaws.com) but does not prevent access via the original REST endpoint; any bucket policy that permits public read keeps direct object URLs working. Website hosting also has no mechanism to restrict requests to a particular origin or distribution, and it lacks native HTTPS support on the custom website endpoint. Removing CloudFront would therefore not secure the content and would forfeit edge caching, TLS termination, and the ability to use features like WAF.

• ✗

  Add a WAF rule that rate-limits requests to the S3 bucket domain to make direct access impractical.

  Why it's wrong here

  AWS WAF is a service you attach to resources like CloudFront or Application Load Balancers, not directly to an S3 bucket, so a WAF rule cannot be applied to the bucket's own domain. Even if you added a rate-limit rule at CloudFront, it only throttles traffic coming through that distribution; browsers or scripts hitting the S3 endpoint directly would bypass the rule entirely. Rate limiting is also a mitigation, not an access control guarantee, and would not stop a low-volume attacker from reading every object.

• ✗

  Turn on S3 object versioning so that attackers cannot read previous objects.

  Why it's wrong here

  Object versioning stores multiple versions of each object to guard against accidental deletion or overwrites, but it has no effect on the bucket policy or the public-read permissions that make objects available via direct URLs. If an object is publicly readable, anyone can still download the current version, and in some cases versioned objects are accessible by including a version ID header. Enabling versioning actually increases the attack surface by retaining older versions that attackers could potentially read if permissions remain permissive.

Go deeper

Related to this question