A team migrating from a NAS-based data platform assumes they can keep their existing pattern of appending to files in place and renaming directories to reorganise data. Why does this assumption fail on object storage?

The correct answer is the statement that objects are written whole and there are no real directories, so in-place appends and directory renames are not operations object storage provides. Object storage holds immutable objects addressed by key in a flat namespace. What appears to be a directory is a shared key prefix, so there is nothing to rename, and modifying an object means writing a new one rather than appending to the existing bytes. Migrations that carry POSIX assumptions across find that their reorganisation and append patterns have no equivalent. The claim that object storage supports appends but caps each object at a size too small for table data is incorrect because the obstacle is the write model, not a size limit. Object stores handle very large objects. The claim that renames are supported but are asynchronous, so the data is briefly unavailable, is incorrect because there is no rename operation to be asynchronous. Achieving the effect requires copying to a new key and deleting the old one. The claim that object storage requires all writes to pass through a query engine, which forbids appends, is incorrect because engines are not gatekeepers for storage writes. Clients write objects directly; the constraint comes from the storage model itself. For the exam, connect object storage's immutability and flat namespace to why open table formats are needed above it - the format supplies inserts, updates and deletes that the storage layer does not.