Exam AWS Certified Security - Specialty topic 1 question 185 discussion

I think it is B for these reasons: 1. Both the bucket and user are in the same account. It says in the question that the Security Engineer's account is defined in the centralized account. The bucket policy is also in the centralized account. So we are not assuming any roles that would apply to the answer. 2. You have to look at all applicable policies and evaluate together. We start with an explicit deny. Then we look at IAM, there is an explicit allow for the Security Engineer for s3:Get and s3:List. Then we look at bucket policy. There's no explicit deny's there and we still have the explicit allow being applied. Finally, we look at bucket ACL. Since it isn't presented in the question, we can only assume that there is an ACL that explicitly denies any principal's other than the ones listed in the ACL.

Object ACL. (s3:x-amz-acl | s3:x-amz-grant-read | s3:x-amz-grant-full-control)

Best practice is to set bucket policy to control cross-account access to S3 bucket. A is the correct answer.

A - "It's also a best practice to use IAM policies and bucket policies (instead of ACLs) to manage cross-account access to buckets and objects." As well as it said that ACL is used for specific cases https://repost.aws/knowledge-center/cross-account-access-s3

Looks to me like A is the answer. When applying both IAM and S3 bucket policies, the resultant policy will be the intersection of both. The IAM policy grants the engineer get access, but the bucket policy's default deny policy doesn't grant access to anyone. Only the "logcopier" role and the IAM user that created the bucket can access the bucket. https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/ S3 bucket policies (as the name would imply) only control access to S3 resources, whereas IAM policies can specify nearly any AWS action. One of the neat things about AWS is that you can actually apply both IAM policies and S3 bucket policies simultaneously, with the ultimate authorization being the least-privilege union of all the permissions (more on this in the section below titled “How does authorization work with multiple access control mechanisms?”).

Another useful material for demystification. https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-auth-workflow-object-operation.html

Why can't I access an object that was uploaded to my Amazon S3 bucket by another AWS account? For existing Amazon S3 buckets with the default object ownership settings, the object owner is the AWS account which uploaded the object to the bucket. For these existing buckets, an object owner had to explicitly grant permissions to an object (by attaching an access control list). https://aws.amazon.com/premiumsupport/knowledge-center/s3-bucket-owner-access/ With S3 Object Ownership, bucket owners can now manage the ownership of any objects uploaded to their buckets. By default, all newly created S3 buckets have the bucket owner enforced setting enabled.

Answer = A / Multi-account requires both IAM and bucket policy permissions

It is B.

I think it's A

I think A To allow cross-account access, you attach a resource-based policy to the resource that you want to share. You must also attach an identity-based policy to the identity that acts the principal in the request. The resource-based policy in the trusting account must specify the principal of the trusted account that will have access to the resource. You can specify the entire account or its IAM users, federated users, IAM roles, or assumed-role sessions.

I think its B A: no need to explicit allow IAM user. Either IAM policy or bucket policy allows the principal is enough. In this case, there is no explicit deny B: you can deny bucket owner account to access bucket/object via ACLs C: S3:Get* and S3:List* are allowed already in IAM policy D: User just need to read.

Cant be B, as the user and bucket are in the same centralised account "Use ACLs to control which principals in other accounts can access the resource to which the ACL is attached. ACLs are similar to resource-based policies, although they are the only policy type that does not use the JSON policy document structure. ACLs are cross-account permissions policies that grant permissions to the specified principal. ACLs cannot grant permissions to entities within the same account." https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html

My view is B. https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/ "Whenever an AWS principal issues a request to S3, the authorization decision depends on the union of all the IAM policies, S3 bucket policies, and S3 ACLs that apply." A- S3 bucket does not need to explicitly allow. There is no explicit deny either. C- S3:Get* and S3:List* are allowed. D- The required access by security engineer is read, so S3:Put* are irrelevant. Also, the level of the Resource given should be acceptable.

A for sure. Security Engineer has read permission by IAM policy but bucket policy not allowing Engineer to get objects from bucket.

yeah, B For the people that think it's a, it's not. the IAM policy allows to get object, but not PUT bucket policy allows put from some roles. there's no deny anywhere, both policies even evaluated together do not deny the engineer to read.

yeah, B For the people that think it's a, it's not. the IAM policy allows to get object, but not but bucket policy allows put from some roles. there's no deny anywhere, both policies even evaluated together do not deny the engineer.