SCS-C02 Management and Security Governance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  "Principal": {"AWS": "arn:aws:iam::123456789012:*"}

  Why it's wrong here

  Using the wildcard suffix ':*' in the principal ARN delegates permission to every IAM entity (users, groups-attached policies, and roles) in the account. If any IAM principal in the account is compromised or misconfigured, it can directly call kms:Decrypt, kms:GenerateDataKey, or other key operations. This broad blast radius violates least privilege and would fail an AWS audit because it grants key access to principals that were never explicitly intended to use the key.

• ✗

  "Principal": {"AWS": "*"}

  Why it's wrong here

  Using 'Principal': {'AWS': '*'} allows anonymous access to the KMS key, meaning anyone with network access to AWS can attempt to use the key, including principals from other AWS accounts and unauthenticated users. KMS key policies are evaluated before IAM policies, and a 'Principal': '*' in the key policy grants permissions without requiring any IAM authorization. This is an extreme security risk because any attacker who obtains an encrypted S3 object URL could call KMS decrypt operations if the S3 bucket policy also permits access, effectively bypassing the intended encryption access controls.

• ✗

  "Principal": {"AWS": "arn:aws:iam::123456789012:root"}

  Why it's wrong here

  Specifying the root user ARN as the principal grants access only to the account root user, which is an IAM entity that has unconditional administrative permissions. While the root user can delegate access via IAM policies, the key policy itself is still restrictive to that single principal. However, this is incorrect for a workload scenario because applications running under an IAM role (e.g., an EC2 instance or Lambda function) cannot use the KMS key — their role does not match the root principal ARN. Moreover, using the root user for day-to-day operations is a security anti-pattern that violates the principle of least privilege and AWS recommends against storing root access keys.

• ✓

  "Principal": {"AWS": "arn:aws:iam::123456789012:role/AllowedRole"}

  Why this is correct

  This principal ARN explicitly identifies the IAM role 'AllowedRole' in the account. When the role is assumed (by an EC2 instance, Lambda, or an STS AssumeRole call), the role's temporary credentials include the role's ARN as the principal, so the KMS key policy exactly matches it. This is the correct least-privilege configuration because no other IAM user or role can use the key unless the role allows it, and the key policy does not expose the key to the entire account. You could further restrict it by adding a condition like kms:ViaService to limit it to S3, but this is the best answer among the options.

Go deeper

Related to this question