Can You Answer These 5 SAA-C03 Questions on Design Secure Architectures?

Practice Design Secure Architectures for the AWS Solutions Architect – Associate (SAA-C03) exam with the 5 questions below. About 30% of the exam comes from this domain. Every option is explained, so a wrong pick still teaches something.

SAA-C03 Design Secure Architectures: 5 practice questions

AWS Solutions Architect – Associate (SAA-C03) · Design Secure Architectures · 5 questions with answers and explanations

🧭 What these questions look for

Questions in this domain rarely ask you to define a service. They describe a requirement (a new policy, a group of users, a kind of data) and ask which control meets it with the least exposure. Three threads come up again and again: who gets access and how, what traffic may reach or leave the workload, and how the data itself is protected.

Three things to look for

• Find the constraint that decides the answer, such as "without embedding credentials" or "never more than an approved ceiling". It usually rules out options before the service names matter.
• Keep detection and enforcement apart: a service that finds a problem is not the one that blocks it.
• Check whether a setting can be changed later. Some protections, such as encryption at rest on an EFS file system, are fixed when the resource is created.

📊 About this set

Exam: SAA-C03 · 65 questions · 130 minutes · passing score 720 · the largest of 4 domains
This set: 3 advanced, 2 applied · 4 scenario, 1 concept check · 1 with more than one answer
Topics: Amazon EFS, AWS DataSync, AWS Network Firewall, Amazon S3, Amazon Macie, AWS resource tags, AWS IAM

Question 1 of 5

A company has an Amazon EFS file system, created without encryption, that stores customer documents for Linux application servers. A new policy requires encryption of the data at rest and in transit. Which TWO actions meet the policy? (Select TWO)

ACreate a new file system with encryption at rest turned on, and copy the data into it by using AWS DataSync
BEdit the existing file system and turn on encryption at rest, so that EFS re-encrypts the stored data in the background
CRestrict the mount target security group to accept NFS traffic on port 2049 only from the application servers' security group
DMove the documents to an Amazon EBS volume that is attached to a single instance, and take snapshots of the volume every day
EMount the file system with the amazon-efs-utils mount helper and the tls option, so that NFS traffic is encrypted with TLS
Show answer

✅ Answer: A, E

Difficulty: applied · Topic: Amazon EFS, AWS DataSync

EFS encryption
• At rest: encryption is chosen when the file system is created and cannot be turned on for an existing file system. To encrypt existing data, create a new encrypted file system and copy data across, for example with AWS DataSync or AWS Backup restore.
• In transit: NFS traffic is not encrypted by default. The EFS mount helper (amazon-efs-utils) with -o tls sets up a TLS tunnel. A file system policy with a condition on aws:SecureTransport can deny connections that do not use TLS.

Why each option works or fails
• ✓ A. New encrypted file system with DataSync (correct): this is the only way to get encryption at rest for these documents, and DataSync preserves file metadata during the copy.
• ✗ B. Editing the existing file system: encryption at rest can only be enabled at creation, so there is no setting to change on the existing file system.
• ✗ C. Security group restriction: this limits who can connect but does not encrypt the traffic, so it satisfies neither part of the policy.
• ✗ D. EBS volume: EBS is block storage that normally attaches to one instance (Multi-Attach is limited to certain io1 and io2 volumes in one Availability Zone), so it does not replace a shared file system, and the option does not turn on encryption.
• ✓ E. Mount helper with TLS (correct): it encrypts NFS traffic between the servers and EFS, meeting the in-transit part.

🎯 Key idea: EFS at-rest encryption is fixed at creation (migrate to a new file system); in-transit encryption uses the mount helper with TLS or a policy on aws:SecureTransport.

Question 2 of 5

A company wants to inspect and filter traffic leaving its VPC to the internet, allowing only approved domains. Which service fits?

AAmazon GuardDuty with default settings
BAWS Network Firewall with domain allow lists
CSecurity groups with outbound rules by IP
DAn internet gateway with a route table only
Show answer

✅ Answer: B

Difficulty: applied · Topic: AWS Network Firewall

