Fixing Stale EC2 Pricing Files with Mountpoint for Amazon S3

SAP-C02 By islever Editorial Last updated

Design a solution to meet performance objectives. Determine a cost optimization strategy to meet solution goals and objectives.

Short answer

C Mount the pricing bucket with Mountpoint for Amazon S3 so the Linux EC2 instances read the current pricing file directly from S3 instead of a launch-time copy.

Question

An entertainment company hosts a ticketing service on a fleet of Linux Amazon EC2 instances that are in an Auto Scaling group. The ticketing service uses a pricing file. The pricing file is stored in an Amazon S3 bucket that has S3 Standard storage. A central pricing solution that is hosted by a third party updates the pricing file.
The pricing file is updated every 1-15 minutes and has several thousand line items. The pricing file is downloaded to each EC2 instance when the instance launches.
The EC2 instances occasionally use outdated pricing information that can result in incorrect charges for customers.
Which solution will resolve this problem MOST cost-effectively?
  1. Create an AWS Lambda function to update an Amazon DynamoDB table with new prices each time the pricing file is updated. Update the ticketing service to use DynramoDB to look up pricing
  2. Create an AWS Lambda function to update an Amazon Elastic File System (Amazon EFS) file share with the pricing file each time the file is updated. Update the ticketing service to use Amazon EFS to access the pricing file.
  3. Load Mountpoint for Amazon S3 onto the AMI of the EC2 instances. Configure Mountpoint for Amazon S3 to mount the S3 bucket that contains the pricing file. Update the ticketing service to point to the mount point and path to access the $3 object, Correct Answer
  4. Create an Amazon Elastic Block Store (Amazon EBS) volume. Use EBS Multi-Attach to attach the volume to every EC2 instance. When a new EC2 instance launches, configure the new instance to update the pricing file on the EBS volume. Update the ticketing service to point to the new local source.

Key Takeaways

The trap is treating this as a storage-consistency question; the real issue is the download-once-at-launch pattern, and the winning option is the one that removes the local copy with the least added cost and code change.

This SAP-C02 scenario tests how to stop Auto Scaling EC2 instances from serving a launch-time snapshot of a frequently updated pricing file. Mountpoint for Amazon S3 (option C) is the most cost-effective fix, because every read reflects the current S3 object without extra infrastructure.

Common mistake: Option A (Lambda to DynamoDB) is the most tempting wrong answer: DynamoDB fits per-item price lookups, but it forces the ticketing service to abandon its flat-file consumption model, adds Lambda and DynamoDB read/write billing on every 1–15 minute refresh, and introduces its own propagation delay.

Expert Analysis

The Real Defect

The failure is not an S3 consistency problem — S3 has offered strong read-after-write consistency for all operations since December 2020. The defect is in the application pattern: each EC2 instance snapshots the pricing file once at launch and never refreshes it, so any instance that has been running for 15+ minutes serves stale prices. Any correct fix must remove that "download once, use forever" behavior.

Why Option A Is the Attractive Trap

Option A looks like the textbook SAP-C02 answer: a Lambda function reacts to the third-party upload and pushes prices into DynamoDB, and the service reads lookups from a fast key-value store. It does eliminate staleness, and DynamoDB genuinely suits item-level price lookups. But it fails on two counts. First, the ticketing service currently consumes a flat file with several thousand line items; option A forces a rewrite of the service into per-item query logic, a modeling and code change well beyond a configuration fix. Second, "most cost-effectively" is violated: you now pay for Lambda invocations, DynamoDB write capacity on every 1–15 minute refresh, and read capacity on every lookup, plus ongoing table storage. The added moving parts also introduce a propagation window between the S3 upload and the DynamoDB update.

Why Option C Wins

