4 of the 6 questions we have for this objective, shown with the answer and the reasoning.
Design high-performing and elastic compute solutions
Willowmere Photos uses an AWS Lambda function named resize-image to generate thumbnails when photos land in an S3 bucket. The function is configured with 128 MB of memory and a 10-second timeout. CloudWatch Logs show that the function is CPU-bound during image decoding and frequently runs for 9 to 12 seconds, so a portion of invocations time out. Willowmere wants to reduce the duration and eliminate the timeouts with the simplest change.
What should a solutions architect recommend?
- AIncrease the function's memory setting to 1,769 MBLambda allocates CPU in proportion to memory; at 1,769 MB the function receives the equivalent of one full vCPU, so a CPU-bound task finishes several times faster and the timeout is no longer reached.
- BIncrease the function's timeout to 15 minutesA longer timeout stops the failures but leaves each invocation slow and billed for the full duration; it does not address the stated goal of reducing duration.
- CSet reserved concurrency on the function to 100Reserved concurrency controls how many invocations can run simultaneously; it has no effect on how fast a single invocation executes.
- DMove the resizing code to an EC2 instance behind an SQS queueRe-platforming to EC2 adds servers to manage and is far from the simplest change when a configuration adjustment solves the problem.
Why: Memory is the single performance dial in Lambda: it sets memory, and CPU and network bandwidth scale with it. A CPU-bound function at 128 MB is running on a small fraction of a vCPU; raising memory shortens duration, and because billing is memory multiplied by duration, the cost per invocation often stays flat or falls. The trap is treating the timeout as the problem and extending it, which hides the symptom instead of fixing the root cause. Use the AWS Lambda Power Tuning tool to find the memory setting that balances cost and speed.
Design high-performing and elastic compute solutions
Stonegate Weather runs a numerical weather model on 64 EC2 instances that exchange data constantly using MPI. The run time is dominated by inter-node communication, and the team needs the lowest possible network latency and highest node-to-node bandwidth. The model checkpoints to S3 every 30 minutes, so the loss of the whole fleet in a single hardware failure is acceptable.
Which configuration will meet these requirements?
- ALaunch the instances in a spread placement group across three Availability ZonesA spread placement group deliberately places instances on distinct hardware to reduce correlated failures, which increases rather than decreases the network distance between nodes.
- BLaunch the instances in a partition placement group with 7 partitionsPartition placement groups isolate groups of instances on separate racks for large distributed systems such as Hadoop; they do not pack instances for lowest latency.
- CLaunch EFA-enabled instances of the same type in a cluster placement group within a single Availability ZoneA cluster placement group packs instances close together on low-latency, high-bisection-bandwidth networking, and Elastic Fabric Adapter provides OS-bypass networking that MPI uses for the lowest latency between nodes.
- DDistribute the instances evenly across three Availability Zones behind a Network Load BalancerCross-AZ traffic adds latency, and a load balancer is irrelevant to peer-to-peer MPI communication between nodes.
Why: The three placement group strategies serve opposite goals: cluster packs instances for tightly coupled, latency-sensitive workloads; spread separates them onto distinct hardware for availability; partition groups them by rack for large distributed data systems. The scenario states that communication latency dominates and that a correlated failure is acceptable because of checkpointing, which removes the usual reason to spread instances out. Adding EFA on top of the cluster placement group gives MPI the kernel-bypass path it needs. The trap is reaching for multi-AZ by habit when the requirement is performance rather than availability.
Design high-performing and elastic compute solutions
Marrowfield Studios lets customers upload videos through a web tier that writes the files to an S3 bucket named marrowfield-uploads. A separate fleet of EC2 instances in an Auto Scaling group transcodes the videos. Today the web servers call the transcoding fleet over HTTP after each upload; when many uploads arrive at once, the calls fail and videos are never transcoded. Marrowfield wants the two tiers to scale independently and wants every uploaded video to be transcoded eventually, with the least operational overhead.
Which two actions should a solutions architect take? Each correct answer presents part of the solution.
- AIncrease the instance size of the transcoding fleet and set a fixed desired capacityBigger fixed capacity still fails under a larger burst and wastes money during quiet periods; it does not remove the synchronous dependency.
- BConfigure an S3 event notification on marrowfield-uploads that sends a message to an Amazon SQS queue, and have the transcoding fleet poll that queueThe upload itself becomes the trigger, the queue durably holds one message per video, and the web tier no longer calls the transcoders at all, so a slow consumer never causes a lost job.
- CEnable sticky sessions on the load balancer for the web tierStickiness controls which web server a browser session returns to; it is unrelated to the hand-off between the web tier and the transcoders.
- DConfigure the transcoding Auto Scaling group to scale on the queue backlog per instanceScaling the consumer fleet on queue backlog lets it grow during upload surges and shrink when the queue drains, which is what makes the two tiers independent.
- EStore the uploaded videos on an Amazon EFS file system shared by both tiersShared storage changes where files live but does not tell the transcoders what work is pending or buffer requests during a burst; the coordination problem remains.
Why: Decoupling has two halves: a durable buffer between producer and consumer, and a consumer that scales on the buffer rather than on the producer. S3 event notifications to SQS provide the buffer with no custom code in the web tier, and queue-based scaling closes the loop so the transcoding fleet tracks real demand. Options A, C, and E are genuine AWS features aimed at the wrong layer: capacity, session routing, and file placement respectively. On the exam, lost work during bursts plus independent scaling almost always resolves to a queue plus queue-driven Auto Scaling.
Design high-performing and elastic compute solutions
Pinefold Imaging processes medical scans from an SQS queue named scan-jobs with an Auto Scaling group of worker instances. Each job takes about 20 seconds, and the business requires that any scan be picked up within 5 minutes of arrival. Scaling on the ApproximateNumberOfMessagesVisible metric alone has caused both over-scaling (the same backlog triggers more instances even after the fleet has grown) and missed deadlines. Pinefold wants a scaling approach that accounts for the current fleet size and the processing time per job.
What should a solutions architect recommend?
- AUse a target tracking policy directly on the ApproximateNumberOfMessagesVisible metric with a target of 100Queue depth by itself ignores how many instances are already consuming; the same depth means a different per-instance load at different fleet sizes, which is exactly the oscillation the company observed.
- BReplace the queue metric with a target tracking policy on average CPU utilization of the workersCPU shows how busy existing workers are but says nothing about how many messages are waiting or whether the 5-minute pickup deadline will be met.
- CPublish a custom CloudWatch metric for backlog per instance (queue depth divided by running instances) and use a target tracking policy whose target equals the acceptable backlog derived from the 5-minute latency goal and 20-second job timeBacklog per instance normalizes queue depth by fleet size, and the target (300 seconds divided by 20 seconds, so about 15 messages per instance) is derived directly from the business SLA, which is the pattern AWS documents for SQS-driven scaling.
- DConfigure scheduled scaling to run the maximum number of workers during clinic hoursScheduled scaling does not react to actual arrivals; it over-provisions during quiet periods and still misses deadlines if an unexpected burst arrives.
Why: AWS recommends scaling queue consumers on a derived metric, backlog per instance, rather than raw queue depth, because raw depth does not account for the instances already working the queue. The target value falls out of the SLA arithmetic: acceptable latency divided by per-message processing time gives the number of messages one instance can own and still meet the deadline. Target tracking then keeps the fleet at that ratio. The trap is option A, which uses the right metric family but without normalization and so produces the over-scaling described in the scenario.