How Should You Encrypt User Credentials Behind a Load Balancer?

PCSE By islever Editorial Last updated Sep 9, 2026

Short answer

C Deploy a TLS certificate at the Global HTTPS Load Balancer to encrypt user credentials in transit via HTTPS.

Question

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?

Generate a symmetric key with Cloud KMS. Encrypt client-side user credentials by using the symmetric key.
Concatenate the credential with a timestamp. Submit the timestamp and hashed value of credentials to the network.
Deploy the TLS certificate at Google Cloud Global HTTPs Load Balancer, and submit the user credentials through HTTPs. Correct Answer
Generate an asymmetric key with Cloud KMS. Encrypt client-side user credentials using the public key.

Key Takeaways

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.

Common mistake: 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.

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

These links open the official vendor documentation in a new tab.

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.

More PCSE FAQ →

Community Votes

78%

22%

78% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 5 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 5

MoAk 👍 1 Answered C

Initially I was with D however it then didn't seem very scalable option. I believe this is now Answer C. The load balancer would decrypt the connection to inspect the packets at L7 but would re-encrypt it (SSL bridging) for full end to end encryption. https://cloud.google.com/docs/security/encryption-in-transit#transport_layer_security
zanhsieh 👍 1 Answered D

I take D. End-to-end encryption should overweight scalability as the question described as "require".
f36bdb5 👍 1 Answered D

In case of C, the Load Balancer would strip the TLS connection, making it not end to end.
yokoyan 👍 4 Answered C

I think it's C.
jmaquino 👍 2 Answered C

C:

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

← Back to PCSE Study Guide