Which solution will meet these requirements?
Add a second cache behavior to the distribution with the same origin as the default cache behavior. Set the path pattern for the second cache behavior to the path of the login page, and make viewer access unrestricted. Keep the default cache behavior’s settings unchanged.
Add a second cache behavior to the distribution with the same origin as the default cache behavior. Set the path pattern for the second cache behavior to *, and make viewer access restricted. Change the default cache behavior’s path pattern to the path of the login page, and make viewer access unrestricted.
Add a second origin as a failover origin to the default cache behavior. Point the failover origin to the S3 bucket. Set the path pattern for the primary origin to *, and make viewer access restricted. Set the path pattern for the failover origin to the path of the login page, and make viewer access unrestricted.
Add a bucket policy to the S3 bucket to allow read access. Set the resource on the policy to the Amazon Resource Name (ARN) of the login page object in the S3 bucket. Add a CloudFront function to the default cache behavior to redirect unauthorized requests to the login page’s S3 URL.
Explanations:
This option allows for a separate cache behavior specifically for the login page, with unrestricted viewer access. It keeps the default cache behavior intact for all other requests, maintaining security for private content stored in the S3 bucket. Thus, unauthenticated users can access the login page without affecting the access control for other resources.
This option incorrectly changes the path pattern of the default cache behavior to the login page while setting the viewer access as unrestricted. This would expose the entire bucket content to unauthenticated users, violating security requirements.
While this option suggests adding a second origin, it introduces unnecessary complexity. Setting a failover origin does not inherently allow access to the login page without additional configurations. It could lead to confusion and may not effectively restrict access to other content.
This option proposes modifying the S3 bucket policy to allow public read access to the login page. However, it would expose the login page to anyone who knows the URL, which could compromise security. Additionally, using a CloudFront function to redirect unauthorized requests does not provide a clean solution for unauthenticated access to the login page.
I map out that the answer is:
Add a second cache behavior to the distribution with the same origin as the default cache behavior. Set the path pattern for the second cache behavior to the path of the login page, and make viewer access unrestricted. Keep the default cache behavior’s settings unchanged.