Resolving Blocked Requests

Answer - A.

Option B is incorrect because this is used to prevent accidental deletion of objects in S3.

Option C is incorrect because this is used for Cross-region replication of objects.

Option D is incorrect because this is used to encrypt objects at rest.

The AWS Documentation mentions the following.

Cross-Origin Resource Sharing: Use-case Scenarios.

The following are example scenarios for using CORS:

Scenario 1: Suppose you are hosting a website in an Amazon S3 bucket named website described in Hosting a Static Website on Amazon S3

Your users load the website endpoint http://website.s3-website-us-east-1.amazonaws.com.

Now you want to use JavaScript on the webpages stored in this bucket to make authenticated GET and PUT requests against the same bucket by using the Amazon S3 API endpoint for the bucket website.s3.amazonaws.com.

A browser would normally block JavaScript from allowing those requests, but with CORS you can configure your bucket to enable cross-origin requests from website.s3-website-us-east-1.amazonaws.com explicitly.

Scenario 2: Suppose that you want to host a web font from your S3 bucket.

Again, browsers require a CORS check (also called a preflight check) for loading web fonts.

You would configure the bucket that hosts the web font to allow any origin to make these requests.

For more information on Cross-Origin access, please refer to the below URL-

https://docs.aws.amazon.com/AmazonS3/latest/dev/cors.html

The issue of the browser blocking requests made to the same bucket via the Fully Qualified Domain Name in the static website hosted on S3 can be resolved by enabling Cross-Origin Resource Sharing (CORS) on the bucket. Therefore, the correct answer is option A.

Explanation:

When a browser requests a resource from a different domain or origin, CORS comes into play. CORS allows the server to include additional headers in its response to the browser, indicating which origins are allowed to access the resources on the server. By default, web browsers block requests to different origins for security reasons.

In this scenario, the web pages and the Javascript calls are both in the same bucket, but the browser is still blocking the requests. This is because the browser considers the Fully Qualified Domain Name as a different origin, and therefore blocks the requests.

Enabling CORS on the bucket allows the server to specify which origins are allowed to access the resources. Once CORS is enabled, the server will include the necessary CORS headers in its response to the browser, allowing the browser to access the resources in the same bucket via the Fully Qualified Domain Name.

Option B, enabling versioning on the bucket, is not related to the issue described in the scenario. Versioning on a bucket allows you to keep multiple versions of an object in the bucket, but it will not resolve the issue of the browser blocking requests.

Option C, enabling Cross-Region Replication (CRR) on the bucket, is also not related to the issue described in the scenario. CRR is used to replicate objects between S3 buckets in different regions for disaster recovery and other purposes.

Option D, enabling encryption on the bucket, will not resolve the issue of the browser blocking requests. Encryption on a bucket provides an additional layer of security by encrypting the objects stored in the bucket, but it will not affect the ability of the browser to access the resources in the bucket.