Controlling egress by domain name
Security groups and NACLs filter by IP, port and protocol. Many internet destinations sit behind changing IP addresses, so domain-based egress control needs a firewall that reads the traffic.
AWS Network Firewall is a managed, stateful firewall deployed in a VPC with firewall endpoints in dedicated subnets. Route tables send traffic through those endpoints.
• A domain list rule group can allow or deny domains such as .amazonaws.com or updates.example.com.
• For HTTPS it matches the TLS SNI, and for HTTP the Host header.
• A default action drops anything not on the allow list.
Example: private subnets route 0.0.0.0/0 to the firewall endpoint, the firewall allows only approved domains, then forwards to a NAT gateway and the internet gateway.

Why each option works or fails
• ✗ A. Amazon GuardDuty: it analyzes logs to detect threats and produces findings, but it does not sit in the traffic path and cannot block or filter connections.
• ✓ B. AWS Network Firewall with domain allow lists (correct): it inspects outbound traffic statefully and allows only approved domain names, dropping everything else.
• ✗ C. Security groups with outbound IP rules: they filter only by IP and port and cannot match domain names, and service IP addresses change often.
• ✗ D. Internet gateway with a route table only: routing sends traffic to the internet but performs no inspection or filtering of destinations.

🎯 Key idea: Domain-based egress filtering needs an inline firewall such as Network Firewall; security groups work on IPs and GuardDuty only detects.

Question 3 of 5

A mobile app must let users upload photos directly to S3 without routing files through backend servers, and without embedding AWS credentials in the app. Which solution fits?

AShare the root account password with the mobile development team
BEmbed an IAM user's access keys in the mobile application package
CGenerate short-lived presigned URLs from the backend for each upload
DMake the bucket publicly writable so any user can upload directly
Show answer

✅ Answer: C

Difficulty: advanced · Topic: Amazon S3

What an S3 presigned URL is
A presigned URL is a normal S3 URL that carries a signature created with the backend's credentials. Anyone holding the URL can perform exactly that one operation (for example PUT of one object key) until the URL expires.
• The backend, which already has an IAM role, calls the SDK to generate the URL with a short expiry such as 5 minutes.
• The mobile app uploads the file directly to S3 with a plain HTTPS request. The file never passes through the backend servers.
• The app never holds AWS credentials; the URL only works for the object key and method it was signed for.

Example
The user taps "upload". The app asks the API for an upload URL; the backend checks the user is signed in, signs PUT photos/user123/abc.jpg valid for 300 seconds, and returns it. The app sends the photo to that URL.

Why each option works or fails
• ✗ A. Sharing the root password: gives a whole team full, unrestricted control of the account and still does not provide a credential-free upload path for end users.
• ✗ B. IAM user keys in the app package: anyone can extract keys from a mobile app binary, and those long-term keys work for any request the IAM user is allowed to make until someone revokes them.
• ✓ C. Short-lived presigned URLs (correct): direct client-to-S3 uploads, no credentials inside the app, and each URL is limited to one object and a short time window.
• ✗ D. Publicly writable bucket: anyone on the internet can upload or overwrite objects, which invites abuse, malware hosting and unexpected storage costs.

🎯 Key idea: Let clients upload straight to S3 with short-lived presigned URLs issued by the backend instead of giving the client credentials or opening the bucket.

Question 4 of 5

A company wants encryption, access, and retention controls applied automatically according to how sensitive each dataset is. What must it do FIRST, and how can AWS help?

AMove all data to the cheapest storage class, then classify what remains
BEncrypt everything with one KMS key, then decide on classification later
CClassify and tag data by sensitivity; Macie helps find it
DApply the strictest controls to all data
Show answer

✅ Answer: C

Difficulty: advanced · Topic: Amazon Macie, AWS resource tags

Classification comes first
Controls such as encryption keys, access rules and retention periods should depend on how sensitive data is. Before automation can apply them, each dataset needs a known classification, for example public, internal, confidential or restricted.

Tags make classification actionable
Once data is labeled with tags like classification=confidential:
• IAM and bucket policies can use tag conditions to limit access;
• AWS Backup plans and S3 Lifecycle rules can select resources or objects by tag to apply retention;
• automation can check that confidential data uses a specific KMS key.

