Transient email-verification codes for citizen accounts should expire automatically without a nightly sweeper job. Which DynamoDB feature should the app use?
Select an answer to reveal the explanation.
Short Explanation
Verification codes are milk with an expiration date. Stamp a TTL attribute and let DynamoDB toss the carton—no nightly janitor script required.
Full Explanation
Transient email-verification codes should disappear after their lifetime without a custom sweeper job. DynamoDB Time to Live (TTL) on a Unix-epoch expiration attribute lets the citizen-account service delete expired code items automatically after the code’s validity window, which is the managed pattern for short-lived municipal auth artifacts and reduces leftover secrets in the table.
An EC2 cron that scans and deletes expired codes each night adds operational burden, delayed cleanup between runs, and recurring Scan cost against a growing codes table. Storing codes forever and filtering expired ones only in the UI leaves secrets and clutter in the datastore and risks accepting expired codes if any API path skips the UI check. S3 Object Lock in governance mode applies to S3 object immutability and retention, not to DynamoDB verification-code items.
Exam caveat: TTL deletion is eventually processed by DynamoDB—not guaranteed at the exact epoch second—so treat expiry as “soon after” and still reject codes in application logic when now is past expiresAt. Operational check: write a code item with a near-term TTL attribute, wait past expiration plus typical TTL processing lag, confirm the item is gone from the table, and ensure the verify API rejects the same code even before physical deletion completes.