A payment app behind an Application Load Balancer must enforce encrypted browser connections using only strong TLS, automatically redirect HTTP to HTTPS, and pass audits proving weak ciphers are disabled. Users connect globally with modern browsers. Which load balancer control best enforces encrypted connectivity?

An HTTPS listener with a strong TLS security policy and an HTTP-to-HTTPS redirect is the right control: TLS terminates at the Application Load Balancer, where the policy restricts negotiation to strong protocols such as TLS 1.2 and higher and disables weak cipher suites, providing auditable evidence. Redirecting HTTP ensures clients reach encryption rather than relying on backend code. An HTTPS listener with a strong policy but no automatic redirect leaves plain HTTP reachable, so unencrypted requests can still succeed. An HTTPS listener that redirects HTTP but uses a legacy policy for older-protocol compatibility does not meet the strong-only requirement; weak protocols or ciphers may remain enabled and fail an audit. An HTTPS listener with strong TLS and redirection but a self-signed certificate does not meet the public-trust requirement for global modern browsers, which may warn about or block the connection; a public app needs a publicly trusted certificate with proper validation and renewal. Exam caveat: backend HSTS, WAF inspection, TCP passthrough, or backend TLS can add protection but cannot replace listener-level policy enforcement and auditable proof at the load balancer. Practical check: inspect the listener policy, confirm HTTP returns a 301 redirect to HTTPS, and use a TLS scanner to verify that only strong protocols and ciphers negotiate successfully.