DVA-C02 Security 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 an S3 bucket policy that allows access from the EC2 instance's public IP address.

  Why it's wrong here

  Using an S3 bucket policy that allows access from an EC2 instance's public IP address is an insecure and unscalable approach. Public IP addresses are not a reliable form of identity; they can change, especially with dynamic IP assignments or instance restarts, leading to broken access. This method only authorizes network origin, not the specific EC2 instance's identity, failing to provide proper authentication or granular authorization based on the instance itself.

• ✓

  Create an IAM role and attach it to the EC2 instance profile.

  Why this is correct

  Creating an IAM role and attaching it to an EC2 instance profile is the AWS-recommended and most secure method for granting permissions. The instance profile acts as a container for the IAM role, allowing the EC2 instance to assume the role and obtain temporary, frequently rotated credentials from the EC2 metadata service. This eliminates the need to store long-term AWS credentials directly on the instance, significantly reducing the risk of credential compromise and adhering to the principle of least privilege.

• ✗

  Set the AWS credentials as environment variables in the user data script.

  Why it's wrong here

  Setting AWS credentials as environment variables, even within a user data script, is a highly insecure practice. Any process running on the EC2 instance can potentially read these environment variables, meaning that if the instance is compromised, an attacker gains immediate access to the associated AWS resources. This method bypasses proper identity and access management controls and requires manual rotation and management of static credentials, increasing operational overhead and security risk.

• ✗

  Store the AWS access key ID and secret access key in a configuration file on the instance.

  Why it's wrong here

  Storing static AWS access key IDs and secret access keys directly in a configuration file on an EC2 instance represents a severe security vulnerability. These long-term credentials never expire unless manually rotated, and if the file is accidentally exposed or the instance is compromised, an attacker gains persistent, full access to the AWS resources associated with those keys. This approach completely undermines the principle of least privilege and the use of temporary, identity-based credentials.

Go deeper

Related to this question