A containerized service on Amazon ECS connects to a database with a password that must never be stored in plaintext or hardcoded in the image. The application reads the password at startup and occasionally reconnects later, so it needs to retrieve the current secret when needed. Which three actions should the architect take? Select three.

Store the password in a plain environment variable and update it manually during maintenance windows.

Plain environment variables are easy to expose through logs, crash dumps, or operator mistakes. Manual updates also create avoidable downtime and operational drift.

Use an IAM user access key inside the container so the database password can be embedded in code.

IAM users and embedded credentials are long-lived and difficult to control safely. They are not appropriate for ephemeral workloads that should use task roles instead.

What does this SAA-C03 question test?

Authentication checks who the user is.

What is the correct answer to this question?

The correct answer is: Store the database password in AWS Secrets Manager. — The best solution is to store the secret in Secrets Manager, retrieve it dynamically at runtime, and authorize the container through the ECS task role with least privilege. That combination avoids plaintext credential storage, supports password changes without rebuilding the container, and keeps access tightly constrained to the specific secret. It is a practical AWS-native pattern for application credential handling. Why others are wrong: Plain environment variables and IAM user credentials both violate the requirement to avoid plaintext or hardcoded secrets. They also create long-lived credential exposure that is hard to audit and rotate. The secure pattern is to use Secrets Manager plus a task role, not static credentials in the application or image.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.