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

  Storing the database password in user data is insecure because user data is available to any process running on the instance via the instance metadata service at http://169.254.169.254/latest/user-data. It is also returned in the EC2 console and API responses unless explicitly redacted, making it visible to anyone with read access. A plaintext secret in user data has no rotation mechanism, and if the instance is compromised, the attacker can trivially retrieve the password and reuse it against the RDS database.

• ✓

  IAM database authentication for RDS with an EC2 instance role

  Why this is correct

  IAM database authentication for RDS with an EC2 instance role is the correct approach because it lets the application generate a short-lived (15-minute) authentication token using SigV4, eliminating any stored database password. The EC2 instance assumes an instance role with rds-db:connect permissions, and the application presents the token to PostgreSQL over SSL; RDS validates the token against IAM rather than a static password. This provides centralized credential management via IAM roles, automatic rotation of credentials, and ensures no secret is baked into configurations, user data, or code.

• ✗

  Use a security group rule that allows only application instances

  Why it's wrong here

  Using a security group rule to allow only application instances restricts network access to the RDS endpoint, but it is purely a network-layer control and does not authenticate the identity of the caller. Any process on an allowed instance can still attempt SQL login, and if the instance is compromised, the attacker inherits the allowed network path; the database would still require a static password to be stored somewhere, reintroducing the original secret-management problem. Security groups complement authentication but cannot replace IAM database authentication or a robust password mechanism.

• ✗

  Embed the database password in the AMI

  Why it's wrong here

  Embedding the database password in the AMI bakes a long-lived secret into a reusable image artifact that is copied, versioned, and launched in multiple environments. Anyone with access to the AMI—or any snapshot derived from it—can extract the password, and unauthorized AMI sharing can leak the secret outside your account. Rotating the password would require rebuilding and redeploying the AMI, which is slow, error-prone, and leaves old instances still holding stale credentials; the secret also remains recoverable from the AMI even after you stop using it.

Go deeper

Related to this question