Courseiva

Google PCA Manage implementation of cloud architecture Practice Question

A company is migrating a monolithic application to Google Kubernetes Engine (GKE). The application currently runs on a single Compute Engine instance and stores session state in local memory. The migration must support horizontal scaling and high availability. What should the company do to manage session state in the new architecture?

⚠ Common exam trap

Google Cloud often tests the distinction between 'making the application stateless' versus 'using sticky sessions or StatefulSets'—the trap here is that candidates may think session affinity (Option C) is sufficient for high availability, but it actually creates a single point of failure at the pod level.

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

✓

Refactor the application to store session state in Cloud Memorystore for Redis and make the application stateless.

Migrating to a stateless architecture with Cloud Memorystore for Redis allows the application to scale horizontally without session state being tied to any single pod. By externalizing session state to a managed, highly available Redis service, any pod can handle any request, which is essential for high availability and autoscaling in GKE.

Answer analysis

Option-by-option breakdown

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

  • ✓

    Refactor the application to store session state in Cloud Memorystore for Redis and make the application stateless.

    Why this is correct

    Storing session state in Cloud Memorystore for Redis externalises it from pod memory, so any replica can serve any request and pods can scale or restart freely, satisfying the horizontal scaling and high availability constraints of the GKE migration.

  • ✗

    Use a StatefulSet with a headless service to assign stable network identities to pods.

    Why it's wrong here

    Stable network identities give each pod a persistent hostname and storage, but the session data still lives inside that pod's local memory, so scaling out spreads users across pods that cannot see each other's sessions. StatefulSets suit stateful workloads needing per-pod identity, such as databases, not shared session state.

  • ✗

    Use GKE Ingress with session affinity (sticky sessions) to route requests to the same pod.

    Why it's wrong here

    Sticky sessions pin a user to one pod, so that pod's local memory still holds the only session copy; if it fails, the session is lost, defeating high availability. Session affinity suits short-lived, non-critical state where pod loss is tolerable, not the mandated resilience and horizontal scaling here.

  • ✗

    Store session state in Cloud SQL using a replicated database.

    Why it's wrong here

    Cloud SQL is a relational database engine, not a low-latency session store; every request would incur a SQL round trip, and a replicated instance adds failover lag rather than the fast, shared key-value access sessions need. It suits durable transactional records, not ephemeral per-request session lookups.

About these practice questions

Courseiva writes every PCA question from scratch — 807 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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 PCA 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 PCA exam.