A company has an encrypted Amazon S3 bucket. An Application Developer has an IAM policy that allows access to the S3 bucket, but the Application Developer is unable to access objects within the bucket. What is a possible cause of the issue?
A.
The S3 ACL for the S3 bucket fails to explicitly grant access to the Application Developer
B.
The AWS KMS key for the S3 bucket fails to list the Application Developer as an administrator
C.
The S3 bucket policy fails to explicitly grant access to the Application Developer
D.
The S3 bucket policy explicitly denies access to the Application Developer
D is what i thought if the IAM is allowing the users the buckets policy is not needed but if the bucket policy is denying access no matter if the IAM user policy grants it
D. The S3 bucket policy explicitly denies access to the Application Developer.
If the S3 bucket policy explicitly denies access to the Application Developer, this would certainly cause the issue. S3 bucket policies can include "Deny" statements that override "Allow" statements in IAM policies.
The most likely cause of the issue is option D. The S3 bucket policy explicitly denying access to the Application Developer would result in the behavior described. You should check the S3 bucket policy to ensure that it does not contain any explicit "Deny" statements for the Application Developer.
Option "D" says explicitly denies which means, the particular user has to be denied. But that is not the case here. So, option "C" is the right answer because due to other reasons (like not granted) he might have got blocked
I'd go with D. If the IAM policy has an allow, only an *explicit* deny would stop the user from accessing the bucket.
Yes, it could be a problem with the key, but "list the application developer as an administrator" isn't required to use the key itself.
To explain, when you use server-side encryption with AWS Key Management Service (SSE-KMS) for an S3 bucket, not only does the IAM policy need to allow access to the S3 bucket, but the key policy for the KMS key used for encryption also needs to allow the necessary permissions.
In other words, if the Application Developer doesn't have the necessary permissions in the KMS key policy to use the key (like kms:Decrypt for reading objects, for example), they would be unable to access the objects in the bucket, even if their IAM policy allows S3 bucket access.
Of course, without more specific details, this is just one possible cause. There could be other potential issues too (like explicit deny statements, lack of necessary S3 permissions in the IAM policy, etc.), but based on the information in the question, Option B seems the most likely.
The IAM role has been configured to allow access to the S3 resource. However the bucket has an explicit deny policy which takes precedence over the allow rule.
Ans is D
Reason: You don't need to explicitly grant permission to user in S3 Policy if he\she has permission in IAM, except when the S3 policy has explicit DENY
It mentions the bucket is encrypted. It could have to do with something with KMS etc too right? Like, maybe the user doesn't have kms:Decrypt permissions? Or am I wrong here
The AWS KMS key for the S3 bucket fails to list the Application Developer as an administrator - because it's nonsense and on the other hand you'll get a different error, not access deny.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
awssecuritynewbie
Highly Voted 3 years, 9 months agojoeboy
Highly Voted 3 years, 9 months agoRaphaello
Most Recent 1 year, 4 months agoRosenYordanov
1 year, 8 months agoSenthil_SPM
1 year, 9 months agoaddy_prepare
1 year, 10 months agoGreen53
2 years agoOCHT
2 years agoITGURU51
2 years, 2 months agoLaziiie
2 years, 7 months agolandsamboni
2 years, 7 months agoAshishFL
2 years, 4 months agosapien45
2 years, 10 months agolotfi50
3 years, 1 month ago1awssec
3 years, 8 months agonhokicuc
3 years, 8 months agovmalj
3 years, 8 months agoskipbaylessfor3
3 years, 8 months agohubekpeter
2 years, 7 months agosanjaym
3 years, 8 months ago