Task 4.3: Optimize applications by using AWS services and features

• AKeep 512 MB, because the function uses only 180 MB of its memory

  Incorrect

  Max Memory Used shows memory is not the limit, but CPU scales with the memory setting, so a CPU-bound function can still get faster with more.

• BMeasure several memory sizes, such as with Lambda Power Tuning, and pick the best

  Correct

  More memory brings an equivalent increase in CPU. Performance testing across memory sizes, which AWS suggests doing with Lambda Power Tuning, finds the setting with the best duration and cost.

• CAdd provisioned concurrency so that each invocation starts on a warm environment

  Incorrect

  Provisioned concurrency cuts initialization latency. It does not add CPU to the work done inside the handler.

• DRaise the function's ephemeral storage in /tmp to 10,240 MB

  Incorrect

  Ephemeral storage is disk space in /tmp. It does not change the CPU available to the function.

For Lambda, memory is the CPU knob; measure several settings instead of guessing, and use Max Memory Used and duration to judge them.

• AAdd a filter policy on the subscription that matches a region message attribute

  Incorrect

  The default filter policy scope is message attributes, and these messages carry none, so the subscription would receive nothing.

• BTurn on raw message delivery for the SQS subscription

  Incorrect

  Raw message delivery strips the SNS metadata from each message. Every message is still delivered to the queue.

• CSet the filter policy scope to MessageBody and match region equal to eu

  Correct

  With the MessageBody scope, SNS compares the filter policy with the message body, so only matching messages reach this subscription.

• DConvert the topic and the queue to FIFO so that messages arrive in order

  Incorrect

  FIFO topics add ordering and deduplication. They do not reduce which messages a subscriber receives.

Subscription filter policies move filtering into SNS; set the scope to MessageBody when the deciding field is in the payload.

• AAdd Accept-Language to an origin request policy for the cache behavior

  Incorrect

  An origin request policy sends the header to the origin without adding it to the cache key, so one cached version per URL is still served to everyone.

• BUse legacy cache settings that forward all headers to the origin

  Incorrect

  With legacy settings that forward all headers, CloudFront does not cache the objects and sends every request to the origin.

• CCreate an invalidation for /* after every deployment of the site

  Incorrect

  An invalidation removes cached files before they expire. The next request in any language would again fill the cache for every viewer.

• DInclude the Accept-Language header in the cache key with a cache policy

  Correct

  Values in the cache key decide which cached object a request matches, so each language gets its own cached copy, and only the one header is added.

Put exactly what changes the response into the cache key (here one header); send other values to the origin with an origin request policy.

• AX-Ray active tracing with OpenTelemetry instrumentation

  Correct

  Active tracing creates trace segments for invocations, and instrumented AWS SDK and HTTP client calls are recorded as spans that X-Ray shows as subsegments with their own timing.

• BCloudWatch Lambda Insights for the function

  Correct

  Lambda Insights collects system-level metrics such as CPU time and memory, plus diagnostic information such as cold starts, for each invocation.

• CAn AWS CloudTrail trail that records the function's invocations

  Incorrect

  CloudTrail records actions as events for auditing and governance. It does not break a request's time into its parts.

• DAmazon Inspector scanning for the function and its layers

  Incorrect

  Inspector assesses functions and layers for security vulnerabilities. It does not measure latency or resource use.

• EAWS Config recording for the function's configuration

  Incorrect

  AWS Config shows how resource configurations change over time. It does not show where request time is spent.

Traces show where time goes across calls; Lambda Insights shows how the function's CPU and memory behave. Together they locate a regression.

• AUse an Express workflow for this high-volume processing

  Correct

  Express workflows are meant for high-volume, event-processing workloads such as IoT data ingestion, with runs of up to five minutes.

• BAdd Wait states between the steps to slow the workflow down

  Incorrect

  Waiting adds time to each run and does not lower the cost of the work.

• CTurn on AWS X-Ray tracing for the state machine

  Incorrect

  Tracing helps analyze runs; it does not change what they cost.

• DSplit the workflow into three Standard workflows, one per step

  Incorrect

  More Standard workflows add state transitions instead of removing them.

Choose Express workflows for short, high-rate event processing and Standard workflows for long-running, exactly-once orchestration.

• AUse transactional reads with TransactGetItems

  Incorrect

  Transactional reads use two read units per 4 KB, more than strongly consistent reads.

• BUse eventually consistent reads by leaving ConsistentRead false

  Correct

  An eventually consistent read of an item up to 4 KB uses half a read unit, half of a strongly consistent read.

• CRead the items with a Scan and a filter instead

  Incorrect

  A Scan reads many more items than needed, which uses more capacity.

• DStore each item twice so that reads can alternate between copies

  Incorrect

  Duplicate items double writes and storage, and each read still costs the same.

When stale-by-a-moment data is acceptable, eventually consistent reads halve read capacity use.

• AS3 Standard with S3 Transfer Acceleration turned on for the bucket

  Incorrect

  Transfer Acceleration speeds up long-distance transfers, not requests from compute in the same Region.

• BS3 Intelligent-Tiering

  Incorrect

  Intelligent-Tiering optimizes storage cost for changing access patterns, not request latency.

• CS3 Express One Zone, in the instances' Availability Zone

  Correct

  S3 Express One Zone delivers consistent single-digit millisecond access and can be co-located with compute in one Availability Zone.

• DS3 Standard-Infrequent Access

  Incorrect

  Standard-IA is for infrequently accessed data and adds retrieval charges for these frequent reads.

For latency-sensitive, frequently accessed data near compute, S3 Express One Zone gives the fastest access, with single-zone resilience.

• AFargate with larger task sizes so that the job finishes sooner

  Incorrect

  Larger tasks cost more per hour and may not reduce the total cost of the job.

• BFargate Spot through a capacity provider for the job's tasks

  Correct

  Fargate Spot runs interruption-tolerant tasks at a discount on spare capacity, with a two-minute warning before interruption.

• CA self-managed EC2 Auto Scaling group for the cluster

  Incorrect

  This means managing EC2 instances, which the team wants to avoid.

• DProvisioned concurrency on a Lambda function that starts the tasks

  Incorrect

  This adds Lambda cost and does not change the price of the Fargate tasks.

Interruption-tolerant container workloads can run on Fargate Spot for lower cost.

• ATurn on stage caching with a longer TTL

  Incorrect

  Caching avoids backend calls but does not make the responses smaller.

• BTurn on payload compression with a minimum compression size

  Correct

  API Gateway can compress response payloads for clients that accept a supported content coding once compression is enabled on the API.

• CSwitch the API to an edge-optimized endpoint served through CloudFront

  Incorrect

  The endpoint type changes routing; it does not compress payloads.

• DRaise the stage's throttling limits

  Incorrect

  Throttling controls request rates, not response size.

Enable compression on REST APIs to shrink large responses for clients that accept it.