Create an IAM role for EC2 with least-privilege access to the SalesLedgerV3 table and attach it to the instance using an instance profile is correct because it provides temporary credentials to the application running on the instance and it avoids managing static secrets.

The role attached via an instance profile lets the EC2 instance obtain temporary AWS credentials from the instance metadata service and those credentials are rotated automatically by AWS. This approach implements least privilege by scoping permissions to the SalesLedgerV3 table and it is easier to maintain than distributing and rotating long term keys.

Store IAM user access keys in AWS Secrets Manager and have the application retrieve them to call DynamoDB is not ideal because it still depends on long term IAM user credentials and you must manage rotation and access to those secrets. Secrets Manager protects stored secrets but it does not eliminate the operational risk of static credentials on the instance.

Create an IAM user with DynamoDB permissions and save its access keys on the instance file system for the application to load is insecure because embedding static credentials on the host increases the chance of accidental exposure and makes rotation manual and error prone.

Create an IAM role and add the specific EC2 instance ID to the role trust policy so the instance can assume it is incorrect because EC2 roles are granted through instance profiles and the role trust policy uses the EC2 service principal rather than listing instance IDs. The correct delivery mechanism is to attach the role to the instance with an instance profile.

Full AWS Practitioner Certification Question