SAA-C03 Design Secure Architectures Practice Question

A order processing API uses Amazon RDS for PostgreSQL. Application credentials must not be stored on the EC2 instances, and authentication should use short-lived credentials. What should the architect recommend?

⚠ Common exam trap

Many exam-takers confuse network-level controls (security groups) with authentication mechanisms, or they assume that storing credentials in user data or AMIs is acceptable because it is 'hidden,' but the exam explicitly tests the requirement for short-lived, non-persistent credentials.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

IAM database authentication for RDS with an EC2 instance role

IAM database authentication for RDS allows EC2 instances to authenticate to PostgreSQL using a short-lived token generated via the AWS CLI or SDK, instead of a static password. By assigning an IAM instance role to the EC2 instance, the application can obtain the token without storing any credentials on the instance, meeting both security requirements. This approach uses the IAM role's temporary security credentials to generate a password token that is valid for 15 minutes, after which a new token must be obtained.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
IAM database authentication for RDS with an EC2 instance role
Why this is correct
IAM database authentication lets the EC2 instance's attached role call RDS's GenerateDBAuthToken API, producing a signed token that the PostgreSQL client presents as the password; the token expires after 15 minutes and the connection uses SSL, so no permanent secret exists in application code, configuration files, or disk. With this design, you create a DB user for IAM authentication in PostgreSQL and grant it privileges while controlling access via IAM policies, making credential rotation unnecessary for the application.
✗
Store the database password in user data
Why it's wrong here
User data is a plaintext bootstrap script that any process on the instance can read from the link-local metadata service (169.254.169.254/latest/user-data) and that is also visible in the EC2 console during launch. Putting a database password there makes it accessible to local users, a later malware compromise, or anyone with EC2 describe/start permissions on the instance, and it does nothing to support password rotation or auditing.
✗
Use a security group rule that allows only application instances
Why it's wrong here
A security group rule that only allows traffic from application instances controls network reachability to the RDS database, but it does not prove the caller's identity or carry database authentication credentials. RDS PostgreSQL still requires either a stored password or an IAM authentication token, so this measure merely shrinks the attack surface at the network layer while leaving the hard-coded secret problem completely unsolved.
✗
Embed the database password in the AMI
Why it's wrong here
Baking a password into an AMI embeds a long-lived, shared secret in a reusable snapshot that can be copied, shared across accounts, or used as the base for many instances, exponentially increasing who can extract it. Any rotation of the RDS credential then forces you to rebuild a new AMI and re-provision every fleet, and the old secret commonly persists in snapshots even after deletion.

Go deeper

SAA-C03 Design Secure Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question