Council wants the citizen auth gateway to scale horizontally without sticky sessions pinned to a particular EC2 host. Which session approach supports that goal?
Select an answer to reveal the explanation.
Short Explanation
Think hotel keycards that any front desk can swipe—not a room key locked in one clerk's drawer. Bearer tokens or an external session store let any auth instance validate the citizen. Sticky in-memory sessions, pinned private IPs, and a single giant box fight horizontal scale.
Full Explanation
Council wants the citizen auth gateway to scale horizontally without sticky sessions pinned to a particular EC2 host. Issue bearer tokens (or store sessions externally) so any instance can validate the request. JWTs validated with a shared secret/JWKS, or server sessions in ElastiCache/DynamoDB, let auto scaling add/remove instances freely during tax-deadline peaks without affinity maps.
Keeping encrypted session objects only in each EC2 instance’s local memory and enabling sticky sessions recreates host affinity and fails the no-sticky goal. Requiring citizens to reconnect to the same private IP after every page load is operationally absurd behind load balancers. Disabling auto scaling and running one oversized instance rejects horizontal scale and creates a single point of failure.
Exam caveat: bearer tokens need rotation, short TTL, and secure storage on clients; external session stores need encryption and TTL. Sticky sessions are sometimes a migration crutch—not the target architecture here.
Operational check: move to token or external session validation; disable stickiness on the ALB target group; scale out under load tests without login loss; and monitor auth latency as instances churn.