Where Amazon Macie helps
Macie scans S3 buckets with machine learning and pattern matching to find sensitive data such as personal information and financial data, so you can classify data nobody has labeled yet.
Example: Macie flags a bucket of CSV files containing credit card numbers; the team tags it restricted and policies then apply.

Why each option works or fails
• ✗ A. Cheapest storage first: moving data before knowing its sensitivity can break retention or access requirements, and it does not tell you which controls each dataset needs.
• ✗ B. One KMS key for everything: encryption is useful but a single key gives no per-sensitivity access separation, and postponing classification skips the step that drives all other controls.
• ✓ C. Classify and tag, with Macie (correct): classification is the input that decides which controls apply, tags let policies act on it automatically, and Macie discovers sensitive data in S3 to speed classification.
• ✗ D. Strictest controls everywhere: applying maximum controls to all data is expensive and blocks legitimate use, and it still avoids deciding what is actually sensitive.

🎯 Key idea: Automatic sensitivity-based controls start with classifying and tagging data; Macie helps find sensitive data in S3.

Question 5 of 5

A platform team wants application developers to create their own IAM roles for new microservices without waiting for a central team. Developers must never be able to create a role that has more permissions than an approved ceiling, even if they write an administrator policy for it. Which design enforces this?

AGive developers an identity policy that allows iam:CreateRole on all resources and rely on an IAM Access Analyzer external access analyzer to alert on any overly broad role
BGive developers an identity policy that allows iam:CreateRole only for role names that start with the team prefix, and review each new role manually once per week
CAttach a service control policy to the developers' OU that lists the approved AWS services, and let developers create roles with any policy they like inside the OU
DGive developers an identity policy that allows iam:CreateRole only when the request sets the approved permissions boundary through the iam:PermissionsBoundary condition key
Show answer

✅ Answer: D

Difficulty: advanced · Topic: AWS IAM

What a permissions boundary does
A permissions boundary is a managed policy attached to an IAM user or role as an upper limit. The effective permissions of that identity are the intersection of its identity policies and its boundary, so a role with an AdministratorAccess policy and a narrow boundary can still do only what the boundary allows.

Making the boundary mandatory
Delegating role creation is safe only if the delegated permission itself forces the boundary. The developer's policy allows iam:CreateRole (and iam:AttachRolePolicy, iam:PutRolePolicy) with a Condition that iam:PermissionsBoundary equals the ARN of the approved boundary policy. A request that omits the boundary or names a different one is not allowed. A second statement denies iam:DeletePolicy and iam:DeleteRolePermissionsBoundary so the boundary cannot be removed later.

Why each option works or fails
• ✗ A. Access Analyzer alerts: an external access analyzer reports resources shared outside the account or organization. It detects nothing about how powerful a role is inside the account, and an alert arrives after the role already exists.
• ✗ B. Name prefix and manual review: a naming rule limits which roles can be created, not what they can do, and a weekly review leaves a window in which an over-privileged role is already in use.
• ✗ C. Service control policy: an SCP limits which actions accounts can use, but it is an account-wide guardrail. It cannot cap one role differently from another, and inside the allowed services a developer could still create a role with full access to them.
• ✓ D. Condition on the boundary (correct): because creation is allowed only when the approved boundary is attached, every developer-created role is capped at that ceiling no matter which policies are attached, and no central team needs to approve each role.

🎯 Key idea: To delegate role creation safely, allow iam:CreateRole only with the iam:PermissionsBoundary condition set to the approved boundary.

🔗 Related practice sets

• All SAA-C03 practice sets
• Every exam on this blog

📚 More SAA-C03 practice

More SAA-C03 questions: https://hyunhp.github.io/cert-bank/#exam=SAA-C03
Study guide: https://hyunhp.github.io/cert-bank/study.html#exam=SAA-C03

These are original practice questions, not real exam questions, and cert-bank is not affiliated with any certification vendor.

Original practice questions written for this blog, not exam dumps.

Comments