Courseiva

SAA-C03 Design Secure Architectures Practice Question

A company is designing a secure architecture for an internal microservices application running on Amazon ECS with the Fargate launch type. The security team wants each microservice to have its own fine-grained permissions to access specific AWS resources, and wants to avoid storing long-term AWS credentials in the container images or task definitions. The company also wants to encrypt data in transit between services. (Choose two.)

⚠ Common exam trap

The trap here is assuming that injecting secrets as environment variables or using PrivateLink alone provides the same security as task roles and mutual TLS.

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

✓

Implement mutual TLS between microservices using AWS App Mesh with certificate management through AWS Certificate Manager Private CA.

ECS task IAM roles provide each microservice with temporary, scoped credentials without storing secrets in images or task definitions, meeting the fine-grained permission and credential-hygiene requirements. AWS App Mesh with mutual TLS encrypts and authenticates service-to-service traffic using certificates from ACM Private CA, satisfying the in-transit encryption requirement. Together they form a least-privilege, encrypted microservices architecture.

Answer analysis

Option-by-option breakdown

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

  • ✗

    Enable AWS PrivateLink for communication between microservices and use TLS termination at the Network Load Balancer.

    Why it's wrong here

    AWS PrivateLink provides private connectivity to services, but it does not by itself encrypt data in transit between ECS tasks. TLS termination at a load balancer protects traffic between the client and the load balancer, not necessarily between microservices. The requirement is to encrypt service-to-service traffic, which is better addressed with mutual TLS or a service mesh rather than PrivateLink alone.

  • ✗

    Attach an IAM user access key to each container through a mounted Amazon EFS volume.

    Why it's wrong here

    Mounting IAM user access keys via EFS introduces long-term credentials that must be rotated and protected, violating the requirement to avoid stored credentials. It also grants broad identity-based permissions not tied to the task lifecycle. ECS task roles are the supported mechanism for providing temporary credentials to containers, so this approach is insecure and operationally burdensome.

  • ✗

    Store AWS credentials in AWS Secrets Manager and inject them as environment variables in the task definition.

    Why it's wrong here

    Injecting long-term credentials as environment variables still places secrets in the task definition and container environment, which is exactly what the company wants to avoid. It also requires rotation logic and broadens the blast radius if the task is compromised. ECS task IAM roles provide temporary credentials natively, making this approach unnecessary and less secure for the stated requirements.

  • ✓

    Implement mutual TLS between microservices using AWS App Mesh with certificate management through AWS Certificate Manager Private CA.

    Why this is correct

    AWS App Mesh provides service-to-service communication control and supports mutual TLS, where both sides present certificates to authenticate and encrypt traffic. Integrating with ACM Private CA allows the mesh to issue and rotate certificates automatically. This satisfies the requirement to encrypt data in transit between microservices and adds identity verification, which is a strong security control for internal microservices.

  • ✓

    Use an ECS task IAM role for each microservice with a least-privilege policy attached.

    Why this is correct

    ECS task IAM roles provide temporary credentials to containers through the task metadata endpoint. Each task can have a distinct role with policies scoped to only the AWS resources that microservice needs. This eliminates the need to embed long-term credentials in images or task definitions and enforces least privilege at the task level, directly satisfying the fine-grained permissions and no-stored-credentials requirements.

About these practice questions

Courseiva writes every SAA-C03 question from scratch — 935 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint

This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.