A DevOps engineer’s script incrementally archives on-premises data older than one month to S3 using PutObject and then deletes the local data. The script currently does not verify the S3 upload succeeded or that the object is intact. The engineer must ensure uploads are verified using MD5 before deleting local data. Which approaches meet this requirement? (Choose two.)

The two correct approaches ensure data integrity during S3 uploads. 1. Include the base64-encoded MD5 checksum in the Content-MD5 request header and verify the PutObject call returned no error. When you include the Content-MD5 header with a base64-encoded MD5 checksum of the object data, S3 calculates its own MD5 checksum upon receipt and compares it to the one you provided. If they don't match, S3 returns an error, indicating a data integrity issue. If no error is returned, the upload was successful and the data is intact. 2. After PutObject, compare the returned ETag value with the local MD5 checksum. For objects uploaded using a single PUT operation, S3's ETag is an MD5 hash of the object data. After a successful PutObject call, you can retrieve the ETag from the response and compare it to the MD5 checksum calculated locally before the upload. A match confirms data integrity. Incorrect options: Checking VersionId after PutObject only confirms a new version was created but doesn't verify data integrity. Adding the checksum to object tagging or metadata doesn't trigger S3's internal integrity checks during the upload process; it's merely storing information. You'd still need a separate step to verify it, which isn't as robust as S3's built-in Content-MD5 check or ETag comparison.