SAA-C03 Design Secure Architectures 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.

• ✗

  Store the database password in user data

  Why it's wrong here

  User data is a plaintext script or payload passed to an EC2 instance at launch and stored on the instance itself; it can be retrieved by anyone with IAM permission to describe the instance or by anyone with OS-level access to the running instance. Since user data is not encrypted at rest and is visible in the AWS Console and APIs, storing a database password there exposes the secret to anyone who can read the instance metadata. Moreover, rotating the password would require relaunching instances with new user data, making credential rotation impractical and error-prone.

• ✓

  IAM database authentication for RDS with an EC2 instance role

  Why this is correct

  IAM database authentication for RDS replaces a static database password with an authentication token generated from the EC2 instance profile using AWS Signature Version 4. The application requests the token via the RDS API (or AWS SDK), and the token is valid for only 15 minutes, so the credential is ephemeral and automatically rotated. This approach avoids long-lived secrets in application code or configuration, enforces least-privilege access because the IAM role governs which database user the instance can connect as, and logs all token generation in CloudTrail. Note that the RDS instance must have IAM DB authentication enabled, and the database user must be created with the `PASSWORD` clause set to `AUTHENTICATED OVER IAM` in PostgreSQL.

• ✗

  Use a security group rule that allows only application instances

  Why it's wrong here

  A security group acts as a stateful network firewall, restricting inbound traffic to the RDS endpoint based on source IP addresses or other security groups. While limiting connections to only the application instances is a good defense-in-depth practice, it does not authenticate individual users or processes; if the application itself is compromised, or if a malicious actor obtains credentials, the security group will not block them. The database still requires a valid username and password (or IAM auth) to establish a session, so security groups alone do not meet the requirement to replace static database authentication.

• ✗

  Embed the database password in the AMI

  Why it's wrong here

  Baking a database password into an AMI embeds the secret into a reusable image that is often copied across AWS accounts, shared within an organization, or stored as snapshots in S3. Anyone with access to the AMI—including a developer who only needs the EC2 image—can extract the password from the root volume, making it impossible to restrict exposure to production operators. Rotation is also severely hindered because every running instance launched from that AMI continues using the same embedded password, forcing a full image rebuild and new instance rollout for each credential change, which increases downtime and operational burden.

Go deeper

Related to this question