Option C is correct. Mountpoint for Amazon S3 is an open-source FUSE client supported on Linux — which the question explicitly states the instances run — that exposes the S3 bucket as a file path. Because Mountpoint reads the object from S3 on demand, every read reflects the current object version; there is no cached copy to go stale and no launch-time snapshot. The change is minimal: repoint the service at the mount path instead of the local file. Cost stays minimal too — no new compute, no intermediate storage tier, no replication of the pricing data, and you pay only for the S3 GET requests and Standard storage you already have. Option B adds a Lambda-triggered copy into EFS (extra storage billing plus eventual staleness of its own), and Option D fails outright: EBS Multi-Attach is an iSCSI-based shared block volume for clustered applications, it does not refresh data on already-running instances, and each new instance must re-upload the file.

Official Reference

https://docs.aws.amazon.com/AmazonS3/latest/userguide/mountpoint.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

When a question says data is downloaded once at launch and "occasionally outdated," immediately identify the caching/snapshot pattern as the fault, not the storage service itself — read-after-write consistency in S3, DynamoDB, and EFS is no longer the differentiator. Then filter options by the least-invasive change: prefer the one that keeps the existing file-consumption model and adds no new compute or replicated storage tier, since "most cost-effectively" questions reward the minimal-footprint design. Always check the stated operating system before selecting a FUSE-based answer such as Mountpoint for Amazon S3.

Frequently Asked Questions

Doesn't Amazon S3 already guarantee strong consistency, so why is the pricing outdated?

S3 itself is strongly consistent; the problem is that each EC2 instance downloads the file once at launch and caches it locally for its entire lifetime. Later S3 updates never reach an already-running instance.

Why not use a Lambda function to copy prices into DynamoDB on each update?

It removes staleness but requires rewriting the ticketing service from flat-file parsing to per-item queries, and adds Lambda, DynamoDB read/write, and storage costs on every 1–15 minute refresh, so it is not the most cost-effective.

Is Mountpoint for Amazon S3 compatible with Linux EC2 instances?

Yes. Mountpoint for Amazon S3 is an open-source FUSE client for Linux, and it supports all S3 storage classes except the Glacier and Intelligent-Tiering archive tiers — S3 Standard works fine here.

More SAP-C02 FAQ →

Discussion 17 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 17

  1. awsaz 👍 9 Answered C
    Mountpoint for Amazon S3: This solution allows the EC2 instances to directly access the S3 bucket as if it were a local file system. This ensures that the instances always access the latest version of the pricing file without having to download it each time. Cost-Effective: This approach avoids the need to constantly download and store the file on each instance, which can save on both S3 GET requests and local storage costs. Simplicity: By mounting the S3 bucket, you ensure that all instances are using the most current file without additional logic or processes to manage file updates.
  2. mifune 👍 7 Answered A
    DynamoDB in this scenario looks cheaper than EFS. Answer A
  3. DS2023 👍 4 Answered A
    Option A is the correct answer.
  4. liuliangzhou 👍 3 Answered A
    A. DynamoDB provides fast data access and query capabilities, suitable for frequently read but infrequently updated data. B. EFS may not be suitable for frequent small file updates, and its cost may be higher than using DynamoDB. C. This solution can directly read pricing files from S3, but it does not solve the problem of outdated pricing data being used by old instances even after the pricing files are updated. D. EBS is not good at Multi Attach to multiple EC2 instances, and it can increase complexity and cost.
  5. nimbus_00 👍 3 Answered C
    "Mountpoint for Amazon S3 is available only for Linux operating systems. You can use Mountpoint to access S3 objects in all storage classes except S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive, S3 Intelligent-Tiering Archive Access Tier, and S3 Intelligent-Tiering Deep Archive Access Tier." https://docs.aws.amazon.com/AmazonS3/latest/userguide/mountpoint.html
