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.

• ✗

  Set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the AMI.

  Why it's wrong here

  Baking long-term AWS access key environment variables into an AMI means the credentials are embedded in the snapshot and copied to every instance launched from it, making rotation a matter of rebuilding and republishing the image and creating a persistent credential leak surface. Anyone with read access to the AMI or who can inspect an instance's environment through processes or SSM can harvest the keys, which also violate least privilege because they are never scoped to a specific instance role. Unlike instance-profile temporary credentials fetched from the metadata service, these long-lived keys never auto-rotate, so a compromise remains valid indefinitely.

• ✓

  Create an IAM role with the required permissions and attach it to the EC2 instance as an instance profile.

  Why this is correct

  An IAM role attached as an instance profile is the AWS-recommended mechanism because the EC2 instance automatically assumes the role through the instance metadata service (IMDS), receiving temporary credentials from AWS STS that are valid for a limited duration and refreshed automatically by the SDK or CLI. This eliminates the need to store or manage long-lived access keys while letting you scope the role with a narrowly defined read-only policy, such as allowing only s3:GetObject or ec2:DescribeActions. The instance profile acts as the container for the role, and the per-instance trust policy ensures only instances with that profile can use the role, giving centralized control, easy revocation, and cross-account access when needed.

• ✗

  Store AWS access keys in the EC2 user data script.

  Why it's wrong here

  Storing AWS credentials in EC2 user data is dangerous because user data is accessible via the instance metadata service at http://169.254.169.254/latest/user-data, so any process or attacker with local code execution on the instance can trivially read the embedded access key ID and secret. Additionally, user data is visible in the EC2 console to any IAM principal with the ec2:DescribeInstanceAttribute permission, remains in plaintext for the entire instance lifecycle, and is often included in launch templates or CloudFormation resources, widening exposure to anyone who can view those templates. These long-lived keys do not rotate and persist even after the instance is terminated, making a breach difficult to detect and remediate.

• ✗

  Retrieve the credentials from AWS Systems Manager Parameter Store using a custom script.

  Why it's wrong here

  Retrieving credentials from Parameter Store via a custom script would require the EC2 instance to have an IAM role that grants access to the Parameter Store itself, which introduces a circular dependency: the instance still needs an initial identity to fetch the S3 credentials. The correct mechanism—an IAM role attached directly to the EC2 instance—provides temporary credentials automatically via the instance metadata service, eliminating the need for any custom script or stored secret. This option is tempting because Parameter Store is designed for securely storing configuration data and secrets, and it would be the correct choice if the developer needed to rotate or centrally manage static credentials for an application that cannot use IAM roles, such as a legacy system running outside AWS.

Go deeper

Related to this question