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.

• ✗

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

  Why it's wrong here

  Storing AWS access keys and secret keys directly on an EC2 instance in a configuration file is highly insecure. These are long-term credentials that, if compromised, grant persistent access to your AWS resources, potentially leading to significant data breaches or unauthorized operations. This method violates the principle of least privilege and introduces a critical security vulnerability, as the keys could be exposed through misconfigurations, code vulnerabilities, or unauthorized access to the instance.

• ✗

  Use an IAM user with programmatic access and attach a policy allowing S3 access.

  Why it's wrong here

  While using an IAM user provides granular permissions, assigning an IAM user's programmatic access keys to an application running on an EC2 instance still relies on long-term credentials. These static keys, similar to those stored in a configuration file, must be securely managed, rotated, and protected from exposure. This approach introduces operational overhead and security risks, as a compromise of these keys would grant persistent access to the associated IAM user's permissions, making it an anti-pattern for machine-to-AWS service access.

• ✓

  Launch the EC2 instance with an IAM role that grants S3 access.

  Why this is correct

  Launching an EC2 instance with an IAM role is the AWS best practice for granting applications secure access to AWS services like S3. An IAM role provides temporary security credentials that are automatically rotated and delivered to the instance via the instance metadata service. This eliminates the need to embed or manage long-term access keys on the instance, significantly reducing the risk of credential compromise and simplifying credential management, aligning with the principle of least privilege.

• ✗

  Use a shared secret key stored in AWS Secrets Manager and retrieve it at runtime.

  Why it's wrong here

  While AWS Secrets Manager is excellent for securely storing and rotating database credentials, API keys, or other application secrets, using it to store AWS access keys for an EC2 instance to access S3 introduces unnecessary complexity and an architectural anti-pattern. The EC2 instance would still require *some* initial credentials or an IAM role to access Secrets Manager itself, creating a bootstrapping problem or an indirect reliance on long-term keys. IAM roles for EC2 instances are specifically designed for this exact use case, offering a more direct, secure, and simpler solution without additional service dependencies.

Go deeper

Related to this question