DOP-C02 Security and Compliance 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.

• ✗

  Store the secret in a configuration file on the EC2 instance and encrypt the file system.

  Why it's wrong here

  Persisting the secret in a configuration file on an EC2 instance—even with an encrypted file system—does not protect it from any process with local access to the running instance. The OS must hold the decryption key (e.g., a KMS-backed EBS key) available to the kernel, so an attacker with compromised credentials or an exploited application can simply read the file while the instance is running. Additionally, this approach lacks audit logging, secret rotation, and any fine-grained permission control, and the secret will be copied into any AMI or snapshot created from the instance.

• ✗

  Store the secret in AWS Systems Manager Parameter Store and retrieve it via the AWS CLI at boot time.

  Why it's wrong here

  Retrieving the secret from Parameter Store via the AWS CLI at boot time only moves the problem into shell history and user data. The CLI command that fetches the secret must be embedded in user data, which is visible via the instance metadata service and the EC2 console, so anyone with read access to that metadata or the launch template can see the command and potentially intercept the returned secret. While Parameter Store can hold secrets, it does not natively provide the same rotation or access-tracking features as Secrets Manager, and the instance role would need broadly scoped permissions that raise the blast radius if compromised.

• ✓

  Modify the application code to use the AWS SDK to retrieve the secret from Secrets Manager using the instance's IAM role.

  Why this is correct

  Using the AWS SDK inside the application to retrieve the secret from Secrets Manager is the correct pattern because the secret is fetched at runtime, encrypted in transit, and never written to user data, environment variables, or disk. The EC2 instance profile's IAM role gives the SDK temporary, automatically rotated credentials, so no hard-coded access keys or CLI scripts are required. This approach leverages Secrets Manager's built-in rotation, CloudTrail auditing, and fine-grained IAM policies that can limit which secrets a given instance role can read, and it lets the SDK cache the secret to minimize latency while still respecting rotation.

• ✗

  Use a KMS key to encrypt the secret and store the encrypted value in user data.

  Why it's wrong here

  Encrypting the secret with a KMS key and placing the ciphertext in user data is flawed because user data is an unencrypted part of instance metadata that any process with access to the metadata service (or an administrator reviewing the EC2 console/CloudTrail) can retrieve. The KMS key does not protect the secret at rest; instead, the IAM role attached to the instance almost certainly has permission to call KMS Decrypt so the application can use the secret, meaning an attacker who gains access to the ciphertext from user data can simply decrypt it by invoking KMS with that instance's role. Because the ciphertext is static, rotating the underlying secret would require editing the user data and relaunching the instance, creating operational overhead and leaving historical copies in metadata snapshots.

Go deeper

Related to this question