Question

Difficulty: Very hardAWS Key Management Service (KMS) and Data Encryption

A SysOps Administrator is managing an AWS KMS Customer Managed Key (CMK) that encrypts sensitive finance data. The key policy is configured as follows:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow admin access",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::444455556666:role/FinanceSecurityAdmin"
},
"Action": "kms:*",
"Resource": "*"
}
]
}

Due to an administrative error, the `FinanceSecurityAdmin` IAM role in account 444455556666444455556666 is deleted. The administrator quickly recreates the IAM role with the exact same name and path. However, when trying to manage the CMK using the recreated role, the administrator receives an Access Denied error.

Which of the following describes the root cause of this behavior and the correct resolution?

  1. The KMS key policy stores the unique principal ID of the role, which changed when the role was recreated. Because the key policy does not delegate permissions to the AWS account root user, the key policy cannot be modified by any user in the account, and the administrator must contact AWS Support to restore access.Answer
  2. B
    The recreated role lacks the necessary permissions to update key policies. The administrator should attach an IAM policy to the role that grants kms:PutKeyPolicy on the CMK, which will override the key policy's restrictions and restore access.
  3. C
    The AWS account root user retains global administrative control over all resources. The administrator must log in using the AWS account root user credentials, which automatically bypasses the KMS key policy, and update the policy to map to the new role principal.
  4. D
    The recreated role cannot be assumed by AWS KMS to evaluate policies. The administrator must attach an IAM policy to the role that grants iam:PassRole permissions targeting the AWS KMS service principal to restore the trust relationship.

Answer

The KMS key policy stores the unique principal ID of the role, which changed when the role was recreated. Because the key policy does not delegate permissions to the AWS account root user, the key policy cannot be modified by any user in the account, and the administrator must contact AWS Support to restore access.
The correct answer explains that AWS KMS key policies evaluate permissions using the principal's unique internal ID rather than the friendly ARN name. When the IAM role was deleted and recreated, a new unique ID was generated, which does not match the old ID stored in the KMS key policy. Because the KMS key policy did not include the root account delegation statement (which allows IAM policies to grant access to the key), there is no way for any administrator or even the root user to modify the key policy locally. Therefore, the key is orphaned, and the administrator must contact AWS Support to resolve the issue.

Step-by-Step Solution

1
Analyze the KMS key policy provided in the scenario.
The key policy only grants administrative permissions ('kms:*') to the specific IAM role principal 'arn:aws:iam::444455556666:role/FinanceSecurityAdmin'. It lacks the default root account delegation statement ('arn:aws:iam::444455556666:root').
This determines whether IAM policies or other principals (like root) have any administrative control over the key.
2
Evaluate the impact of deleting and recreating the IAM role.
Although the new role has the same name and ARN, its underlying unique principal ID is different from the original role.
AWS KMS evaluates permissions based on unique principal IDs that are mapped internally when the policy is saved.
3
Determine if the policy can be updated locally.
Since the only authorized principal in the policy (the old role ID) no longer exists, and there is no root account delegation to allow IAM policy overrides, no user in the account can modify the key policy.
Without root account delegation, KMS key policies are the sole authority, and local IAM policies cannot grant access.
4
Identify the required remediation path.
Since the key is locked and unmanageable locally, AWS Support must be contacted to resolve the policy deadlock.
AWS Support is the only entity capable of assisting in recovering or deleting the orphaned key.

Key Concept

KMS Key Policy Precedence and Unique Principal IDs
Rate this question