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 AWS access keys in the application configuration

  Why it's wrong here

  Hard-coding or embedding long-term AWS access keys (access key ID and secret access key) in application configuration creates a standing credential that can be exposed via config files, debug logs, or source control, and requires manual rotation whenever it leaks. IAM roles, in contrast, provide temporary credentials that are automatically rotated, so storing any key material in the application is an unnecessary and high-risk anti-pattern.

• ✓

  Create an IAM role with a policy allowing only necessary S3 actions and attach it to the EC2 instance

  Why this is correct

  Attaching an IAM role to the EC2 instance profile is the correct method because the instance automatically retrieves short-lived credentials from the instance metadata service (IMDS) and uses them to sign S3 API requests. The role's policy should only include the actions needed on the specific S3 bucket/prefix, satisfying least privilege and avoiding long-lived secrets entirely. These credentials are refreshed automatically, and access can be revoked by modifying the role, making change management clean and auditable.

• ✗

  Use an S3 bucket policy to allow access from the EC2 instance's public IP

  Why it's wrong here

  Using an S3 bucket policy with an aws:SourceIp condition can technically allow access from the EC2 instance's public IP, but public IPs on EC2 are dynamic unless an Elastic IP is attached, so the policy would break on instance stop/start. More importantly, this approach grants permission based solely on network origin rather than on a verified IAM principal, so any process or attacker able to egress from that IP is treated as authorized, making it a blunt, insecure, and difficult-to-audit control.

• ✗

  Configure the EC2 security group to allow outbound access to S3

  Why it's wrong here

  A security group is a stateful network firewall that filters traffic based on IP/port, not an IAM authorization mechanism; configuring outbound HTTPS to S3 only establishes TCP connectivity. The application still needs AWS credentials and an identity-based policy permitting the desired S3 actions—without them, S3 returns AccessDenied because the request is unauthenticated/unauthorized. Even when using a VPC endpoint or allowing the S3 prefix list, the security group rule never grants API-level permissions and should never be considered an access-control substitute.

Go deeper

Related to this question