Exam AWS Certified Security - Specialty topic 1 question 124 discussion

A. It's usually a grant when a grant is an option in the tests.

A, AWS KMS supports two resource-based access control mechanisms: key policies and grants. With grants you can programmatically delegate the use of KMS customer master keys (CMKs) to other AWS principals. IAM Policies are optional - Requires additional steps.

A . Don't know why it says grant in the option just choose it

1. It was not mentioned how the vendor accounts access the data in S3 bucket. Manually or programmatically. Only mentioned "principals". 2. KMS key grants dynamically generate GRANT TOKEN that is required for granted actions for the time of grant validity. Once the grant is retired, the associated token is gone. This is why point (1) is important. How to communicate the token to vendor account and how is going to be used? 3. Using the word "programmatically" suits issuing grants more than updating key policy. Misleading. 4. Both A & C are correct each in its own context. Programmatic access from vendor account won't work well with GRANT TOKENS, cause each time "PROGRAMMATICALLY CREATE A GRANT" means vendor needs to update their programmatic access with the new GRANT TOKEN. Even manually, will depend on communicating the token. 5. For all above, setting a key policy to permit "principals" from vendor accounts is the best answer (NO GRANT TOKENS). Answer is C

Everyone says the answer is A but based on my understand and research, the answer should be more like C. https://repost.aws/knowledge-center/cross-account-access-denied-error-s3

Ans A: Grants are advanced mechanisms for specifying permissions that you or an Amazon service integrated with Amazon KMS can use to specify how and when a KMS key can be used. Grants are attached to a KMS key, and each grant contains the principal who receives permission to use the KMS key and a list of operations that are allowed. url: https://www.bing.com/ck/a?!&&p=d91421aa69e1d254JmltdHM9MTY5NTYwMDAwMCZpZ3VpZD0yMTEzZmNjNy0zOTNkLTYyYmQtMTJhNC1lZWQxMzhkZDYzM2QmaW5zaWQ9NTUxMg&ptn=3&hsh=3&fclid=2113fcc7-393d-62bd-12a4-eed138dd633d&psq=what+is+kms+key+grant&u=a1aHR0cHM6Ly9kb2NzLmFtYXpvbmF3cy5jbi9lbl91cy9rbXMvbGF0ZXN0L2RldmVsb3Blcmd1aWRlL2RldGVybWluaW5nLWFjY2Vzcy1ncmFudHMuaHRtbCM6fjp0ZXh0PUdyYW50cyUyMGFyZSUyMGFkdmFuY2VkJTIwbWVjaGFuaXNtcyUyMGZvciUyMHNwZWNpZnlpbmclMjBwZXJtaXNzaW9ucyUyMHRoYXQsYW5kJTIwYSUyMGxpc3QlMjBvZiUyMG9wZXJhdGlvbnMlMjB0aGF0JTIwYXJlJTIwYWxsb3dlZC4&ntb=1

While using KMS grants is a viable option, it may not be the most efficient way to manage access control for the KMS CMK in the given scenario, as it requires creating and revoking individual grants for each vendor. Updating KMS key policies (Option C) is a more efficient approach, as it allows for easier management of access for multiple vendors, especially when the vendor list changes frequently.

Grants allow programmatic access to keys. There are no roles in IAM Key policies

A as well for me

aws kms create-grant \ --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ --grantee-principal arn:aws:iam::111122223333:user/exampleUser \ --operations Decrypt \ --retiring-principal arn:aws:iam::111122223333:role/adminRole \ --constraints EncryptionContextSubset={Department=IT}

a - grants

A. Grants allow programatic creation and revoking of multiple granted key access'

A for me