Examkin

Question

Difficulty: HardAutomating Deployment and Configuration Management

An enterprise uses AWS Organizations to manage a multi-account environment. The central Platform DevOps team maintains configuration baselines using Ansible playbooks stored in a private GitHub repository. To automate configuration management and enforce these baselines on Amazon EC2 instances across multiple workload accounts, the team uses AWS Systems Manager State Manager associations. To pull the playbooks from the private repository, State Manager requires a GitHub Personal Access Token (PAT). The DevOps team stores the GitHub PAT as a secret in AWS Secrets Manager within a centralized Shared Services account. They configure the secret using the default AWS-managed KMS key (aws/secretsmanager). The EC2 instances in the workload accounts are assigned an IAM instance profile with a policy that allows the secretsmanager:GetSecretValue action on the secret's ARN. When the State Manager association executes in the workload accounts, the execution fails on the EC2 instances, and the Systems Manager runbook log displays an AccessDeniedException error related to AWS KMS decryption. Which of the following actions should the Solutions Architect take to resolve this issue and enable successful configuration management?

  1. A
    Update the workload accounts' IAM instance profile policies to explicitly grant the kms:Decrypt action targeting the default AWS-managed KMS key (aws/secretsmanager) ARN in the Shared Services account, and configure the secret's resource policy to trust the workload account IDs.
  2. B
    Create and attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing the workload accounts that explicitly permits the secretsmanager:GetSecretValue and kms:Decrypt actions, ensuring the permissions are inherited by the IAM roles without modifying local KMS or secret resource policies.
  3. Re-create the secret in the Shared Services account using a Customer Managed Key (CMK). Configure the CMK key policy to allow kms:Decrypt permissions for the workload accounts' IAM roles. Add a resource-based policy to the Secrets Manager secret that permits secretsmanager:GetSecretValue for the workload IAM roles, and update the workload accounts' IAM instance profile policies to allow kms:Decrypt on the CMK.Answer
  4. D
    Enable AWS CloudFormation drift detection on the workload stacks to identify modified local configuration parameters, trigger an SSM Automation runbook to restore the SSM Agent configuration to its baseline, and configure AWS CodeDeploy to perform a linear deployment of the Ansible playbook.

Answer

The correct answer is to re-create the secret in the Shared Services account using a Customer Managed Key (CMK), configure the CMK's key policy and secret's resource policy to allow access from the workload accounts' IAM roles, and update the workload accounts' IAM instance profile policies to allow kms:Decrypt on the CMK.
The correct answer is correct because AWS Secrets Manager secrets encrypted with the default AWS-managed key (aws/secretsmanager) cannot be accessed cross-account. AWS-managed keys do not allow their key policies to be modified, which is a prerequisite for cross-account access. Therefore, a Customer Managed Key (CMK) must be used. Additionally, cross-account access requires a resource-based policy on the secret itself to grant retrieval permissions to the external workload account roles, and the workload roles must have corresponding IAM policies allowing secrets retrieval and KMS decryption.

Step-by-Step Solution

1
Identify the root cause of the AccessDeniedException error during the State Manager association run.
The execution log indicates a KMS decryption error, pointing to a cross-account decryption permission issue when the managed instances retrieve the GitHub Personal Access Token from Secrets Manager in the Shared Services account.
SSM State Manager uses the IAM instance profile of the EC2 instance to execute tasks, meaning the instance's IAM role must have permission to access the secret and decrypt the KMS key.
2
Analyze the KMS key type used for encrypting the secret.
The secret was encrypted using the default AWS-managed KMS key (aws/secretsmanager), which cannot be modified to grant cross-account access.
AWS-managed KMS keys do not allow custom key policies, making them incompatible with cross-account access scenarios.
3
Configure a Customer Managed Key (CMK) and resource policies to establish secure cross-account access.
A CMK is created in the Shared Services account with a key policy allowing kms:Decrypt to workload roles. The secret is re-created with this CMK, and its resource policy is configured to allow secretsmanager:GetSecretValue for the workload roles. The workload instance profile IAM policies are updated to allow kms:Decrypt on the CMK and secretsmanager:GetSecretValue on the secret.
Establishing cross-account access to Secrets Manager requires both a resource policy on the secret, an IAM policy on the requesting role, and a custom KMS key policy permitting cross-account decryption.

Key Concept

Establishing secure cross-account access for AWS Secrets Manager secrets requires using a Customer Managed Key (CMK) because default AWS-managed keys (e.g., aws/secretsmanager) cannot be shared cross-account or have their key policies modified.
Rate this question

Topics

Automating Deployment and Configuration Management