Answer: Configure a second cache behavior to the distribution having the same origin as the default cache behavior and have the path pattern for the second cache behavior as the path of the login page with viewer access as unrestricted. Keep the default cache behavior’s settings unchanged

Overall explanation Correct option: Configure a second cache behavior to the distribution having the same origin as the default cache behavior and have the path pattern for the second cache behavior as the path of the login page with viewer access as unrestricted. Keep the default cache behavior’s settings unchanged Cache behavior describes how CloudFront processes requests. You must create at least as many cache behaviors (including the default cache behavior) as you have origins if you want CloudFront to serve objects from all of the origins. Each cache behavior specifies the one origin from which you want CloudFront to get objects. If you have two origins and only the default cache behavior, the default cache behavior will cause CloudFront to get objects from one of the origins, but the other origin is never used. The pattern (for example, images/*.jpg) specifies which requests to apply the behavior to. When CloudFront receives a viewer request, the requested path is compared with path patterns in the order in which cache behaviors are listed in the distribution. The path pattern for the default cache behavior is * and cannot be changed. If the request for an object does not match the path pattern for any cache behaviors, CloudFront applies the behavior in the default cache behavior. For the given use case, you need to add a second cache behavior to the distribution having the same origin as the default cache behavior and list it above the default cache behavior in the distribution. The second cache behavior should have the path pattern as the path of the login page with viewer access set as unrestricted. This would allow access to the login page for unauthenticated users. Since the default cache behavior’s settings remain unchanged, it ensures the security of all private content that continues to have restricted viewer access. Incorrect options: Configure a second cache behavior to the distribution having the same origin as the default cache behavior and have the path pattern for the second cache behavior as * with viewer access as restricted. Modify the default cache behavior’s path pattern to the path of the login page and have the viewer access as unrestricted - This option is incorrect since the path pattern for the default cache behavior is always * and cannot be changed. Configure a new distribution having the same origin as the original distribution and set the path pattern for the default cache behavior of the new distribution as the path of the login page with viewer access as unrestricted. Keep the default cache behavior of the original distribution unchanged - If you have two origins and only the default cache behavior, the default cache behavior will cause CloudFront to get objects from one of the origins, but the other origin is never used. So this option is incorrect. Configure a second origin as the failover origin for the default behavior of the original distribution and have the path pattern for the second origin as the path of the login page with viewer access as unrestricted. Keep the behavior for the primary origin unchanged - You can set up CloudFront with origin failover for scenarios that require high availability. To get started, you create an origin group with two origins: a primary and a secondary. If the primary origin is unavailable or returns specific HTTP response status codes that indicate a failure, CloudFront automatically switches to the secondary origin. To set up origin failover, you must have a distribution with at least two origins. Next, you create an origin group for your distribution that includes two origins, setting one as the primary. Finally, you create or update a cache behavior to use the origin group. This option is incorrect since the failover kicks in only when the primary is unavailable. Therefore, access to the login page and the rest of the content will never work together.