Use a KMS key alias and create a new customer managed key on each change

SCS-C02 By islever Editorial Last updated

Design and implement controls to protect credentials, secrets, and cryptographic key materials.

Short answer

C Create a key alias and a new customer managed key on each change, repointing the alias so apps need no update.

Question

A company is using an AWS Key Management Service (AWS KMS) AWS owned key in its application to encrypt files in an AWS account. The company's security team wants the ability to change to new key material for new files whenever a potential key breach occurs. A security engineer must implement a solution that gives the security team the ability to change the key whenever the team wants to do so. Which solution will meet these requirements?
  1. Create a new customer managed key. Add a key rotation schedule to the key. Invoke the key rotation schedule every time the security team requests a key change.
  2. Create a new AWS managed key. Add a key rotation schedule to the key. Invoke the key rotation schedule every time the security team requests a key change.
  3. Create a key alias. Create a new customer managed key every time the security team requests a key change. Associate the alias with the new key. Correct Answer
  4. Create a key alias. Create a new AWS managed key every time the security team requests a key change. Associate the alias with the new key.

Key Takeaways

A key alias decouples the application reference from the underlying key; swapping the alias to a freshly created CMK changes the material used for new files without touching application configuration. AWS managed keys (B/D) are created/maintained by AWS and you cannot freely create new ones on demand; CMK rotation (A) is scheduled/automatic and not an on-demand breach response. C is the control the customer wants.

With an AWS-owned key the company cannot control key material; to allow on-demand key changes, create a customer managed key (CMK) and reference it through a key alias. On each suspected breach, create a new CMK and repoint the alias to it—applications keep using the alias, so no code change is needed and new files use the new material. AWS managed keys cannot be created on demand by the customer the same way, and alias+CMK gives full lifecycle control.

Common mistake: Choosing A's scheduled key rotation—KMS automatic rotation keeps the same key ID and only rotates backing material on a schedule; it is not an on-demand 'change whenever we want' control. Choosing AWS managed keys (B/D)—the customer cannot create new AWS managed keys at will, defeating the requirement.

Expert Analysis

Why the Answer Is Correct

A customer managed key gives the company full control over key lifecycle, and a key alias lets applications reference a stable name while the underlying key is swapped. On each suspected breach the engineer creates a new CMK and repoints the alias to it, so new files use fresh material with zero application changes—exactly the on-demand capability requested.

Why the Other Options Are Wrong

A relies on KMS automatic rotation, which keeps the same key ID and rotates on a fixed schedule; it is not an on-demand, whenever-you-want change. B and D use AWS managed keys, which AWS creates and maintains—the customer cannot spin up new ones at will. C is the correct customer-controlled pattern.

Community Comment Notes

Community voted C (100). Commenters clarified AWS managed keys are created/maintained by AWS on your behalf, whereas customer managed keys give full lifecycle control, and aliases let you abstract the key reference. C was agreed.

Official Reference

https://docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html

This link opens the official vendor documentation in a new tab.

Community Votes

C
100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 4 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 4

  1. Zek 👍 5
    Agree with option C AWS managed keys are KMS keys in your account that are created, managed, and used on your behalf by an AWS service integrated with AWS KMS https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#rotate-keys-manually Also see; a public discussion thread on this question
  2. navid1365 👍 2 Answered C
    C is correct: According to AWS documentation: Customer managed keys provide full control over the lifecycle, including the ability to rotate and change the key material. Key aliases allow you to abstract the underlying key from the application, making it easier to switch to a new key without changing the application code. AWS owned keys and AWS managed keys do not provide the same level of control for key rotation and material changes as customer managed keys. By creating a key alias and associating it with a new customer managed key each time the security team requests a key change, you ensure that the encryption uses fresh key material while maintaining seamless integration with your application.
  3. Arad 👍 2 Answered C
    C is the right one.
  4. Nash101 👍 1
    Agree C

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Preserve EC2 forensic evidence by isolating first, then capturing memory before stopping the instance

S-grade

Grant the report Lambda Security Hub read-only access because findings are already in Security Hub

S-grade

Deny inbound MySQL 3306 and allow outbound TLS 443 with ephemeral return in a custom NACL

S-grade

Prepare a PHI/public-bucket audit with Macie, Audit Manager, and Security Hub FSBP

S-grade

← Back to SCS-C02 Study Guide