A company uses user data scripts that contain sensitive information to bootstrap Amazon EC2 instances. A security engineer discovers that this sensitive information is viewable by people who should…

Question

Options

• AStore the scripts in the AMI and encrypt the sensitive data using AWS KMS. Use the instance role
• BStore the sensitive data in AWS Systems Manager Parameter Store using the encrypted string
• CExternalize the bootstrap scripts in Amazon S3 and encrypt them using AWS KMS. Remove the
• DBlock user access of the EC2 instance's metadata service using IAM policies. Remove all scripts

• A
  2% (1)
• B
  82% (47)
• C
  5% (3)
• D
  11% (6)

Explanation

AWS Systems Manager Parameter Store with SecureString encryption is the purpose-built solution for this problem - it stores sensitive values (passwords, API keys, tokens) encrypted via KMS, grants access through IAM policies at the parameter level, and allows EC2 instances to retrieve secrets at runtime without ever embedding them in user data scripts.

Why the distractors fall short:

• A - Storing scripts in an AMI still embeds sensitive data at rest in the image itself, which can be shared or copied; this doesn't solve the exposure problem.
• C - S3 + KMS encryption is better than plaintext, but the scripts still contain the sensitive values in their decrypted form during execution; Parameter Store keeps secrets out of the script entirely.
• D - Blocking the metadata service breaks legitimate EC2 functionality (instance roles, IMDSv2) and doesn't actually remove or protect the sensitive data.

Memory tip: Think of Parameter Store as a "vault with a receptionist" - your EC2 instance asks for a secret by name at runtime, IAM decides if it's allowed in, and KMS handles the encryption. The secret never needs to live in the script itself, which is the root cause of the exposure.

No community discussion yet for this question.