Granting a VM scoped storage access without static keys
workload identity over static secrets.
attach a least-privilege role or managed identity to the VM so it gets auto-rotating temporary credentials scoped to the bucket.
storing access keys in config or environment variables.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
What is the key security benefit of attaching a role to a VM instead of placing access keys on it?
- a.It grants the VM unrestricted access so policies are unnecessary
- b.The VM receives short-lived, auto-rotating credentials with no stored secretCorrect
- c.It makes the storage bucket publicly readable for convenience
- d.It permanently caches one static credential that never needs rotation
Why? this is the answer
An attached role delivers temporary, auto-rotating credentials via the metadata service, so no long-lived secret exists to leak. The other options either remove access control or reintroduce the static-key risk.
Just read this? Test yourself on what you have been reading.
Read the original → docs.aws.amazon.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles