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.

• ✗

  The S3 bucket policy does not allow public access.

  Why it's wrong here

  The scenario states the S3 bucket has public read access enabled, which means the bucket policy or ACL allows anonymous s3:GetObject. With static website hosting, the bucket policy must allow public reads, and since the user explicitly indicated this is configured, the permissions are not blocking access. If the policy were the problem, the user would receive an Access Denied error directly from the S3 website endpoint, not a connection or resolution issue. Therefore, the symptom described is not explained by a missing public access policy.

• ✗

  The website does not support HTTPS and the browser blocks it.

  Why it's wrong here

  S3 website endpoints only support HTTP, not HTTPS, but modern browsers do not automatically block HTTP requests; they may display a security warning but still load the page. If the site were loading via HTTPS and the browser blocked it, the user would see a certificate error, not a complete failure to connect. The actual issue is that the alias record resolves to the REST endpoint, which does not serve website content and returns a 301/307 or 403 error, not a browser security block. Thus, HTTPS incompatibility is not the cause of the site not resolving.

• ✓

  The Route 53 alias record points to the S3 bucket's regional endpoint instead of the website endpoint.

  Why this is correct

  The S3 bucket has two distinct endpoints: the REST API endpoint (bucket-name.s3.amazonaws.com) and the static website endpoint (bucket-name.s3-website-region.amazonaws.com). For a custom domain to serve your static website, the Route 53 alias record must target the website endpoint, because that endpoint processes requests with the Host header matching the custom domain and returns the index document. If the alias record mistakenly points to the REST endpoint, the request is handled by the S3 API, which expects path-style addressing and returns a 403 Forbidden or a connection error when it receives a Host header for a custom domain. This is the classic misconfiguration that prevents the website from appearing.

• ✗

  The DNS TTL is too long and the changes have not propagated.

  Why it's wrong here

  Route 53 alias records are not subject to the same TTL-based caching as standard DNS records because they are evaluated at the authoritative DNS layer and resolve to AWS-specific virtual IPs. Even if a resolver cached an old record, the TTL would only affect how long a client might use the previous IP; but the real problem is that the alias target itself is incorrect. Waiting for DNS propagation would not change the target from the REST endpoint to the website endpoint, so the issue persists indefinitely despite TTL expiration. A long TTL could cause a delay in changes taking effect, but only if the record were correct and later updated; here the record is wrong from the start.

Go deeper

Related to this question