Chapter 1 of 430% of exam

Design Secure Architectures

Security is the largest domain of the SAA-C03 exam, worth roughly 30 percent, and it mirrors the Security pillar of the AWS Well-Architected Framework. Exam questions in this domain ask you to secure identities and access, protect data at rest and in transit, isolate networks, defend edge and application layers, and detect threats. The recurring skill is choosing the right service for a given security requirement and applying least privilege at every layer. This chapter walks through IAM, encryption and KMS, VPC network controls, S3 protection, edge defenses like WAF and Shield, and detection services such as GuardDuty, framing each around when you would reach for it on the exam and in practice.

Identity and Access Management (IAM)

IAM is the foundation of AWS security and governs who can perform which actions on which resources. It has four core building blocks: users represent long-lived human or programmatic identities, groups bundle permissions for sets of users, roles provide temporary credentials that any trusted principal can assume, and policies are JSON documents that grant or deny permissions. On the exam, the single most tested principle is least privilege: grant only the specific actions and resources a task requires, and nothing more. The second most tested principle is preferring roles over static access keys. When an EC2 instance, Lambda function, or ECS task needs to call AWS APIs, attach an IAM role so it receives temporary, automatically rotated credentials from the instance metadata service rather than embedding an access key that can leak and never expires. For workforce or customer identities from an external directory, use IAM Identity Center or federation with SAML or OpenID Connect so people sign in with existing credentials and assume roles, avoiding one IAM user per person. Policy evaluation follows clear logic you must know: an explicit deny always wins, otherwise an explicit allow grants access, and the default with no matching statement is an implicit deny. Distinguish identity-based policies (attached to users, groups, or roles) from resource-based policies (attached to resources such as S3 buckets, SQS queues, or KMS keys), which additionally name a principal and enable cross-account access. Service control policies in AWS Organizations set permission guardrails across accounts but never grant access on their own. Protect the root user with MFA, remove its access keys, and use it only for the handful of tasks that require it. When a question describes 'access denied' despite an allow, look for an explicit deny, a missing trust policy on a role, or an SCP boundary.

Prefer IAM roles with temporary credentials over long-lived access keys for any compute that calls AWS APIs.
Apply least privilege: grant only the exact actions and resources a task needs.
An explicit deny always overrides any allow; a missing allow is an implicit deny.
Use IAM Identity Center or SAML/OIDC federation for human sign-in instead of per-person IAM users.
Protect the root user with MFA, delete its access keys, and use it only for root-only tasks.

Data Protection and Encryption with KMS

Encrypt data at rest and in transit by default, and know the tools that make it easy. AWS Key Management Service (KMS) creates and controls encryption keys and integrates with almost every storage and database service. With AWS managed keys, encryption is automatic but you have limited control; with customer managed keys (CMKs) you own the key policy, can enable automatic annual rotation, set grants, and audit every single use through CloudTrail. Choose a customer managed key when you need control over rotation, cross-account key sharing, or the ability to disable or delete key material to render data unreadable. For extremely strict compliance requiring dedicated single-tenant hardware you control, CloudHSM is the answer rather than KMS. For data at rest, S3 offers SSE-S3 (S3-managed keys), SSE-KMS (KMS keys with audit and access control), and DSSE-KMS (dual-layer), while EBS volumes, RDS databases, DynamoDB tables, and EFS file systems all encrypt with KMS by simply enabling encryption. Note that you must enable encryption when a resource is created for services like EBS and RDS; to encrypt an existing unencrypted volume or database you create an encrypted snapshot or copy. For data in transit, enforce TLS everywhere and, on S3, add a bucket policy that denies requests where aws:SecureTransport is false, or one that requires a specific encryption header on upload. Secrets deserve special handling: never hard-code credentials. AWS Secrets Manager stores secrets encrypted with KMS and can automatically rotate database passwords and other credentials on a schedule using a Lambda rotation function. Systems Manager Parameter Store is a lower-cost choice for configuration values and secrets that do not need managed rotation. When an exam scenario stresses automatic credential rotation, pick Secrets Manager; when it stresses free hierarchical configuration storage, pick Parameter Store. In all cases, applications should fetch secrets at runtime through an IAM role rather than baking them into code or images.

Use customer managed KMS keys when you need control over rotation, key policy, cross-account use, or CloudTrail auditing.
Enable encryption at resource creation; encrypt an existing volume or database by copying to an encrypted snapshot.
Enforce TLS in transit; on S3 deny requests where aws:SecureTransport is false.
Choose Secrets Manager for automatic credential rotation; Parameter Store for low-cost config without rotation.
Use CloudHSM only when compliance mandates dedicated, single-tenant, customer-controlled hardware.

Network Security: VPC, Security Groups, and NACLs

A Virtual Private Cloud (VPC) is your isolated network in AWS, and its subnets, route tables, and gateways determine what can reach your resources. The two firewall layers you must contrast on the exam are security groups and network ACLs. Security groups operate at the instance or elastic network interface level, are stateful (return traffic is automatically allowed regardless of outbound rules), and support only allow rules. Network ACLs operate at the subnet boundary, are stateless (you must explicitly allow both request and response traffic, including ephemeral ports), and support both allow and deny rules, which makes them the right tool for blocking a specific IP address. A powerful security-group feature is referencing another security group as a source rather than a CIDR range, so a web tier can allow the app tier by group membership without hard-coding addresses, and the rule keeps working as instances scale. Design a layered topology: put internet-facing load balancers in public subnets, and place application servers and databases in private subnets with no direct inbound internet access. Private-subnet instances reach the internet for updates through a NAT gateway (managed, highly available within an AZ, scales automatically) placed in a public subnet, while inbound internet traffic arrives only through an internet gateway to public resources. For private connectivity to AWS services without traversing the internet, use VPC endpoints: gateway endpoints for S3 and DynamoDB (free, added to route tables) and interface endpoints powered by PrivateLink for most other services. To connect a VPC to on-premises networks, use Site-to-Site VPN for quick encrypted tunnels or Direct Connect for dedicated, consistent bandwidth, and Transit Gateway to hub many VPCs and on-premises connections together. When a question asks how to reach S3 privately from a private subnet without a NAT gateway, the answer is a gateway VPC endpoint. When it asks how to block a single malicious IP, the answer is a network ACL deny rule.

