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.

• ✗

  Use the root user credentials of the AWS account.

  Why it's wrong here

  The root user of the AWS account possesses full, unrestricted administrative access to all resources and billing. Using these credentials for an EC2 application violates the fundamental principle of least privilege, exposes the account to catastrophic compromise if the keys are ever leaked, and provides no way to scope permissions down to a single S3 read requirement. Best practice is to delegate permissions through an IAM role with a narrowly defined policy.

• ✗

  Store AWS access keys in the instance's user data and use them in the application.

  Why it's wrong here

  Embedding long-term AWS access keys in instance user data is insecure because user data is readable by any process or user with access to the local metadata service (169.254.169.254/latest/user-data) and is also visible in the EC2 console. These static credentials never expire and will continue to work even if the instance is terminated, creating a persistent exposure risk. An instance profile instead injects short-lived, automatically rotated credentials.

• ✗

  Create an S3 bucket policy that allows the EC2 instance's public IP address.

  Why it's wrong here

  An S3 bucket policy cannot authorize an EC2 instance directly; to restrict by IP you would need a condition key like aws:SourceIp, but that only checks the source IP address of the request, not the identity of the instance, so any client on that IP (e.g., behind a NAT) would inherit the permission. EC2 public IPs are also dynamic by default and can change after stop/start, making the policy fragile. The correct approach is to grant identity-based permissions via an IAM role attached to the instance profile, not resource-based bucket policy conditions.

• ✓

  Create an IAM role with an S3 read policy and attach it to the EC2 instance profile.

  Why this is correct

  Create an IAM role with a policy such as s3:GetObject and s3:ListBucket, then attach it to the EC2 instance profile. The instance will automatically obtain temporary security credentials from AWS STS through the instance metadata service, which are rotated every few hours and never stored on disk. This follows least privilege, avoids long-lived keys, and is the AWS best practice for granting permissions to a running instance.

Go deeper

Related to this question