Design Secure Architectures

Concepts Covered

• SAA-C03 secure architecture domain
• Secure access to AWS resources
• Secure workloads and applications
• Data security controls
• IAM policy evaluation
• Multi-account guardrails
• VPC segmentation
• KMS key policies
• S3 access controls
• Security service selection

1. Domain Mental Model

The secure architecture domain is not a checklist of security products. It is a reasoning test about boundaries.

The basic question is:

who can access what, through which path, using which key, under which guardrails?

AWS security questions often combine identity, networking, encryption, account structure, and logging. A private subnet is not enough if the instance role can read every secret. A bucket policy is not enough if KMS denies decrypt. A WAF rule is not enough if the database is public. An SCP is not enough if it is expected to grant permissions.

For SAA-C03, secure architecture means designing access intentionally across humans, workloads, AWS services, accounts, networks, and data stores.

2. Official Task Map

AWS groups this domain into three task areas:

• secure access to AWS resources
• secure workloads and applications
• appropriate data security controls

The official weighting is 30 percent of scored content, making this the largest SAA-C03 domain.

In Arcflow terms, that maps to five clusters:

• identity and authorization
• multi-account governance
• network segmentation and private access
• encryption and key management
• threat protection, detection, and auditability

Do not study these as isolated services. Study them as layers in one request path.

3. What AWS Is Testing

AWS is testing whether you understand shared responsibility and least privilege in actual architecture.

For access questions, expect IAM users, roles, federated access, IAM Identity Center, STS, role switching, cross-account access, resource policies, SCPs, permission boundaries, and explicit deny behavior.

For workload questions, expect public versus private subnets, security groups, NACLs, route tables, NAT gateways, VPC endpoints, VPN, Direct Connect, WAF, Shield, and service endpoints.

For data security questions, expect S3 policies, Block Public Access, access points, KMS, TLS, ACM, Secrets Manager, Parameter Store, backups, replication, lifecycle controls, and data classification.

The exam is not asking whether you know the name of every security service. It is asking whether you can place the right control at the right boundary.

4. Service And Concept Clusters

Start with IAM:

• IAM Foundations
• IAM Users vs Roles
• Identity Policies vs Resource Policies
• IAM Policy Types And Evaluation Traps

Then add account governance:

• AWS Organizations
• Service Control Policies
• AWS IAM Identity Center
• Cross-Account Access Patterns

Then add network security:

• VPC Networking Model
• Public vs Private Subnets
• Security Groups vs NACLs
• Security Groups vs NACLs vs Route Tables
• VPC Endpoints And PrivateLink

Then add data protection:

• Amazon S3
• S3 Bucket Policies vs ACLs vs Access Points
• AWS Key Management Service
• KMS Key Policies vs IAM Policies
• Secrets Manager vs Parameter Store

Finally add detection and edge protection:

• AWS WAF
• AWS Shield
• Amazon GuardDuty
• Amazon Macie
• AWS Security Hub

5. Architecture Reasoning Patterns

Use a layered trace for every secure architecture question:

principal -> identity policy -> resource policy -> network path -> data/key policy -> logs and guardrails

For human access, prefer federation or IAM Identity Center over long-lived IAM users. For workloads, prefer roles and temporary credentials over access keys. For cross-account access, draw both accounts.

For network access, decide whether the resource should be public, private behind a load balancer, reachable through a private endpoint, or reachable through hybrid connectivity.

For data access, separate storage permission from encryption key permission. S3, RDS, EBS, Secrets Manager, SQS, SNS, and CloudTrail can all involve KMS decisions.

For governance, remember that SCPs constrain member accounts but do not grant access. Control Tower and Organizations help set the baseline, but service-level security still matters.

6. High-Yield Comparisons

IAM user vs role: long-term credentials versus assumable temporary credentials.

Identity policy vs resource policy: what this identity can do versus who this resource allows.

SCP vs IAM policy: maximum permission boundary for accounts versus actual permissions for principals.

Security group vs NACL: stateful resource firewall versus stateless subnet guardrail.

NAT Gateway vs VPC endpoint: broad outbound path versus private service-specific path.

Bucket policy vs ACL vs access point: modern bucket/resource policy control versus legacy grants versus purpose-specific S3 access paths.

KMS key policy vs IAM policy: key-side trust gate versus identity-side delegation.

Secrets Manager vs Parameter Store: secret lifecycle and rotation versus hierarchical configuration and simple secure strings.

WAF vs Shield vs Network Firewall vs DNS Firewall: web-layer rules, DDoS protection, network traffic inspection, and DNS query filtering.

7. Scenario Triggers

"Avoid long-term credentials" points to roles, federation, IAM Identity Center, or STS.

"Even administrators in member accounts must be blocked" points to SCPs.

"Private application needs S3 access without NAT" points to an S3 gateway endpoint and bucket policy conditions when required.

"Block malicious domains queried by VPC workloads" points to Route 53 Resolver DNS Firewall.

"Protect an internet-facing web app from SQL injection" points to AWS WAF.

"DDoS protection for public endpoints" points to Shield and edge design.

"Find sensitive data in S3" points to Macie.

"Encrypted object access denied despite bucket permission" points to KMS.

"Central security team needs findings across accounts" points to delegated administration and Security Hub or GuardDuty organization patterns.

8. Common Traps

Do not use IAM users and access keys for workloads when roles are available.

Do not assume an IAM allow always works. Explicit denies, SCPs, permission boundaries, session policies, resource policies, endpoint policies, and KMS key policies can still block access.

Do not put a database in a public subnet for normal app access.

Do not choose NAT for private S3 access when a gateway endpoint satisfies the requirement.

Do not treat encryption as a checkbox. Key policy is part of security.

Do not choose WAF for general TCP packet inspection.

Do not assume GuardDuty prevents attacks. It detects suspicious activity.

Do not make a bucket public when a signed URL, CloudFront OAC, access point, or scoped policy fits.

9. Study Path

Study in this order:

1. Shared Responsibility Model
2. IAM Foundations
3. IAM Policy Types And Evaluation Traps
4. VPC Networking Model
5. Security Groups vs NACLs vs Route Tables
6. VPC Endpoints And PrivateLink
7. S3 Bucket Policies vs ACLs vs Access Points
8. KMS Key Policies vs IAM Policies
9. GuardDuty vs Inspector vs Macie vs Security Hub
10. Landing Zone Guardrails For Multi-Account AWS

The goal is not to memorize every security service. The goal is to trace the access path without guessing.

10. Related Topics

Review Design Resilient Architectures, Design Cost-Optimized Architectures, Secure Cross-Account CloudTrail Logging, and Centralized Security Findings And Incident Triage.

Official AWS references:

• SAA-C03 content outline
• Content Domain 1: Design Secure Architectures
• IAM policy evaluation logic