SAA-C03 Design Secure Architectures Practice Question

A IoT ingestion 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 candidates confuse network-level controls (security groups) with authentication mechanisms, assuming that restricting traffic alone satisfies credential security, while the real requirement is about eliminating stored long-term credentials entirely.

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 short-lived credentials obtained via an IAM instance role, eliminating the need to store long-term credentials on the instance. The EC2 instance assumes the role, retrieves a temporary authentication token (valid for 15 minutes), and uses it to connect to the RDS database, meeting both security requirements.

Answer analysis

Option-by-option breakdown

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

✗
Store the database password in user data
Why it's wrong here
Storing the database password in EC2 user data is insecure because user data is passed in plaintext to the instance at launch and remains readable from the instance metadata and launch configuration. Unlike a secret-store lookup, it is not encrypted, cannot be centrally rotated, and anyone with DescribeInstanceAttribute or local access can recover the exact password. AWS recommends storing secrets in AWS Secrets Manager or using IAM database authentication to avoid persistent plaintext credentials.
✗
Embed the database password in the AMI
Why it's wrong here
Baking the database password into an AMI means every instance launched from that image carries the same static secret, and rotation becomes a multi-step image rebuild and redeploy process. AMI sharing, copying, or snapshotting can silently expose the credential to other accounts, and you have no granular audit trail of who used it. This violates the principle of least privilege and makes breach recovery slower, unlike temporary IAM-generated tokens.
✓
IAM database authentication for RDS with an EC2 instance role
Why this is correct
With IAM database authentication, an EC2 instance uses its attached IAM role to generate a temporary authentication token via the RDS generate_db_auth_token API, then supplies that token as the PostgreSQL password. The token is valid for 15 minutes and is cryptographically signed by the IAM role, so RDS can verify it without a stored password. This eliminates embedded secrets, enables rotation by simply refreshing the role credentials, and gives you centralized IAM policies to control which DB users can connect from which identity.
✗
Use a security group rule that allows only application instances
Why it's wrong here
A security group rule permitting application instances restricts which source IPs can reach the RDS listener, but it operates at the network layer and does not authenticate the database user or the application making the connection. If an attacker compromises any allowed instance or exploits an SSRF vulnerability, the extra network restriction is irrelevant because the DB still asks only for a username/password. The proper remediation is to remove static database passwords and use IAM-generated tokens, while keeping the security group as defense in depth.

Go deeper

SAA-C03 Design Secure Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question