Courseiva
hardMultiple Choice

Google ACE Practice Question: A company has an e-commerce application deployed…

A company has an e-commerce application deployed on Compute Engine instances in a managed instance group (MIG) behind an external HTTP load balancer. The application stores session data in an in-memory cache on each instance. Recently, the team noticed that users are being logged out unexpectedly and losing their shopping cart contents. The MIG is configured with autoscaling based on CPU utilization. The team suspects the issue is related to session persistence. They have considered the following options: A) Switch to an internal TCP/UDP load balancer with session affinity; B) Enable sticky sessions (session affinity) on the existing load balancer; C) Move session storage to a centralized service like Memorystore; D) Increase the instance size and disable autoscaling. Which solution permanently resolves the issue while maintaining scalability and fault tolerance?

⚠ Common exam trap

Many candidates think sticky sessions (session affinity) alone will fix session persistence, but they overlook that autoscaling and instance failures still cause data loss when sessions are stored locally—only a centralized external store like Memorystore provides true persistence and fault tolerance.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Move session storage to a centralized service like Memorystore

Storing session data in a centralized service like Memorystore (Redis) decouples session state from individual Compute Engine instances. This ensures that any instance in the managed instance group can serve any user request without losing session data, even as the MIG autoscales up or down. This approach permanently resolves the issue while maintaining scalability and fault tolerance, as Memorystore provides a highly available, in-memory data store that persists across instance lifecycle events.

Answer analysis

Option-by-option breakdown

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

  • ✗

    Switch to an internal TCP/UDP load balancer with session affinity

    Why it's wrong here

    An internal TCP/UDP load balancer only accepts traffic from within the VPC network, so it cannot serve public e-commerce customers. While session affinity would route a client's connections to the same backend VM, the affinity is tied to the instance's IP address; if that instance is deleted, recreated, or fails a health check, all in-memory session data is permanently lost. Additionally, TCP/UDP load balancing does not terminate HTTP(S) requests, so it cannot inspect cookies or offer application-layer session persistence. This approach fundamentally misplaces the load balancer tier and still leaves session state coupled to an individual VM.

  • ✗

    Enable sticky sessions (session affinity) on the existing load balancer

    Why it's wrong here

    Scaling up the VM size and disabling autoscaling removes the elasticity needed for e-commerce traffic spikes and creates a single point of failure. Even a larger VM runs a single operating system and local process; if that instance crashes or is replaced due to maintenance, all session objects held in its heap or local disk vanish. Without autoscaling you cannot add or remove instances dynamically, so you also lose the ability to absorb load increases gracefully. This change only postpones availability and scalability problems while doing nothing to decouple session state from the compute instance.

  • ✓

    Move session storage to a centralized service like Memorystore

    Why this is correct

    Enabling sticky sessions (session affinity) on the existing load balancer forces all requests from a given user to be directed to the same backend instance. However, the session data is still stored in that instance's local memory, so the affinity is only as durable as the instance itself. When the instance is restarted for patching, fails a health check, or is removed during a scale-in event, the load balancer reroutes traffic to a different instance that has no copy of the original session, causing the user to lose their cart or login. Sticky sessions merely tie the client to a VM; they do not replicate or persist the session state across the instance lifecycle.

  • ✗

    Increase the instance size and disable autoscaling

    Why it's wrong here

    Moving session storage to Memorystore (a managed Redis service) makes the e-commerce application's compute instances completely stateless with respect to user sessions. Each HTTP request can be served by any healthy instance because session data is read from and written to a centralized, in-memory cache that lives outside the instances. This design survives instance failures, autoscaling events, and rolling deployments, because the session is stored independently of any single VM. Memorystore also provides sub-millisecond latency and high availability, while offloading memory management from the application heap, making it the only correct solution to the session-loss problem.

Visual reference

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

About these practice questions

This ACE question is part of Courseiva's 775-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.