Granting a VM scoped storage access without static keys

WHAT THIS TESTS The interviewer wants to confirm you reach for workload identity and least privilege instead of static keys, and that you understand how instances obtain temporary credentials.

A GOOD ANSWER COVERS The secure pattern is to give the VM an identity rather than a secret. On AWS you create an IAM role with a policy granting only the needed actions, such as read or write, on only the specific bucket and prefix, then attach it to the instance through an instance profile. The application running on the VM transparently retrieves temporary, automatically rotating credentials from the instance metadata service, so nothing long-lived is ever written to disk, config, or environment variables. Azure offers the same idea through a managed identity, and Google Cloud through an attached service account. Scope the policy to least privilege: name the exact bucket, restrict actions, and optionally add conditions. Because the credentials come from the security token service, they expire and rotate on their own, so a compromised instance leaks only short-lived, narrowly scoped access. If access must be time-bounded beyond that, you can also issue a pre-signed URL for a single object with an expiry, but for ongoing workload access the attached role is the right tool.

COMMON WRONG ANSWERS Creating an IAM user and copying its access keys onto the instance, the exact long-lived-credential pattern to avoid. Granting broad storage-wide permissions instead of scoping to one bucket. Hardcoding keys in environment variables or a config file.

LIKELY FOLLOW-UPS How does the instance metadata service deliver credentials? How do you restrict a policy to one bucket and prefix? When is a pre-signed URL the better fit?

ONE CONCRETE EXAMPLE A role allowing only s3:GetObject on arn for reports-bucket is attached to the VM. The app reads rotating temporary credentials from metadata and can read that one bucket and nothing else, with no key ever stored on the host.