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.

• ✓

  Memorystore for Redis

  Why this is correct

  Memorystore for Redis is a fully managed in-memory data store compatible with the Redis protocol, offering sub-millisecond latency for key-value lookups—exactly what session state requires. Cloud Run instances are stateless and ephemeral, scaling to zero when idle, so placing sessions in a shared cache like Memorystore ensures user state survives individual instance lifecycles and remains accessible across autoscaled replicas. Furthermore, Redis-native features such as TTLs, atomic increments, and SETNX are ideal for session expiry, rotation, and concurrency control, making it the correct choice for low-latency session persistence.

• ✗

  Cloud Storage

  Why it's wrong here

  Cloud Storage is an object storage service designed for immutable, blob-based data such as images, videos, backups, or static assets—not for frequently updated, small mutable session records. Each read or write operation involves an HTTP request to bucket objects, which introduces latency in the tens to hundreds of milliseconds, far too slow for per-request session validation. Moreover, Cloud Storage lacks native atomic update operations or built-in TTLs for per-object expiry, so implementing session state would require custom JSON patching and external lifecycle management, making it an awkward and high-latency fit.

• ✗

  Cloud SQL

  Why it's wrong here

  Cloud SQL is a fully managed relational database service providing ACID transactions and durable, disk-backed storage, but this power comes with overhead that is counterproductive for session state. Every session lookup requires establishing a TCP connection, parsing SQL, and executing a query, resulting in significantly higher latency and connection-pool pressure compared to an in-memory cache. While you could technically create a sessions table, the relational model, strict consistency guarantees, and persistent storage are overkill for transient ephemeral data, and in high-traffic serverless apps the connection limits become a scaling bottleneck. The service is better suited for transactional business data such as orders, users, and inventory.

• ✗

  Cloud Pub/Sub

  Why it's wrong here

  Cloud Pub/Sub is a fully managed asynchronous messaging service built for event streaming, fan-out, and decoupling microservices, with push/pull delivery semantics. Messages are consumed and acknowledged (or retained only briefly by policy), and it does not provide point lookups, key-value reads, or updates on arbitrary keys—so it cannot function as a session store. Session state requires random access and in-place mutation, whereas Pub/Sub is designed for one-time, ordered (or unordered) event delivery. Attempting to use it for session state would require an additional durable store to hold the actual state, which defeats the purpose and introduces unnecessary architectural complexity.

Go deeper

Related to this question