Security groups are stateful, instance-level, allow-only; network ACLs are stateless, subnet-level, and support deny rules.
Reference a security group as a source instead of a CIDR to keep rules valid as instances scale.
Place load balancers in public subnets and app/database tiers in private subnets; use a NAT gateway for private outbound.
Use gateway VPC endpoints for private S3/DynamoDB access and interface endpoints (PrivateLink) for other services.
Block a specific IP address with a network ACL deny rule, not a security group.

Protecting S3 and Data Stores

Amazon S3 is a frequent target of misconfiguration, so the exam probes how you keep buckets private and data safe. Start with S3 Block Public Access, which is enabled by default at the account and bucket level and overrides any public bucket policy or ACL; leave it on unless a bucket is intentionally a public website. Control access with bucket policies and IAM policies, and prefer disabling ACLs by using the Bucket Owner Enforced object-ownership setting so all access is governed by policy rather than legacy per-object ACLs. To grant a web application scoped, temporary access to specific objects, generate presigned URLs from credentials that already hold permission, rather than making objects public. When serving content through CloudFront, use Origin Access Control (OAC) so the bucket stays private and only CloudFront can read it, replacing the older Origin Access Identity. Enable versioning to preserve, retrieve, and restore every version of an object, protecting against accidental deletes and overwrites, and pair it with MFA Delete for sensitive buckets. For regulatory write-once-read-many needs, S3 Object Lock enforces retention so objects cannot be deleted or changed for a set period. Encrypt data as covered earlier and enforce encryption on upload through a bucket policy. To discover sensitive data such as personally identifiable information or credentials sitting in buckets, Amazon Macie uses machine learning to classify and alert. For visibility into who accessed what, enable S3 server access logging or, better, CloudTrail data events. Cross-account access is best granted through bucket policies naming the external principal, and cross-Region replication or same-Region replication can copy objects for compliance, latency, or resilience. When a scenario needs a private bucket served globally through a CDN, the pattern is CloudFront with OAC over a Block-Public-Access bucket; when it needs to find exposed PII, the answer is Macie.

Keep S3 Block Public Access enabled unless the bucket is deliberately a public website.
Serve private buckets through CloudFront using Origin Access Control, not public objects.
Grant temporary object access with presigned URLs rather than making objects public.
Enable versioning (and Object Lock for WORM compliance) to protect against deletion and tampering.
Use Amazon Macie to discover and classify sensitive data such as PII in S3.

Edge Defense and Threat Detection

Securing the application edge and detecting threats rounds out the domain. AWS WAF is a web application firewall that filters HTTP and HTTPS requests on CloudFront, Application Load Balancers, API Gateway, and AppSync; use it to block SQL injection and cross-site scripting, enforce rate-based rules against floods, apply managed rule groups, and allow or block by geography or IP set. AWS Shield protects against distributed denial-of-service attacks: Shield Standard is automatic and free for all customers at the network and transport layers, while Shield Advanced adds protection for larger, sophisticated attacks, 24/7 response team access, and cost-protection against scaling charges during an attack, and it pairs with WAF. AWS Firewall Manager centrally applies WAF and Shield policies across many accounts in an Organization. For threat detection, Amazon GuardDuty continuously analyzes CloudTrail, VPC Flow Logs, and DNS logs using machine learning to surface findings like compromised instances, credential exfiltration, or crypto-mining, with no agents to deploy; choose it when a scenario wants intelligent, low-effort threat detection. Amazon Inspector automatically scans EC2 instances, container images in ECR, and Lambda functions for software vulnerabilities and unintended network exposure, so choose it for vulnerability assessment. AWS Config records resource configurations and evaluates them against compliance rules over time, answering 'is this resource configured correctly and how did it change,' while AWS CloudTrail records every API call for audit and forensics, answering 'who did what and when.' AWS Security Hub aggregates findings from GuardDuty, Inspector, Macie, and Config into one prioritized view and checks against standards like the AWS Foundational Security Best Practices and CIS. On the exam, map the verb to the service: detect threats to GuardDuty, scan vulnerabilities to Inspector, filter web traffic to WAF, absorb DDoS to Shield, audit API calls to CloudTrail, and assess configuration compliance to Config.

Use AWS WAF to block SQL injection, XSS, floods, and unwanted geographies at CloudFront, ALB, or API Gateway.
Shield Standard is automatic and free; add Shield Advanced for large attacks, response team, and cost protection.
Choose GuardDuty for intelligent threat detection from logs, with no agents to deploy.
Use Amazon Inspector to scan EC2, containers, and Lambda for software vulnerabilities.
CloudTrail audits who called which API; AWS Config tracks resource configuration and compliance over time.

Keep going: the full AWS Solutions Architect Associate (SAA-C03) guide covers every section of the exam. AWS Solutions Architect Associate (SAA-C03) — Complete Study Guide (2026) — PDF + EPUB, $14.99 · 14-day refund →

Studying in order?

Practice stays free. The full AWS Solutions Architect Associate (SAA-C03) study guide is the material itself, taught start to finish — a downloadable PDF + EPUB you keep.

Get the book — $14.99
Report