A municipal foghorn museum catalog stores each artifact as a Cosmos DB for NoSQL item. A curator retires one artifact and the app must remove only that document. Which SDK action should the developer call?
Select an answer to reveal the explanation.
Short Explanation
One retired artifact is one folder pull, not demolishing the museum wing. Point the Cosmos SDK delete at that item’s id plus partition key. Leave the container and account standing.
Full Explanation
When a municipal foghorn museum curator retires one artifact stored as a Cosmos DB for NoSQL item, the correct action is an SDK DeleteItem (or equivalent) that targets that document’s id together with its partition key. Item-level delete removes only the retired artifact while leaving every other catalog document, the container, and the account intact. Partition key plus id is the addressing pair Cosmos requires for point operations, so both values must be known to the worker that performs the retirement.
Deleting the entire Cosmos container that holds the catalog destroys every artifact document and the container’s throughput configuration—far beyond retiring a single piece. Dropping the database account and recreating it empty is a disaster-recovery style reset, not a curator workflow, and it wipes databases, keys, and networking settings. Replacing the account consistency level with Strong does not delete anything; consistency only governs how reads observe committed writes, and Strong does not expire or remove items.
Exam caveat: TTL can expire items asynchronously after a property is set, which is a supporting pattern for automatic cleanup, but an immediate curator action is still an explicit item delete rather than waiting on TTL alone.
Operational check: log the id and partition key used for DeleteItem, assert a NotFound on a subsequent ReadItem for that pair, and confirm sibling items in the same container still read successfully so the retirement did not escalate into a broader purge.