When a resident uploads a new 311 case attachment to object storage, the city wants an automated virus-scan and metadata tag without a standing poller. Which approach fits?
Select an answer to reveal the explanation.
Short Explanation
You can think of an object-created trigger as a doorbell: the upload arrives, and the function or queue consumer wakes up without a standing poller. Monthly manual downloads are too slow for timely scanning and tagging, while disabling uploads avoids the work by giving up the needed 311 attachments.
Full Explanation
When a resident uploads a 311 case attachment to object storage, an event-driven function or queue consumer triggered on object creation fits the need for virus scanning and metadata tagging without a standing poller. Object stores commonly emit create events to queues, bus topics, or functions-as-a-service; consumers can scan and tag each upload asynchronously. This scales with upload bursts and avoids the waste and lag of continually listing buckets for new objects. A technician manually downloading every upload at month’s end fails on latency, scale, and reliability: malware and missing tags could persist for weeks, and people are not event processors. Disabling uploads avoids automation only by removing residents’ ability to attach evidence to 311 cases, so it fails the business need. A nightly bucket sweep still delays work until the scheduled run and requires discovering objects after arrival, rather than triggering work for each new object. Exam caveat: event-driven processing does not rule out occasional reconciliation jobs for missed events; the primary pattern here is trigger-on-create, not polling or manual review. Practical check: upload a test attachment, confirm an event reaches the consumer and produces a scan result and tags, then use a safe test sample in a non-production bucket to verify quarantine behavior. Ensure the function has least-privilege access to read objects and write results or tags.