How Should You Encrypt User Credentials Behind a Load Balancer?
Your organization has an internet-facing application behind a load balancer. Your regulators require end-to-end encryption of user login credentials. You must implement this requirement. What should you do?
Community Votes
78% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Tests understanding of encryption-in-transit standards versus impractical client-side schemes, highlighting the trap of confusing theoretical end-to-end encryption with scalable cloud-native TLS termination.
Securing login credentials in transit requires implementing TLS/HTTPS between the client and the infrastructure. This page confirms that configuring a Global HTTPS Load Balancer with a valid TLS certificate is the standard and compliant solution.
Candidates often select asymmetric client-side encryption (D) assuming it guarantees true end-to-end security, overlooking that standard HTTPS termination at the edge meets regulatory compliance and scales efficiently.
Community Discussion (5 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Deploying a TLS certificate at the Global HTTPS Load Balancer establishes encrypted communication channels using industry-standard HTTPS protocols. This configuration satisfies regulatory mandates for credential protection because TLS effectively encrypts data in transit from the user’s browser to the cloud edge. Google Cloud’s managed load balancer natively handles TLS termination and can be configured for SSL bridging if backend services require re-encrypted traffic, ensuring continuous protection without compromising performance.Why the Other Options Are Wrong
Option A proposes distributing symmetric keys to clients, which introduces severe key management vulnerabilities and breaks standard web authentication flows. Option B relies on hashing credentials, which provides integrity verification rather than encryption and leaves passwords exposed to network sniffing and replay attacks. Option D suggests client-side asymmetric encryption, which is operationally unscalable, lacks native browser support for login forms, and unnecessarily complicates session management compared to standard TLS.Community Comment Notes
Several learners initially debated between options C and D, with some arguing that true end-to-end encryption demands client-side key handling. As zanhsieh noted, "End-to-end encryption should overweight scalability," but cloud exams prioritize scalable TLS termination over custom cryptographic workflows. Other contributors like MoAk clarified that modern load balancers support SSL bridging to re-encrypt traffic downstream, directly addressing concerns about the connection being stripped at the edge. The consensus correctly shifted toward recognizing HTTPS load balancing as the production-ready standard.Official Reference
Exam Strategy
When regulators mandate encryption for credentials in transit, prioritize standard TLS/HTTPS implementations over custom cryptographic workflows. Always map the requirement to managed services like the Global HTTPS Load Balancer rather than inventing complex client-side encryption schemes that break browser compatibility.
Frequently Asked Questions
Why isn't client-side asymmetric encryption required?
Standard HTTPS termination at the edge satisfies regulatory encryption mandates without breaking browser compatibility or session management.
Does HTTPS load balancer termination break end-to-end encryption?
No, the LB can be configured for SSL bridging to re-encrypt traffic to backend services, maintaining full encryption throughout the data path.