Exam AWS Certified Machine Learning - Specialty topic 1 question 237 discussion

The goal is to provide secure and efficient access to datasets stored in Amazon S3. Sensitive datasets should be accessible only to the Finance department, while non-sensitive datasets should be accessible to all user groups. S3 bucket policies are the most effective and scalable solution for implementing access control in this scenario.

For the Marketing and Human Resources department user groups, attach an IAM policy that provides access to only the folder that contains the non-sensitive datasets. Finance department user also need access to non-sensitive datasets.

I think attaching the policy is more flexible, in case this pattern needs to be repeated for another s3 bucket?

You cannot identify a user group as a principal in a policy (such as a resource-based policy) because groups relate to permissions, not authentication, and principals are authenticated IAM entities. an Amazon S3 bucket policy cannot have a user group as the principal directly. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html I stand corrected. I retract my previous answer.

D Use a bucket policy. User group cannot be a principal in IAM policy. adding each individual user to the policy is not practical

According to the AWS documentation, you cannot specify an IAM group as a principal in an S3 bucket policy. This is because groups relate to permissions, not authentication, and principals are authenticated IAM entities. You can only specify the following principals in a policy: AWS account and root user IAM user Federated user IAM role . If you want to grant permission to an IAM group, you can add the ARNs of all the IAM users in that group to the S3 bucket policy instead. so it is C to create 2 IAM roles and attach them to different groups you have

https://docs.aws.amazon.com/AmazonS3/latest/userguide/walkthrough1.html it does not show any option to use iam group based s3 bucket policy. (so D cannot be the right answer)

changing to C

Option D suggests creating a single S3 bucket that includes two folders to separate the sensitive datasets from the non-sensitive datasets. This option is helpful because it can simplify the data management and reduce the cost of using multiple S3 buckets. You can use a single S3 bucket to store all your datasets and use folders to organize them by their sensitivity level1. You can also use the Amazon S3 console or the AWS CLI to create and manage your folders2.

First it is more efficient to use one single bucket, S3 has limit of 100 buckets by default, answer C creates two policies while for answer D , it is done with one, and use Deny on the sensitive folder to the two groups not finance, and have an allow to the non sensitive, knowing that deny takes precendence

In S3 bucket Policy you CANNOT specify IAM Group as Principal, but you can specify IAM Users. So it's C.

Option C https://stackoverflow.com/questions/35944349/iam-aws-s3-to-restrict-to-a-specific-sub-folder https://aws.amazon.com/blogs/security/how-to-restrict-amazon-s3-bucket-access-to-a-specific-iam-role/

I will choose C

I will choose C

Both B and D look apparently correct but they are not because in s3 bucket policy , IAM Group cant be the principal. In other words you cant give access to a User group to s3 buckets using s3 bucket policy. It can only be an IAM user or role.https://stackoverflow.com/questions/30667678/s3-bucket-policy-how-to-allow-a-iam-group-from-another-account I would go for C

single bucket looks a better option. Ease of management and still secure

Creating a single S3 bucket that includes two folders to separate the sensitive datasets from the non-sensitive datasets would be the best approach. The policy of the S3 bucket can be set to allow only the Finance department user group to access the folder that contains the sensitive datasets. The folder that contains non-sensitive datasets can be made available to all three department user groups. This approach will ensure that sensitive datasets are only accessible to users who need access to them.