Which solution will meet these requirements?
Create a new customer managed CMK. Add a key rotation schedule to the CMK. Invoke the key rotation schedule every time the security team requests a key change.
Create a new AWS managed CMK. Add a key rotation schedule to the CMK. Invoke the key rotation schedule every time the security team requests a key change.
Create a CMK alias. Create a new customer managed CMK every time the security team requests a key change. Associate the alias with the new CMK.
Create a CMK alias. Create a new AWS managed CMK every time the security team requests a key change. Associate the alias with the new CMK.
Explanations:
Using a customer managed CMK with a key rotation schedule allows automatic rotation, but it does not meet the requirement for the security team to manually change the key whenever needed. Additionally, AWS does not support manual invocation of the key rotation schedule.
An AWS managed CMK cannot be rotated or changed by the user. The key material is managed by AWS, so the security team would not have the ability to change the key at will, thus failing to meet the requirement.
Creating a new customer managed CMK for each key change allows the security team to manually control when to create a new key. Associating the new key with a CMK alias provides a way to refer to the current key without needing to update application configurations. This solution meets all requirements.
Similar to option B, AWS managed CMKs cannot be manually rotated or changed by users. Each new key would need to be a customer managed CMK to allow for manual control over key changes, making this option incorrect.
In my opinion, the answer is:
Create a CMK alias. Create a new customer managed CMK every time the security team requests a key change. Associate the alias with the new CMK.
As I see it, the answer is:
Create a CMK alias. Create a new customer managed CMK every time the security team requests a key change. Associate the alias with the new CMK.