A CloudFront distribution uses an origin access identity (OAI) to access a private S3 bucket. The bucket denies access to everyone else. The app requires users to view a public login page, then receive signed cookies to access private directories. The distribution uses the default cache behavior with restricted viewer access pointed at the S3 origin. Accessing the login page returns a 403 Forbidden. How can the developer allow unauthenticated access to the login page while keeping private content secure?

The correct solution is to add a second cache behavior. CloudFront processes cache behaviors in order, from most specific to least specific. By creating a new cache behavior with a path pattern matching the login page (e.g., /login.html) and setting its viewer access to unrestricted, CloudFront will apply this rule for requests to the login page, allowing public access. The default cache behavior, which is more general and has restricted viewer access, will remain unchanged and continue to protect the private content. The other options are incorrect because: Changing the default cache behavior to unrestricted access for the login page would expose all other content if the new specific behavior was restricted, which is the opposite of what's needed. Failover origins are for high availability, not for conditional access based on paths. Modifying the S3 bucket policy to grant public read access to the login page object and using a CloudFront function to redirect would bypass CloudFront's OAI protection for that specific object, making it publicly accessible directly from S3, which is less secure and not the intended use of CloudFront functions for this scenario.