AWS Certified Solutions Architect - Associate SAA-C03 Practice Test 47
Question 460
An AWS Batch platform must run one class of GPU inference jobs and another class of low-memory CPU transforms. The resources have very different cost and priority profiles. Which Batch constructs should separate scheduling?
- Put all jobs in one process on one untyped EC2 instance because Batch ignores CPU, GPU and memory differences.
- Define suitable job definitions and queues associated with compute environments matched to the resource classes.
- Use only S3 object tags to allocate GPUs to Batch jobs, without job resource definitions.
- Require all GPU tasks to run through API Gateway synchronous integrations until they finish.
Explanation
Correct Answer
B:Job definitions express workload resource needs, while queues and compute environments let the scheduler map workloads to appropriate capacity.
Incorrect Answers
A:Batch can schedule by job resource requirements, and ignoring them risks failed placement and wasted capacity.
C:S3 metadata does not directly request container accelerators or govern Batch placement.
D:Long compute jobs are better scheduled separately than coupled to finite HTTP request timeouts.
Question 461
A Batch image-analysis job fails intermittently when an external metadata API throttles requests. The current operator relaunches the entire month-long pipeline on every failure. What Batch-level recovery helps?
- Configure bounded retry attempts and differentiate transient failures from permanent invalid-input errors.
- Disable Batch job logs so the external throttling error does not cause job failure.
- Provision only more S3 bucket capacity and expect the external metadata provider to remove rate limits.
- Set infinite retry attempts for every malformed input regardless of exit code or correction plan.
Explanation
Correct Answer
A:AWS Batch can retry unsuccessful jobs under supported strategy rules. Limits and failure classification avoid unlimited replay of hopeless work.
Incorrect Answers
B:Suppressing logs does not change the dependency's HTTP responses or provide controlled recovery.
C:Object storage capacity is unrelated to the third-party API's request throttling policy.
D:Unbounded retries can waste resources permanently without addressing deterministic data corruption.
Question 462
A satellite image pipeline runs large, interrupt-tolerant nightly Batch jobs. Cost matters more than strict immediate start, but workers must recover when discounted EC2 capacity is interrupted. Which compute plan is reasonable?
- Increase an EC2 Auto Scaling group’s maximum capacity while continuing to run every job on an interruptible Spot instance without checkpoints.
- Use a Spot-capable AWS Batch compute environment with checkpointable or retry-safe jobs and suitable fallback planning.
- Put a hard five-second completion SLA on Spot-only nodes and assume capacity interruptions are impossible.
- Disable all Batch retry settings so interrupted multi-hour jobs are silently discarded to reduce cost.
Explanation
Correct Answer
B:Batch can manage eligible Spot capacity for flexible jobs, but interruptions must be incorporated into retry and job state handling.
Incorrect Answers
A:Extra potential capacity may help replace compute but does not prevent a running Spot instance from receiving an interruption. Work needs durable checkpoints or other interruption-aware execution design.
C:Spot supply and termination are not a sound sole basis for strict real-time availability without alternatives.
D:Ignoring interruption recovery would sacrifice completed work and violate the pipeline's need to finish analysis.
Question 463
A retail company runs Spark SQL transformations over multi-terabyte S3 datasets twice each month. The jobs are parallelizable, tolerate startup delay, and have no requirement for custom persistent HDFS nodes. The operations team wants to avoid maintaining EC2-based EMR clusters between runs. Which option fits?
- Run the entire multi-terabyte Spark application in one Lambda invocation and use its default single invocation resource limits.
- Keep a manually operated Amazon EMR EC2 cluster at full peak capacity every day despite only two monthly job windows.
- Use Amazon EMR Serverless with a supported Spark application and per-job runtime roles, allowing workers to scale while jobs run.
- Use Athena partition projection as the execution engine for arbitrary long-running Spark code and custom JVM transformations.
Explanation
Correct Answer
C:EMR Serverless runs Spark without provisioning or maintaining an EC2 cluster, allocates workers as needed and releases them after processing.
Incorrect Answers
A:Lambda’s single-invocation runtime and memory envelope is not a substitute for a distributed multi-terabyte Spark runtime.
B:A continuously provisioned cluster can run Spark but carries idle-management and capacity overhead that conflicts with the intermittent workload.
D:Athena partition projection optimizes SQL partition metadata lookup; it does not execute a general Spark application.
Question 464
A Spark workload on EMR frequently spills data and runs out of executor memory, while input volume has doubled. The team scales the client web API but leaves the EMR cluster unchanged. What should be reviewed?
- Increase only spark.driver.memory and leave the undersized worker executors and their shuffle partitions unchanged.
- Increase EMR step concurrency so additional Spark jobs share the same fixed worker memory, without reviewing executor allocation.
- Change only spark.sql.shuffle.partitions to a very low value without examining skew or the available executor memory.
- Size and scale EMR processing resources and Spark executors based on observed memory, CPU and data-shuffle demands.
Explanation
Correct Answer
D:Distributed analytics capacity is determined by the processing nodes and execution layout; unrelated web API scaling does not increase executor memory.
Incorrect Answers
A:Driver memory affects the coordinator, not the heap available for the worker executors reported as running out of memory. Executor sizing and partition/shuffle behavior still require investigation.
B:Submitting more jobs into an already memory-constrained cluster increases contention rather than addressing per-executor heap, parallelism or shuffle-spill requirements.
C:Too few shuffle partitions can produce larger intermediate partitions and more memory pressure. Partition changes require workload measurements and suitable executor capacity, not an unmeasured blanket reduction.
Question 465
An EMR cluster is intentionally terminated after each nightly processing batch, but its team previously stored source datasets only on cluster-local disks. The next day's job cannot find the input. What should be externalized?
- Keep durable input and output datasets in Amazon S3 or another appropriate independent data store.
- Set a CloudWatch alarm on failed reads but leave all data only on short-lived worker disks.
- Store every dataset on the root EBS volume of the EMR primary node and assume cluster termination preserves all attached disks.
- Increase the terminated cluster's instance count after it has been deleted to recover the old node-local files.
Explanation
Correct Answer
A:Separating durable data from ephemeral EMR cluster nodes allows compute capacity to be shut down and recreated without losing source records.
Incorrect Answers
B:Monitoring detects failure but does not provide durable data independent of the compute lifecycle.
C:Cluster termination can delete underlying volumes; cluster-local storage is not the right sole durable data repository.
D:New instances do not inherently contain the ephemeral data from a previous terminated cluster.
Question 466
A company runs a two-hour EMR analytics job once a week. Its multi-node cluster remains idle for the other six days while costs accumulate. Which execution design reduces unused compute?
- Maintain a permanently running peak-sized EMR cluster even when no data processing is scheduled.
- Delete all retained S3 input files after each run so the existing cluster becomes cheaper.
- Increase the job's CloudWatch log retention because longer logs switch off idle EMR instance billing.
- Use transient EMR clusters or supported managed job execution and terminate processing capacity after completion.
Explanation
Correct Answer
D:Decoupled S3 datasets allow compute to exist only during scheduled work, avoiding days of unneeded EC2-backed cluster charges.
Incorrect Answers
A:Idle compute continues to generate cost and does not meet the explicit efficiency objective.
B:Removing source data harms repeatability and has no effect on charges for an otherwise idle EMR cluster.
C:Logs and cluster compute charges are independent billing resources, so this does not stop idle compute expense.
Question 467
A checkout workflow reserves inventory, charges a payment provider and then books shipment. The shipment step fails after the charge succeeds, leaving an inconsistent business transaction. What orchestration pattern should be added?
- Delete the workflow execution history, which automatically reverses payments completed by third-party providers.
- Use Step Functions Catch/error transitions that invoke appropriate compensating actions, such as payment reversal and inventory release.
- Increase Lambda memory for the shipment step and assume every permanent address-validation error is repaired.
- Retry shipment forever without exposing the committed charge or applying any business rollback path.
Explanation
Correct Answer
B:Multi-service operations are not one atomic database transaction. Explicit compensation helps restore a valid state after a downstream step fails.
Incorrect Answers
A:Execution logging is evidence; removing it cannot undo external side effects.
C:More compute cannot make an invalid destination valid or compensate for committed upstream operations.
D:Unbounded retries can leave customers charged and inventory locked without a defined recovery outcome.
Question 468
A workflow may retry its payment-refund compensation step after a timeout. The first refund could already be accepted by the payment provider. How should the compensation code prevent double refunds?
- Increase Step Functions logging verbosity alone; duplicate refunds are impossible when execution history is detailed.
- Choose a fresh random refund identifier for each retry so the provider treats every attempt as new.
- Give compensation a stable business transaction key and make the refund operation idempotent across retries.
- Disable the compensation state after the first request regardless of whether the provider accepted it.
Explanation
Correct Answer
C:Retries can occur when completion acknowledgement is lost. A durable idempotency key prevents repeated rollback from creating additional financial side effects.
Incorrect Answers
A:Logs help reconstruct actions but do not enforce uniqueness of the external payment transaction.
B:Different identifiers can cause multiple real refunds for one original charge when the first attempt succeeded.
D:Suppressing retries without outcome verification can leave a failed refund unresolved and the workflow inconsistent.
Question 469
A Step Functions activity waits on a remote partner for several minutes. Occasionally the partner hangs indefinitely, leaving the state stalled. Which state-machine contract helps detect stalled work?
- Remove all task timeouts so an unresponsive partner always finishes before any business deadline.
- Configure suitable task timeout and heartbeat handling when supported, plus retry or Catch paths for noncompletion.
- Increase the workflow's display name length to enable automatic partner health detection.
- Use only an S3 lifecycle expiration rule as the signal that a Step Functions activity is alive.
Explanation
Correct Answer
B:Explicit time boundaries and heartbeats let the workflow recognize dead workers and move to a controlled failure response.
Incorrect Answers
A:An indefinitely stuck dependency can hold state and exhaust deadlines without ever producing a valid result.
C:State-machine metadata does not implement task liveness or timeout transitions.
D:Object expiration is unrelated to heartbeats from the worker executing the workflow task.
Question 470
A document-validation workflow has completed three external service calls when a fourth fails. Operators need to resume safely without sending duplicate invoices from earlier stages. What must the state design preserve?
- Track durable progress and idempotent step boundaries so retries or resumes do not repeat already committed side effects.
- Configure unbounded Step Functions retries for every failed task, but omit business-operation idempotency keys for the invoices that previous tasks already issued.
- Make every external service request unconditional because Step Functions guarantees exactly-once effects in outside systems.
- Restart the workflow from the beginning after any failure and rely on the execution name alone to prevent previously committed invoice API calls from running again.
Explanation
Correct Answer
A:State-machine transitions and application idempotency are needed because re-execution across non-atomic services can otherwise resend earlier invoices.
Incorrect Answers
B:Step Functions retry behavior does not provide transaction atomicity for external billing systems. Without durable committed-step identifiers, retry/redrive can repeat a successful side effect.
C:Workflow execution does not atomically coordinate every independent provider's business write.
D:Execution naming may help identify workflow attempts, but does not make an external invoice endpoint idempotent. Durable per-step progress and operation IDs prevent duplicate effects on replay.
