SOA-C02 Reliability and Business Continuity Practice Question
A company runs a file-sharing application on AWS. Users upload files to an S3 bucket, which triggers a Lambda function to process the files and store metadata in a DynamoDB table. Recently, users have reported that some uploaded files are never processed. The SysOps Administrator checks the CloudWatch logs and finds no errors from the Lambda function. The S3 bucket is configured to send events to the Lambda function. The DynamoDB table has sufficient write capacity. The administrator suspects that the event notifications are being lost. Which action should the SysOps Administrator take to ensure that every file upload triggers a Lambda function and that the function processes the file successfully?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure an SQS queue as the event destination for the S3 bucket, and have the Lambda function process messages from the queue.
Using an SQS queue as the event destination for S3 bucket events provides a durable, reliable mechanism to capture every event. S3 sends event notifications to the SQS queue, and if the Lambda function fails or is throttled, the message remains in the queue for later processing. This decouples the event source from the function and ensures no events are lost. Option B is incorrect because DynamoDB Streams capture changes to DynamoDB items, not S3 events. Option C is wrong because increasing reserved concurrency only helps with Lambda scaling but does not address potential event loss due to failures or delivery issues. Option D is wrong because DynamoDB write capacity is already sufficient; the issue is with S3 event delivery, not database writes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Configure an SQS queue as the event destination for the S3 bucket, and have the Lambda function process messages from the queue.
Why this is correct
S3 event notifications can be delivered to SQS, providing a durable buffer. Lambda polls the queue, so messages are not lost if the function is throttled or busy. SQS retains messages until processed, and Lambda event source mapping handles retries and batching. This decouples the upload rate from Lambda's invocation capacity.
- ✗
Use DynamoDB Streams to capture file metadata changes instead of Lambda invocation.
Why it's wrong here
DynamoDB Streams are specifically for tracking changes to items in a DynamoDB table; they cannot receive S3 bucket event notifications. Since the object uploads are happening in S3, DynamoDB Streams would not capture those events at all. The architecture already uses Lambda to write metadata to DynamoDB; replacing the Lambda trigger with DynamoDB Streams would only help if you need to react to changes in that table, not S3 uploads.
- ✗
Increase the Lambda function's reserved concurrency to handle more invocations.
Why it's wrong here
Reserved concurrency caps simultaneous Lambda invocations; it neither recovers lost S3 event notifications nor guarantees delivery. Configuring an S3 event notification destination with a dead-letter queue, or using EventBridge, addresses dropped events. Concurrency is tempting because throttling causes missed invocations, and raising it would be right for genuine throughput limits.
- ✗
Increase the write capacity of the DynamoDB table to avoid throttling.
Why it's wrong here
The issue is that S3 is failing to deliver events to Lambda, not that DynamoDB is throttling writes. Increasing write capacity on the table would only address problems during the Lambda function's write operation, which occurs after the event is successfully received. Since the file metadata is never written because the Lambda function is never triggered, the capacity of DynamoDB is irrelevant. This option treats a symptom of a downstream write, not the root cause at the event notification layer.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
Courseiva writes every SOA-C02 question from scratch — 1,169 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.