SCS-C03 Identity and Access Management 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.

• ✗

  Embed IAM access keys directly into the application code.

  Why it's wrong here

  Hardcoding credentials in code is a critical security vulnerability. If the code is pushed to a repository, the keys can be easily stolen. This practice violates fundamental security principles and makes rotating credentials extremely difficult, as it requires re-deploying the application whenever the keys need to be updated.

• ✗

  Store IAM access keys in a configuration file on the EC2 instance.

  Why it's wrong here

  Storing keys in configuration files is nearly as insecure as hardcoding them. Any user or process with read access to the file can compromise the credentials. Furthermore, managing these files across multiple instances is an operational burden and does not provide the automated rotation benefits offered by IAM roles.

• ✓

  Assign an IAM role to the EC2 instance via an instance profile.

  Why this is correct

  Using IAM roles with instance profiles is the gold standard for EC2 security. It provides temporary, short-lived credentials that are automatically rotated by the AWS environment. The application uses the AWS SDK to retrieve these credentials, ensuring no sensitive data is stored on the disk or exposed in the code.

• ✗

  Create a public DynamoDB table to allow unauthenticated access.

  Why it's wrong here

  Public access to data stores is a severe misconfiguration. DynamoDB tables should never be made public unless they are intended to serve as a public CDN-like interface, which is rarely the case for internal application data. This exposes sensitive data to the entire internet, violating all data privacy and compliance standards.