Question 40
Domain 1: Agent Architecture, Design, and DevelopmentYou're deciding whether to keep agent state (conversation, working memory, in-flight plan) inside the agent process or to externalize it to a database/cache. The system must survive pod restarts, scale horizontally, and allow any replica to handle any user turn. Select TWO design choices that satisfy these requirements.
Correct answer: AD
Explanation
Keeping state in a shared store lets the system survive pod restarts because the data is not lost with any one process. It also supports horizontal scaling and “allow any replica to handle any user turn” because each replica is “effectively stateless” and can load conversation and plan state by session ID from Redis, Postgres, or a managed conversation service.
Why each option is right or wrong
A. Externalize conversation state and intermediate plan state to a shared store (e.g., Redis, Postgres, or a managed conversation service) keyed by session ID, and treat each agent replica as effectively stateless.
The requirement to survive pod restarts and let any replica serve any turn is met by persisting both conversation and in-flight plan state outside the pod, because process-local memory is lost on restart and cannot be shared across replicas. In practice this means storing the state in a shared backend such as Redis or Postgres, indexed by a session ID, so each request can rehydrate the agent context regardless of which pod receives it; this is the standard stateless-replica pattern used for horizontal scaling.
B. Keep all conversation state in process memory of each agent replica and rely on Kubernetes liveness probes to detect failures so the user is rerouted before any state is lost.
C. Use sticky sessions pinning every user to a specific replica forever, so each replica becomes the canonical owner of that user's state without any external store.
D. Use a session-affinity-free load balancer in front of agent replicas, since each replica reads/writes the externalized state and doesn't need sticky routing.
E. Store all agent state inside the LLM's parametric memory by fine-tuning continuously on every conversation, so no external state store is needed.