Exam AWS DevOps Engineer Professional topic 1 question 38 discussion

D is my choose https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html

i will go with D. C is not correct, if you have deny *, allow AuthenticatedUsers still doesn't allow the access. authenticated-read vs public-read, one is for Owner gets FULL_CONTROL. The AuthenticatedUsers group gets READ access., the other one is Owner gets FULL_CONTROL. The AllUsers group (see Who Is a Grantee?) gets READ access.

D - When setting the flag authenticated-read in the command line, the owner gets FULL_CONTROL. The AuthenticatedUsers group (Anyone with an AWS account) gets READ access. Reference: https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html

I think it's D, If you don't specify any acl command then acl is not enabled for the bucket which means that the objects accesses are defined only by the bucket policy.

Of course, B and C are excluded. C is self-contradicted, B is not completed. D looks like the best, because AWS suggested to stop using ACL on S3 buckets. However, if we only remove the "acl authenticated-read", but not use bucket's ownership to change the default behaviour that uploader of the objects has access, the bucket's owner will not have access to the object and set up policies to the objects.

D looks consistent.

Correct answer is D. Best practice is to limit the use of ACL and grant access using bucket policy. So in this case it's about allowing access to the bucket to specific AWS accounts and not to every authenticated user or all AWS accounts which are options A and B. I am not sure how Option C would work. It's talking about denying access to the principal. But I am not sure how access can be provided to the account but not to the Role or user in that account.

D is my choice. AWS does not recommend the usage of ACL's. Below is the explanation from https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html A majority of modern use cases in Amazon S3 no longer require the use of ACLs, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually. With Object Ownership, you can disable ACLs and rely on policies for access control. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies. For more information, see Controlling ownership of objects and disabling ACLs for your bucket.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html

I choose D

D is my choose https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html

I choose D

Correct Answer: D You can define bucket policy using NotPrincipal to grant permission to specified accounts or users while it explicitly denies access from other users. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notprincipal.ht ml

C is my choose https://aws.amazon.com/blogs/security/how-to-restrict-amazon-s3-bucket-access-to-a-specific-iam-role/

I think the answer is A. https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html When running s3 sync in the post_build section, granting public-read makes it available for download to anyone who knows the URL.

I go with A. Most restrictive access. public_read definition: Owner gets FULL_CONTROL. The AllUsers group (see Who Is a Grantee?) gets READ access. https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html#canned-acl A grantee can be an AWS account or one of the predefined Amazon S3 groups. You grant permission to an AWS account using the email address or the canonical user ID. https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html#specifying-grantee

Answer is C