Cloud Digital Leader Google Cloud Products and Services Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Store session state in Cloud SQL and share across instances

  Why it's wrong here

  Storing session state in Cloud SQL introduces latency for every read and write operation, which degrades the performance of a stateful web application that requires fast, local session access. This option is tempting because Cloud SQL is a managed relational database that centralises data, making it an ideal choice for sharing persistent, non-session data across instances in a different scenario where latency is acceptable and strong consistency is required.

• ✗

  Configure Cloud CDN to cache session data

  Why it's wrong here

  Cloud CDN cache is designed for static content such as images, CSS, and JavaScript, with cache keys based on URL and headers. Session data is dynamic, user-specific, and frequently updated, so caching it at the edge would serve stale or cross-user data, breaking session isolation. Moreover, session state is typically stored in backend memory or a session store, which Cloud CDN cannot access or invalidate per user; trying to cache it would also introduce consistency issues and privacy risks. This option does not address the root problem of routing requests to the same backend instance, so it is incorrect.

• ✗

  Use a global load balancer with HTTP cookies to track sessions

  Why it's wrong here

  While a global external HTTP(S) load balancer can use cookies for session affinity, simply having HTTP cookies to track sessions does not enforce sticky routing. Without configuring the backend service's sessionAffinity mode (e.g., GENERATED_COOKIE or HEADER_FIELD) and appropriate cookie settings, the load balancer will distribute each request independently, causing a session to be spread across different backends. Cookies alone are just data; the load balancer must explicitly use them as a routing key to preserve local session state. Therefore, this option is incomplete and incorrect as stated.

• ✓

  Enable session affinity (sticky sessions) on the load balancer

  Why this is correct

  Enabling session affinity (sticky sessions) on the load balancer ensures that all requests from a given client during a session are routed to the same backend instance, as long as that instance remains healthy. This preserves the in-memory session state because the application can store session data locally on the instance, and subsequent requests are consistently directed to that same machine. The load balancer typically uses a hash of the client's IP address or a generated cookie to determine the backend, while still balancing load across different sessions. This directly solves the problem of a stateful web application without needing to externalize or replicate session state.

Go deeper

Related to this question