A financial services firm needs to verify, beyond doubt, that a large file was not corrupted during transmission to S3, using a cryptographic-strength check rather than relying only on the object's ETag. Which S3 capability lets the client supply or request a checksum such as SHA-256 that S3 calculates and validates server-side against the uploaded data before storing the object?
- S3 Object Lock, which cryptographically signs every object on upload
- S3 additional checksums, which support algorithms including SHA-256, SHA-1, CRC32, CRC32C, and the default CRC-64/NVME
- S3 Storage Class Analysis, which reports on data corruption trends over time
- The object's ETag, which is always a SHA-256 hash of the object's contents
Why B? And why not the others?
Correct answer: B. S3 additional checksums, which support algorithms including SHA-256, SHA-1, CRC32, CRC32C, and the default CRC-64/NVME
Amazon S3 supports specifying an additional checksum algorithm when uploading, copying, or managing an object, choosing among CRC-64/NVME (the default used automatically when no algorithm is specified and clients don't supply their own value), CRC-32, CRC-32C, SHA-1, and SHA-256. When a checksum is supplied or requested, S3 independently calculates its own checksum of the received data server-side and validates it against the provided value before storing the object, giving the strong, verifiable integrity guarantee the firm needs, including cryptographic-strength options like SHA-256. Object Lock has nothing to do with data integrity checking; it only controls whether an object version can be deleted or overwritten during a retention period, and it does not sign or checksum object contents at all. Storage Class Analysis only observes access frequency patterns over time to recommend transitioning data to a cheaper storage class; it has no data-integrity or corruption-detection function whatsoever. The claim that the ETag is always a SHA-256 hash is incorrect: for a simple (non-multipart) upload without additional checksums, the ETag is typically the MD5 hash of the object, and for a multipart upload the ETag becomes a hash of the concatenated part hashes rather than a hash of the object's contents at all, so it cannot be relied upon as a straightforward, algorithm-guaranteed integrity check the way an explicitly requested checksum can.
Source: AWS S3 documentation: Checking object integrity in Amazon S3 — supported checksum algorithms (CRC-64/NVME default, CRC-32, CRC-32C, SHA-1, SHA-256) and server-side validation