What should the solutions architect do to meet these requirements?
Create an IAM role to read the DynamoDB tables. Associate the role with the application instances by referencing an instance profile.
Create an IAM role that has the required permissions to read and write from the DynamoDB tables. Add the role to the EC2 instance profile, and associate the instance profile with the application instances.
Use the parameter section in the AWS CloudFormation template to have the user input access and secret keys from an already-created IAM user that has the required permissions to read and write from the DynamoDB tables.
Create an IAM user in the AWS CloudFormation template that has the required permissions to read and write from the DynamoDB tables. Use the GetAtt function to retrieve the access and secret keys, and pass them to the application instances through the user data.
Explanations:
While creating an IAM role to read DynamoDB tables is necessary, this option does not specify the full permissions needed, such as read and write access, and does not mention associating the role with an instance profile for the application instances.
This option correctly creates an IAM role with the necessary permissions to read and write from the DynamoDB tables. Associating the role with an instance profile and then linking it to the application instances ensures that the EC2 instances can access the DynamoDB tables securely without exposing API credentials.
Using parameters to input access and secret keys from an IAM user is not a secure practice, as it exposes sensitive information in the CloudFormation template. It also does not leverage AWS best practices for temporary credentials or roles.
Creating an IAM user and passing access and secret keys to the application instances via user data also exposes sensitive credentials. This approach is not secure and goes against best practices for managing AWS credentials, which should focus on roles instead of users with static keys.