Designing for the four domains
Domain 1: Designing secure architectures
Domain 1 is worth 30% of the scored content — the largest domain. This chapter turns its three task statements into patterns you can apply to any scenario. Each item links back to the detailed chapter.
1.1 Design secure access to AWS resources
| Requirement | Pattern |
|---|---|
| Protect the root user | MFA, no access keys, use only for root-only tasks |
| People need AWS access | IAM Identity Center with groups and permission sets; federate with the corporate IdP |
| Applications need AWS access | IAM roles (instance profiles, task roles, execution roles) — never stored keys |
| Least privilege | Scoped customer-managed policies, conditions, Access Analyzer, last-accessed data |
| Cap what delegated admins can grant | Permissions boundaries |
| Govern many accounts | Organizations + SCPs, Control Tower landing zone |
| Another account needs access | Cross-account role (with external ID for third parties) or resource-based policy |
| Use existing Active Directory | IAM Identity Center with AD, AD Connector or Managed Microsoft AD |
| App users sign in | Cognito user pools (+ identity pools for AWS credentials) |
1.2 Design secure workloads and applications
| Requirement | Pattern |
|---|---|
| Segment tiers | Public subnets only for load balancers/NAT; app and data tiers in private subnets |
| Control traffic | Security groups referencing each other; NACLs for explicit subnet-level denies |
| Outbound internet from private subnets | NAT gateway (per AZ for HA) |
| Private access to AWS services | VPC endpoints (gateway for S3/DynamoDB; interface for others) |
| Admin access | Session Manager, no open SSH |
| Web attacks (SQLi, XSS), bots | AWS WAF on CloudFront/ALB/API Gateway |
| DDoS | Shield (Advanced for SLAs, response team, cost protection) + CloudFront |
| Threat detection | GuardDuty; vulnerabilities → Inspector; findings → Security Hub |
| Secrets in apps | Secrets Manager (rotation) / Parameter Store |
| Connect to on-premises securely | Site-to-Site VPN; Direct Connect + VPN/MACsec for encryption |
| Centrally enforce firewall rules across accounts | Firewall Manager |
| Inspect/filter VPC traffic and outbound domains | Network Firewall |
1.3 Determine appropriate data security controls
| Requirement | Pattern |
|---|---|
| Encrypt at rest with company-controlled keys | KMS customer managed keys (key policies, rotation, audit in CloudTrail) |
| Single-tenant HSM, exclusive control | CloudHSM |
| Encrypt in transit | TLS everywhere; ACM certificates (auto-renew) |
| Enforce encryption | Default encryption + bucket policies (aws:SecureTransport, required KMS key); EBS encryption by default |
| Find sensitive data | Macie |
| Immutable retention | S3 Object Lock (compliance mode), Backup Vault Lock, Glacier Vault Lock |
| Backups and replication | AWS Backup (cross-Region/account copies), S3 replication, RDS cross-Region snapshots |
| Lifecycle and retention | S3 lifecycle rules, TTL, retention policies |
| Compliance evidence | AWS Artifact (AWS reports), Audit Manager, Config rules, CloudTrail |
| Rotate keys/certificates | KMS automatic rotation; ACM managed renewal; Secrets Manager rotation |
A secure reference architecture
Route 53 → CloudFront (WAF, Shield, OAC to S3 for static) → ALB (WAF, TLS via ACM) [public subnets]
→ ECS/EC2 app tier [private subnets, SG from ALB only, IAM task roles, Secrets Manager]
→ Aurora [isolated subnets, SG from app only, KMS encryption, TLS, IAM auth / RDS Proxy]
→ S3 via gateway endpoint (bucket policy requires the endpoint, SSE-KMS)
Governance: Organizations + SCPs, Control Tower, CloudTrail org trail, Config rules, GuardDuty, Security Hub
Key idea
When torn between two secure answers, prefer: temporary credentials over long-lived keys, private connectivity over public, managed security services over self-built, and preventive controls (SCPs, policies) plus detective controls (Config, GuardDuty).