Show 12 more comments
  1. 0b43291 👍 2 Answered C
    By leveraging the strong consistency guarantees, cost-effectiveness, and simplicity of Mountpoint for Amazon S3, Option C provides the most appropriate and cost-effective solution for ensuring the EC2 instances in the Auto Scaling group always have access to the latest pricing information, resolving the outdated pricing data problem. The other options have drawbacks or are less cost-effective: Option A: Using DynamoDB may not be cost-effective for storing and accessing a large, frequently updated pricing file with several thousand line items. Option B: While Amazon EFS is viable, it introduces additional infrastructure and potential costs compared to directly accessing the pricing file from the S3 bucket using Mountpoint for Amazon S3. Option D: Using an Amazon EBS volume with Multi-Attach would require updating the pricing file on the volume whenever a new instance launches, which is less efficient and more prone to errors than directly accessing the file from the S3 bucket.
  2. JoeTromundo 👍 2 Answered C
    Mountpoint for Amazon S3 allows EC2 instances to treat an S3 bucket like a file system. This solution ensures that the EC2 instances always have access to the latest version of the pricing file, as the file is directly accessed from S3. You avoid downloading the file every time and reduce the risk of using outdated pricing data. S3 Consistency: Amazon S3 provides strong read-after-write consistency, so any update to the pricing file in S3 will be immediately visible to all EC2 instances accessing the file via the mount point. Cost Efficiency: By using Mountpoint for Amazon S3, you leverage S3's cost-effective storage and avoid additional infrastructure like DynamoDB or Elastic File System (EFS). This solution does not require copying data to another storage system, minimizing overhead.
  3. eesa 👍 2 Answered C
    Option C (Mountpoint for S3) (best solution): Mountpoint for Amazon S3 allows the EC2 instances to directly access the latest version of the pricing file stored in S3 without repeatedly downloading it. Each EC2 instance will always read the most up-to-date file directly from S3, eliminating the risk of outdated information. This solution is cost-effective as it involves minimal overhead, does not incur unnecessary data transfer or operational complexity, and requires minimal application modification.
  4. aka1177 👍 2 Answered A
    Only A; S3 service is not a file share system by design. In reality it wont work as good as other solutions. You all were misled.
  5. wbedair 👍 2 Answered C
    the question is asking about cost effectiveness so why choose A to add additional service like Dynamodb . I will go for option C
  6. mns0173 👍 2
    There is no need to move away from S3
  7. chris_spencer 👍 1
    none of them makes sense... if an S3 object is uploaded it is strongly consist since end 2020, eventual consistency is a matter of the past. So it doesn't matter if the lambda function get the trigger after upload and transfer the information to dynamodb (A) or EFS(b), or the ec2 instance get the object via blocklevel file access (C) or EBS (D). The consistency is being provided by the source system which is S3, so nothing helps here. From the cost perspective is C the cheapest
  8. alexbraila 👍 1
    The way I understand it, the question is not about S3 consistency. The problem is that an EC2 instance downloads the file from S3 upon launch and never updates it during its lifetime. Hence A, B and C would all solve this problem (but not D, as the file in EBS would only be updated when a new instance is launched), but the most cost-effective is C
  9. Danm86 👍 1
    Option C is most cost effective, but the question has ambiguity where it tells customer could be wrongly charged, more details should be provided on the same to understand if wrong charging is critical or not. If wrong charging is critical and needs low latency and more reliability on the queried data then its option A
  10. alexbraila 👍 1
    I would argue that option C does solve the problem of outdated pricing data. If the ticketing service looks up the price in the local file upon every request and since the local file links to the up to date file in S3, it looks right to me
  11. Aws00 👍 1
    https://aws.amazon.com/tw/blogs/storage/the-inside-story-on-mountpoint-for-amazon-s3-a-high-performance-open-source-file-client/#:~:text=UPDATE%20(8%2F9%2F2023)%3A%20Mountpoint%20for%20Amazon,S3%20is%20now%20generally%20available.
  12. pk0619 👍 1 Answered C
    most cost effective

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Modernize centralized firewall appliances with a Gateway Load Balancer and Auto Scaling

S-grade

Use Lambda over a CloudWatch Logs stream to count unique users per client

S-grade

Serve global game assets with Route 53 latency records and health checks

S-grade

Reach a cross-account S3 data lake through a gateway endpoint and an access point bucket policy

S-grade

Practice All SAP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full SAP-C02 Practice Test →

← Back to SAP-C02 Study Guide