New objects in an S3 evidence bucket should invoke a redaction function automatically. How should that integration be configured?
Select an answer to reveal the explanation.
Short Explanation
When evidence drops in the bucket, the redaction function should get a doorbell ring—not a guard walking the hallway every minute. Wire S3 object-created events to Lambda. Cron re-listing everything, SSH handoffs, and SES email rules are the wrong doorbells.
Full Explanation
New objects in an S3 evidence bucket should invoke a redaction function automatically via an S3 event notification (or equivalent event source) on object creation. PutObject becomes the trigger; Lambda (often behind SQS for backpressure) runs redaction without polling. Chain-of-custody workflows in public safety benefit from immediate, auditable automation when evidence lands, rather than waiting on a human to notice a new key.
A cron that lists the bucket every minute and invokes Lambda for every key ever seen is wasteful, laggy, and easy to get wrong on pagination and deduplication. Requiring officers to SSH to a bastion and manually start redaction after each upload fails automation and does not scale across shifts. Using only SES inbound email rules to detect new evidence objects in S3 misunderstands both products and invents a fragile side channel.
Exam caveat: configure prefix and suffix filters so only evidence paths trigger redaction. Ensure the Lambda resource-based policy allows the S3 service principal to invoke. Consider SQS between S3 and Lambda for smoother retries. Never overwrite original evidence without a controlled retention design.
Operational check: enable ObjectCreated notifications for the evidence prefix; confirm a test upload invokes redaction; verify permissions; alarm on failures; and ensure redacted outputs land in a separate controlled prefix or bucket with tighter public access blocks.