A developer proposes encoding the database password into the object key prefix so that ingestion scripts can read it back at runtime without a separate configuration store. How should this be handled?
Select an answer to reveal the explanation.
Short Explanation
Don't encode secrets in object keys. Anyone who can list the bucket sees the key, and it leaks into logs, metrics, and console screenshots. Put credentials in a secrets store and reference them from the pipeline.
Full Explanation
The correct handling is to reject the proposal because object keys are metadata visible to anyone who can list the bucket, and credentials belong in a secrets mechanism. Object keys are identifiers, not protected content. Any principal permitted to list the bucket sees them in full, and they propagate into access logs, monitoring output, and administrative interfaces. Any credential placed in a key is therefore disclosed far more widely than the object it names, and it cannot be rotated without rewriting every affected object. The suggestion to accept the proposal because object keys are encrypted at rest along with object contents is incorrect. Encryption at rest protects object contents on disk. Keys must remain readable for the store to serve requests. The suggestion to accept the proposal if the bucket is private, because listing then requires authentication, is incorrect. Private buckets still have many authenticated readers, including operators, service accounts, and other pipelines, and the credential is exposed to all of them. Restricting the audience is not the same as protecting the secret. The suggestion to reject the proposal only because long keys reduce read performance on large buckets is incorrect. It substitutes a marginal performance argument for a security one, and it would leave the practice acceptable with shorter keys. For the exam, treat any choice that stores credentials in a name, path, or table identifier as wrong on sight.