The object store is enabled on a Data Domain for the archive team, and the team's lead asks how readiness will be proven before anyone commits production data. What is the correct bring-up test?
Select an answer to reveal the explanation.
Short Explanation
The archive team shouldn't have to take 'enabled' on faith. Have them put a test object in with the keys and bucket you issued for production, then pull it back out. When a client can write and read on day one with its own credentials, readiness stops being a claim and becomes a demo.
Full Explanation
S3-style access stands on a stack of independently configurable pieces: the object service enabled, a bucket bound to a storage resource, users or access keys issued with permission on that bucket, and the endpoint serving over the right protocol. A put and a get performed with the production access keys against the production bucket touch every layer at once - authentication proves the keys, bucket access proves the authorization, and payload survival proves the data path - and the archive team can rerun the same round trip themselves, which converts the result into their evidence too. The service-enabled view is one layer of the stack: an enabled service with unissued keys or an unbound bucket still rejects every client. A bucket listing proves namespace existence but skips both authentication and writing - the two failure areas that actually generate post-go-live tickets. Outbound network tests from the appliance point the wrong direction: object clients connect inbound to the endpoint, and even perfect reachability would say nothing about whether the issued credentials are accepted. Exam caveat: test against the exact endpoint the application will use, TLS included - a round trip that passes over an insecure or different endpoint encodes a finding for the security review. Operational check: the archive team performs its own put and get with matching checksums, and the exchange is logged on the acceptance sheet.