Design scalable and loosely coupled architectures

Glasswing Genomics receives sequencing files in an S3 bucket named gw-raw-reads. Each file must be processed by a single-threaded alignment job that uses 24 GB of memory and runs for 40 to 90 minutes. Files arrive unpredictably, between 0 and 200 per day. The team currently triggers a Lambda function from the S3 event, but the function fails before completing. They want a solution that starts work automatically when a file arrives and runs nothing when the bucket is idle.

Which solution will meet these requirements?

1. ASend the S3 event to an Amazon SQS queue and scale an Amazon ECS on Fargate service with 32 GB tasks on queue depth, scaling to zero when the queue is empty.Fargate tasks have no 15-minute limit and can request large memory, SQS buffers the arrivals, and scaling the service to zero on an empty queue means nothing runs while idle.
2. BIncrease the Lambda function's memory to 10,240 MB and its timeout to 15 minutes, and configure provisioned concurrency.Lambda's hard limits are 10,240 MB of memory and 15 minutes per invocation, which cannot hold a 24 GB, 90-minute job; provisioned concurrency also bills while idle.
3. CSplit the alignment job into chained Lambda functions that each run for 14 minutes and pass intermediate state through S3.The job is single-threaded and memory-bound; chunking it does not solve the 24 GB memory requirement and adds fragile checkpointing code.
4. DRun a persistent r6i.xlarge EC2 instance with 32 GB of memory that polls gw-raw-reads every minute and processes any new files sequentially.A persistent instance runs and bills even when no files arrive, and a single instance cannot keep up with bursts of 200 files per day at up to 90 minutes each.

Hollowbrook Imaging processes photo-editing jobs from an Amazon SQS queue named hb-jobs using an Auto Scaling group of EC2 worker instances named asg-workers. Each instance processes about 10 messages per minute, and the business requires that a job wait no more than 5 minutes in the queue. Today the group scales on CPU utilization, and the backlog grows to thousands of messages during busy periods even though CPU stays moderate.

Which two actions should the team take to scale the workers on the actual backlog? Each correct answer presents part of the solution.

1. APublish a custom CloudWatch metric that divides ApproximateNumberOfMessagesVisible for hb-jobs by the number of InService instances in asg-workers.The backlog-per-instance metric expresses how much work each instance owns, which is what must be held within the 5-minute latency goal.
2. BCreate a target tracking scaling policy on asg-workers that targets the custom backlog-per-instance metric at the value an instance can clear in 5 minutes.Target tracking on the backlog-per-instance metric adds instances when the backlog grows and removes them as it drains, directly enforcing the latency requirement.
3. CCreate a target tracking scaling policy on asg-workers that targets ASGAverageNetworkIn.Network throughput is not correlated with queue backlog and would scale on the wrong signal, just as CPU does today.
4. DChange hb-jobs to a FIFO queue so that message counts are more accurate.FIFO changes ordering and throughput characteristics, not the accuracy of the ApproximateNumberOfMessagesVisible metric, and does not affect scaling.
5. ESet the visibility timeout on hb-jobs to 5 minutes so that messages are automatically dropped after the latency target.Visibility timeout controls how long a received message is hidden from other consumers; it does not drop messages and does not add capacity.

Juniper Learning hosts a web application on an Auto Scaling group named asg-web behind an Application Load Balancer. Load varies throughout the day with no predictable pattern. The operations team wants the group to keep average CPU utilization near 50 percent and does not want to write or tune individual scale-out and scale-in alarms.

Which scaling policy should the team configure?

1. AA target tracking scaling policy using the ASGAverageCPUUtilization metric with a target value of 50.Target tracking creates and manages the CloudWatch alarms automatically and adds or removes instances to hold the metric at the target value.
2. BA step scaling policy that adds two instances when CPU exceeds 70 percent and removes one when CPU falls below 30 percent.Step scaling works but requires the team to define and maintain the alarms and thresholds, which is what they want to avoid.
3. CA scheduled scaling action that sets the desired capacity to 10 every morning at 08:00.Scheduled scaling fits predictable patterns; the scenario states that load is not predictable.
4. DA simple scaling policy triggered by a manually created CPU alarm with a 300-second cooldown.Simple scaling needs hand-built alarms and waits for a cooldown before responding again, making it slower and more manual than target tracking.

Saltmarsh Trading runs a market-data portal on an Auto Scaling group named asg-portal. Every weekday at exactly 09:30 the user load jumps from near zero to its daily peak within two minutes as markets open, and it drops sharply at 16:00. A target tracking policy on CPU is in place, but users see slow responses for the first ten minutes after the open because new instances take about eight minutes to launch and warm up.

Which additional action will resolve the slow responses with the LEAST operational overhead?

1. ALower the target tracking policy's CPU target from 60 percent to 20 percent.A lower target keeps more spare capacity all day, increasing cost, and still reacts only after the metric rises at 09:30.
2. BReplace the target tracking policy with a step scaling policy that adds more instances per step.Step scaling is still reactive; larger steps do not remove the eight-minute launch and warm-up delay after the spike begins.
3. CAdd a scheduled scaling action that raises the minimum capacity of asg-portal at 09:15 on weekdays and lowers it at 16:05.Scheduled scaling provisions capacity before a known, recurring event, so warmed instances are serving by the time the 09:30 spike arrives while target tracking still handles intraday variation.
4. DIncrease the instance size so that fewer instances are needed and launch time matters less.Vertical sizing does not change the launch and warm-up time and still leaves the group under-provisioned at the open.