A county IT team notices a data scientist's IAM role has access to an entire S3 bucket when the role's job only requires reading a single training-data prefix within that bucket. What is the appropriate remediation?
Select an answer to reveal the explanation.
Short Explanation
Handing someone the keys to the whole warehouse when they only need one shelf is asking for trouble eventually. Scoping the policy down to that one prefix, with resource-level conditions, gives them exactly what the job requires and nothing extra. Least privilege isn't a slogan, it's a policy edit.
Full Explanation
Scoping the IAM policy to the specific training-data prefix using resource-level conditions (for example, restricting the resource ARN to that prefix rather than the whole bucket) gives the data scientist exactly the access their job requires and nothing more, which is the least-privilege fix for a permission grant that's wider than necessary. Leaving the bucket-wide access in place on the grounds that future prefixes might need adding trades a present, real overexposure for a hypothetical future convenience — new prefixes can be added to the policy incrementally as they're actually needed. Moving the data to a new account changes where the data lives but doesn't fix the underlying problem: the role's permissions would still need to be scoped correctly in the new location, so the move solves nothing on its own. Adding a second bucket to the same broad grant expands the blast radius further instead of narrowing it, moving in the opposite direction from the goal. Scope caveat: resource-level conditions work well for object-key patterns within a bucket, but confirm the access pattern (for example, listing versus reading) still functions correctly after narrowing, since some operations require different permissions than simple GetObject. Operational check: attempt to access an object outside the intended prefix with the role's credentials and confirm the request is denied.