Question 660
A migrated ecommerce application holds customer session state in each EC2 process memory. Clients move between servers during scaling and lose their shopping baskets. The business wants a managed low-latency shared session tier. Which architecture is suitable?
- Enable ALB sticky sessions and retain the only session record in one process memory even during a host replacement or fleet scale-in.
- Use CloudTrail event history as a writable low-latency transactional session database.
- Externalize session state to a compatible ElastiCache Redis-compatible cluster with TTL and failure handling.
- Use DynamoDB TTL alone while leaving application session state solely in EC2 process memory with no shared table or read path.
Explanation
Correct Answer
C:Shared in-memory session state lets requests land on different application instances without depending on one process lifetime.
Incorrect Answers
A:Stickiness can reduce redistribution but cannot preserve process-local state when the associated node fails or is replaced.
B:Audit events are not the application session data interface or TTL-controlled session store.
D:A TTL setting on an unused table cannot externalize state across application instances or provide cache-miss reconstruction.
Question 661
A company already ingests sequence-numbered events into a Kinesis data stream. Three independent consumers use shared-throughput `GetRecords` polling on each shard, and their aggregate reads have reached the shard's shared throughput ceiling; latency for one consumer rises whenever another runs a catch-up job. The producers and partition keys are healthy. What consumer-side change most directly isolates read throughput?
- Increase the stream retention period from one day to ten days and assume retention grants every polling consumer a separate shard-read throughput limit.
- Register eligible enhanced fan-out consumers and use `SubscribeToShard` or a supported Kinesis Client Library integration so each consumer has dedicated per-shard read throughput rather than sharing `GetRecords` capacity.
- Switch the Kinesis stream to on-demand capacity mode without changing the `GetRecords` clients, assuming each reader automatically receives its own independent shard-read allotment.
- Increase the number of shards but leave the three applications polling the same hot partition key through `GetRecords`, assuming resharding alone removes read competition on the hot shard.
Explanation
Correct Answer
B:Enhanced fan-out provides a dedicated per-consumer per-shard read allowance and pushes records to registered consumers, avoiding competition for the shared polling read capacity. It fits the measured contention without changing working producers or the stream's overall purpose.
Incorrect Answers
A:Retention determines how long records can be replayed, not the amount of per-consumer shard read capacity. Increasing retention would address the separate another practice scenario replay-horizon decision but leave the current throughput contention intact.
C:Stream capacity mode can affect aggregate shard capacity and scaling, but does not turn multiple standard pollers into enhanced fan-out registered consumers. They still share shard read throughput until the consumption pattern changes.
D:Resharding may spread partition keys over more shards, but records for one hot key remain ordered on its assigned shard and polling applications share that shard's read throughput. Dedicated per-consumer enhanced fan-out more directly fixes the stated contention.
Question 662
An application has already selected an ECS Fargate task to run a containerized 90-minute batch conversion. Operators now need a Step Functions workflow to start exactly one approved task per job, wait for the task to finish, inspect its final status, and only then start a dependent quality-check task. They must not use short Lambda polling loops as the execution coordinator. Which service integration pattern is most appropriate?
- Use a Step Functions Standard Task state with the optimized ECS RunTask.sync service integration and explicit error/cancellation handling before advancing to the quality check.
- Use ECS RunTask request-response only and immediately begin the quality-check task, treating a successful API launch response as completion of the container work.
- Use a series of 15-minute Lambda invocations that keep task completion state only in runtime memory and assume it persists when containers restart.
- Use an S3 bucket policy to detect ECS task completion and automatically resume the state machine, without configuring any supported service integration or callback.
Explanation
Correct Answer
A:Step Functions supports optimized ECS RunTask.sync integration, which waits for task completion and propagates task invocation failures to the workflow before dependent steps.
Incorrect Answers
B:An ECS task launch acknowledgement is not proof that the CPU-intensive conversion finished, so downstream validation could run too early.
C:Ephemeral Lambda memory and repeated invocation timeouts are not the durable wait-for-container-completion integration requested.
D:An S3 resource policy controls object access; it does not track task lifecycle and resume a Step Functions execution.
Question 663
A migrated reservation system uses PostgreSQL transactions and relational constraints and must remain compatible with existing SQL client libraries. The team is tempted to use DynamoDB solely because it is serverless. Which database selection is most defensible?
- Choose a supported managed PostgreSQL-compatible RDS or Aurora deployment and validate scaling, HA and SQL compatibility.
- Migrate the existing PostgreSQL schema to DynamoDB without redesigning relational joins, foreign keys or client SQL expectations.
- Move the PostgreSQL data to S3 tables and treat object prefixes as enforced SQL foreign keys for live transactions.
- Use CloudFront as the primary transactional SQL database engine because it caches web responses.
Explanation
Correct Answer
A:Relational SQL transactions and constraints justify evaluating managed relational engines before redesigning data for a key-value service.
Incorrect Answers
B:DynamoDB requires deliberate access pattern and API design; it does not preserve ordinary PostgreSQL joins and constraints automatically.
C:S3 object storage is not a compatible PostgreSQL transactional endpoint with native relational constraints.
D:Edge caching does not implement PostgreSQL queries, ACID tables or relational constraints.
Question 664
A legacy analytics application already uses Apache Cassandra clients and CQL statements to write large sparse event tables. The cloud migration must keep the supported CQL read/write interface while removing customer-managed Cassandra nodes; engineers will assess unsupported Cassandra extensions before cutover. Which AWS managed database should they evaluate?
- Move the CQL application to DynamoDB and assume the Cassandra driver and unsupported CQL statements can run unchanged.
- Use Amazon Keyspaces (for Apache Cassandra), verify its supported CQL operations and data model, and migrate the tables and clients accordingly.
- Use Amazon S3 static website hosting as a CQL-compatible service that executes Cassandra writes directly.
- Use a self-managed Cassandra cluster on EC2 and describe its node operations as a fully managed serverless CQL service.
Explanation
Correct Answer
B:Amazon Keyspaces offers managed, serverless Cassandra-compatible CQL access for supported operations, reducing cluster operations while requiring feature-compatibility checks.
Incorrect Answers
A:DynamoDB has a different API and query model and is not wire-compatible with ordinary Cassandra CQL clients.
C:S3 static website hosting cannot execute a Cassandra query protocol or provide row-level CQL mutation semantics.
D:Running Cassandra servers on EC2 retains host and cluster operations, contradicting the managed-service goal.
Question 665
A migrated SaaS app must run complex fraud screening models against each transaction, but users require sub-second predictions and the organization does not want to maintain the model server fleet. Which AWS inference hosting option should be assessed?
- Use SageMaker Batch Transform and wait for scheduled batch jobs to create prediction files for each interactive payment decision.
- Use SageMaker Asynchronous Inference with a job queue and delayed result retrieval for the synchronous high-speed payment authorization path.
- Use a suitable Amazon SageMaker managed real-time inference endpoint with autoscaling and network/security controls.
- Use a monthly AWS Glue crawler as the synchronous prediction API for each payment request.
Explanation
Correct Answer
C:Managed inference endpoints host model execution for low-latency requests without the team maintaining raw model servers.
Incorrect Answers
A:Batch Transform does not provide the required interactive subsecond inference endpoint.
B:Asynchronous inference suits long-running or large payload processing, not a blocking low-latency payment decision.
D:Catalog crawlers discover data schemas rather than serving per-request model inference.
Question 666
An Amazon OpenSearch Service application queries the alias `catalog-current`. The team must change the index mapping for a new search release, which requires creating and backfilling a new index instead of modifying the existing field type in place. The application cannot tolerate an index-not-found window, and the previous index must be available for rollback. How should the release be cut over?
- Delete the current index first, then create the new index under the same physical name and allow production searches to fail until reindexing completes.
- Enable Index State Management rollover on the existing index and assume it changes the incompatible field mappings in already-indexed historical documents without backfill or a new validated index.
- Create and populate a versioned replacement index, validate query and synchronization behavior, then atomically change the OpenSearch alias to point to the replacement while retaining the old index for rollback.
- Increase the OpenSearch primary shard count only and assume a different field mapping and tokenizer can be applied to existing indexed documents without reindexing.
Explanation
Correct Answer
C:A versioned index allows the new mapping to be built and tested while production continues using the old one. OpenSearch alias updates support an atomic remove/add switch after synchronization, so clients keep a stable name and rollback can restore the former alias target.
Incorrect Answers
A:Deleting the only live index before backfill creates a predictable outage and removes the immediate rollback source. It violates the stated requirement that `catalog-current` remain searchable throughout the transition.
B:Index State Management helps rotate or tier indexes, but it does not rewrite the existing index's incompatible historical field mapping in place. The new mapping needs a separate populated index and controlled query switch.
D:Shard-count changes address distribution and capacity, not all indexed field mapping incompatibilities. Certain field mapping changes require creating and reindexing a new target before changing query routing.
Question 667
An application is migrating to ECS and will use both On-Demand capacity and Spot for independent stateless workers. Teams want task placement to follow capacity provider strategies instead of hard-coding individual EC2 instance IDs. What should be configured?
- Use appropriate ECS capacity providers and base/weight strategies with validated task availability and interruptions.
- Set ECS service launchType=EC2 and manually pin tasks to fixed instance IDs rather than choosing eligible capacity providers.
- Use a single S3 bucket policy as the scheduler for ECS task placement across independent providers.
- Use an ECS cluster capacity provider but provide zero valid placement weight and no base capacity while expecting all workloads to schedule deterministically.
Explanation
Correct Answer
A:Capacity provider strategies let ECS select suitable infrastructure capacity for service and task placement.
Incorrect Answers
B:Pinned hosts lose the requested provider strategy flexibility as ECS and Auto Scaling capacity changes.
C:Object authorization does not manage ECS capacity provider selection or task placement.
D:Capacity provider strategies need supported base/weight allocation and usable provider capacity; incomplete configuration does not meet the placement requirement.
Question 668
A company is planning a new time-series database in November 2026 to retain several years of high-cardinality industrial measurements. Queries include SQL analytics over historical windows, while production requires managed multi-node high availability and compaction to keep old-data queries efficient. The company was never a Timestream for LiveAnalytics customer. Which eligible managed AWS time-series design should it evaluate?
- Onboard a new Amazon Timestream for LiveAnalytics account in November 2026 and assume it still accepts first-time customers after June 20, 2025.
- Evaluate Amazon Timestream for InfluxDB 3 Enterprise with high-availability multi-node deployment, SQL queries, historical indexing and compaction.
- Choose InfluxDB 3 Core because single-node execution and no compaction are guaranteed to provide better availability and long-term query efficiency than Enterprise.
- Use S3 Intelligent-Tiering alone as a live SQL-capable time-series compute engine, without an analytics query service.
Explanation
Correct Answer
B:Timestream for InfluxDB 3 Enterprise supports managed multi-node HA, native SQL, optimized long-term data queries and compaction suited to historical high-cardinality analytics.
Incorrect Answers
A:Timestream for LiveAnalytics stopped accepting new customers June 20, 2025; the question explicitly describes a new customer in 2026.
C:InfluxDB 3 Core lacks multi-node HA, compaction and optimized long-horizon analytics, all of which this workload explicitly requires.
D:S3 storage classes manage object placement but do not by themselves execute the required live SQL time-series analytical queries.
Question 669
A migrated e-commerce monolith calls its inventory update component synchronously after accepting an order. Any inventory service slowdown exhausts web request threads, although the business permits short asynchronous processing delays. Which modernization most directly removes that coupling without silently losing requests?
- Add retries and longer HTTP timeouts around the existing synchronous inventory call while allowing each web thread to wait for inventory completion.
- Put the order update on a durable SQS queue, use idempotent inventory consumers, configure a DLQ, and acknowledge orders after persistence.
- Publish inventory changes to a nonpersistent in-memory channel and acknowledge orders, with no durable subscriber, retry policy or failure destination.
- Publish accepted inventory updates to an SNS topic with no durable inventory consumer or failure destination and acknowledge orders on publish alone.
Explanation
Correct Answer
B:Asynchronous durable queueing decouples service availability and processing rates; worker idempotency and failure redrive make retries controlled instead of dropping tasks.
Incorrect Answers
A:Retries/longer timeouts increase time spent blocked on the failing dependency; durable asynchronous queueing removes inventory processing from the request path.
C:Ephemeral pub/sub can lose accepted work while inventory is unavailable; a durable queue with redrive is required.
D:SNS fanout without a durable worker subscription/failure strategy does not guarantee eventually processed inventory updates through long consumer outages.
Question 670
A migrated claims processor executes multiple sequential external API steps, some of which may take minutes and need retries with compensation on failure. Operators currently coordinate steps by custom timeouts embedded in Lambda handlers. Which modernization best externalizes workflow state?
- Use separate EventBridge scheduled rules to invoke each external API step on a static timer, without durable step success tracking or compensation branches.
- Chain Lambda calls and keep long-running workflow state only in a single API process, assuming compensation and retries survive process shutdown automatically.
- Use AWS Step Functions with a suitable state machine, explicit retries, timeouts and compensating actions for the long-running process.
- Run all steps in a single Lambda invocation using local variables to preserve the workflow, assuming executions can exceed the service timeout without interruption.
Explanation
Correct Answer
C:Step Functions represents durable workflow progress and retry/branch behavior outside individual Lambda invocations, enabling auditable orchestration.
Incorrect Answers
A:Schedules are time triggers rather than a state machine that records step completion, branches, retries and compensating actions during long-lived claims workflows.
B:Lambda and process-local state are not a durable end-to-end workflow controller; Step Functions owns durable state transitions and retry/compensation logic.
D:Lambda invocation duration and memory state are bounded; Step Functions externalizes durable progress and controls retries, wait states and compensation.
AWS Certified Solutions Architect - Professional SAP-C02 Practice Tests