Uploaded citizen documents must be virus-scanned asynchronously, with infected files moved to a quarantine bucket without blocking the upload API. Which event-driven design fits?
Select an answer to reveal the explanation.
Short Explanation
S3 rings the doorbell; Lambda answers with a scan and escorts bad files to quarantine—upload stays snappy. Making clerks babysit every PUT or banning uploads entirely isn’t event-driven architecture.
Full Explanation
Uploaded citizen documents should be scanned asynchronously via an Amazon S3 event notification that invokes AWS Lambda: the function scans the new object and moves infected files to a quarantine bucket without blocking the upload API. Citizens get a fast PUT to S3; security processing happens event-driven afterward. That pattern is the standard municipal async malware gate on object uploads.
Requiring clerks to open every upload in a desktop antivirus UI before S3 accepts the PUT fails by concept because it inserts a manual synchronous gate that cannot scale and blocks the upload path. Disabling all object uploads and accepting only faxed PDFs fails as an extreme process retreat, not an event-driven cloud design. Running a continuous full-table scan of DynamoDB every second looking for file bytes that never landed in S3 fails because it polls the wrong data store and invents a busy-loop instead of S3 event triggers.
Exam caveat: Async post-upload processing → S3 event → Lambda (or queue/worker). Manual clerk AV, fax-only policies, and DynamoDB polling are distractors when objects land in S3.
Operational check: Verify S3 notifications target the scanner function, quarantine bucket policies block public access, successful clean objects proceed to downstream workflows, and CloudWatch alarms catch scanner failures. If clerks still manually open every file before acceptance, the async design is not live.