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.

• ✗

  Create a bucket policy on S3 to allow EC2 to access SQS

  Why it's wrong here

  Creating a bucket policy on S3 is incorrect because S3 bucket policies are specifically designed to control access permissions for Amazon S3 buckets and their objects. These policies cannot be used to grant an EC2 instance permissions to interact with a completely different AWS service like Amazon SQS, which has its own distinct authorization mechanisms and policy types.

• ✗

  Use a resource-based policy on the SQS queue allowing the EC2 instance's security group

  Why it's wrong here

  Using a resource-based policy on an SQS queue to allow an EC2 instance's security group is incorrect because SQS queue policies define permissions for IAM principals (users, roles, or AWS accounts) to perform actions on the queue. Security groups are network-level constructs that control traffic flow to and from EC2 instances; they are not identity-based principals that can be specified in an IAM policy statement for resource access.

• ✓

  Assign an IAM role to the EC2 instance with permissions to send messages to SQS

  Why this is correct

  Assigning an IAM role to the EC2 instance with appropriate SQS permissions is the recommended and most secure approach. When an IAM role is associated with an EC2 instance, applications running on that instance can automatically obtain temporary, frequently rotated security credentials via the instance metadata service. This eliminates the need to hardcode or store long-term credentials, significantly enhancing security and simplifying credential management.

• ✗

  Create an IAM user and store the credentials in the application configuration file

  Why it's wrong here

  Creating an IAM user and storing its credentials in the application configuration file is a highly insecure practice. Embedding static access keys and secret keys directly within application code or configuration files creates a significant vulnerability, as these long-term credentials could be accidentally exposed, committed to public repositories, or compromised if the instance or configuration file is accessed by unauthorized entities.

Go deeper

Related to this question