AWS SAA-C03 Security Design Guide: How to Think About Secure Workloads and Applications
Why This Domain Matters for SAA-C03
SAA-C03 does not reward security trivia. What it does reward is architectural judgment. Basically, you’re picking the design that reduces risk, keeps the blast radius tight, leaves a solid audit trail, and doesn’t create a bunch of unnecessary ops pain.
That is why security questions often sound simple but are really asking you to compare patterns: roles vs users, VPC endpoints vs NAT, ACM vs self-managed certificates, Session Manager vs bastions, SSE-KMS vs basic service-managed encryption, or Organizations guardrails vs per-account cleanup.
Start with the shared responsibility model, but apply it by service type. With EC2, you’re still responsible for the guest OS, patching, host-level firewall rules, using IAM roles properly, and securing the application configuration. AWS gives you the building block, but you still own a lot of the security posture.
With managed services like RDS, AWS takes on more of the underlying platform work, but you’re still responsible for the important controls: network exposure, authentication, encryption settings, logging, and who can actually touch the data. And with Lambda and S3, AWS manages even more of the infrastructure, but you’re still responsible for identity, policies, data protection, and secure configuration. So, yeah, the operational burden goes down, but customer responsibility doesn’t magically disappear. The exam likes candidates who understand that managed services reduce operational burden, not customer responsibility.
My exam lens is simple: who needs access, should the path be private, do I need temporary credentials, what encrypts the data, what creates an audit trail, and what centralizes governance? If you answer those five questions, most “secure design” scenarios become much easier.
Identity and Access: Temporary Credentials Win
For workloads, the secure default is almost always IAM roles, not IAM users. IAM users are long-term identities, and honestly, I only want them for narrow legacy cases or specific human users where there’s no better option. I definitely don’t want them powering applications, EC2 instances, containers, or Lambda functions.
Workloads should use temporary credentials through instance profiles, task roles, Lambda execution roles, or federated role assumption through AWS STS.
For human access across multiple accounts, prefer IAM Identity Center. It gives you centralized workforce access, permission sets, account assignments, and integration with an external identity source. Honestly, that’s the kind of clean, auditable setup the exam usually wants you to pick.
On the exam, “employees need access to multiple AWS accounts with SSO” points to Identity Center, not local IAM users in every account.
Cross-account access usually means AssumeRole. That requires two things: a trust policy on the target role and permission for the source principal to call sts:AssumeRole. For third-party access, look for external ID to reduce confused-deputy risk.
One area candidates often miss is policy evaluation. AWS is basically asking: is there an explicit deny anywhere, and is there an allow coming from the relevant policy types?
Identity policies, resource policies, session policies, permission boundaries, and SCPs can all affect the answer. The key exam rule is this: explicit deny wins, and SCPs or permission boundaries do not grant permissions; they only limit what could be allowed.
That matters in troubleshooting. If a role appears to have s3:GetObject but access still fails, check for an SCP deny, a permission boundary, a bucket policy deny, a missing KMS permission, or a session policy restriction. SAA-C03 loves this style of layered-control question.
Here is a compact least-privilege example for direct object reads from one prefix:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::example-data-bucket/reports/*" } ] }
If the application must also list objects, add s3:ListBucket on the bucket ARN with a prefix condition. That small distinction is both technically important and exam-relevant.
High-yield identity clues: workforce access → IAM Identity Center; workload access → IAM role; cross-account → AssumeRole or resource policy; org-wide preventive guardrail → SCP; delegated IAM creation with limits → permission boundary.
Data Protection: Encryption, KMS, and Secrets
For SAA-C03, treat data protection as four separate decisions: encryption at rest, encryption in transit, key ownership, and secret lifecycle.
AWS KMS manages cryptographic keys used for encryption operations and integrates with many AWS services through envelope encryption. The exam distinction is not just “use KMS or not,” but which key ownership model fits the requirement. There are AWS owned keys managed entirely by AWS, AWS managed keys created in your account for a service, and customer managed keys that you control with your own key policy, rotation settings, grants, deletion window, and cross-account permissions. If the scenario mentions compliance, separation of duties, auditability, or control over who can decrypt, customer managed keys are usually the better answer.
For S3 specifically, remember the modern baseline: Amazon S3 automatically encrypts new objects at rest with SSE-S3 by default. So the exam tradeoff is no longer “encrypted or not” as much as “do you need stronger governance?” Choose SSE-KMS when you need KMS key policies, auditability, cross-account key control, or encryption requirements tied to a customer managed key. Also remember the cost and scaling angle: SSE-KMS can add KMS request cost and quota considerations for very high request rates.
For secrets, use AWS Secrets Manager when rotation matters, especially for database credentials. Use Systems Manager Parameter Store SecureString for simpler configuration secrets when native rotation is not the main need. Parameter Store SecureString still uses KMS, but Secrets Manager is the stronger lifecycle tool. Lambda environment variables are encrypted at rest by default, but they are not the best answer when the question emphasizes rotation, centralized management, or secret retrieval at runtime.
For TLS certificates, use ACM where supported. It reduces certificate lifecycle risk dramatically. One exam nuance worth remembering: CloudFront uses ACM certificates in us-east-1.
A practical S3 enforcement pattern is to combine default encryption, Block Public Access, and policy enforcement such as denying non-TLS requests. If object retention or immutability is required, use S3 Object Lock, but remember the prerequisite: versioning must be enabled and Object Lock must be configured on the bucket.
Network Isolation and Private Access
A subnet is effectively public when its route table sends internet-bound traffic to an Internet Gateway and resources have public IP addresses or Elastic IPs as needed. Private subnets do not provide direct inbound internet reachability, though they may still have outbound internet access through a NAT Gateway. That distinction matters because the exam often hides the real issue inside one phrase like “must not be publicly accessible.”
Use security groups as the primary traffic filter. Security groups are stateful, and they can reference other security groups, which makes tier-to-tier design really clean. For example, the ALB security group allows 443 from the internet, the app security group allows traffic only from the ALB security group, and the database security group allows traffic only from the app security group.
NACLs are stateless subnet-level controls and are usually a secondary guardrail, not the first answer.
For private access to AWS services, prefer VPC endpoints over NAT when possible. Gateway endpoints are available only for S3 and DynamoDB. Other endpoint patterns are interface endpoints powered by PrivateLink. This is one of the highest-value SAA-C03 tradeoffs: if private EC2 instances need S3 access, a gateway endpoint is usually more secure and often cheaper than sending traffic through a NAT Gateway.
Be precise about NAT. A NAT Gateway enables outbound internet access for private subnets, but it does not expose those private instances to unsolicited inbound internet traffic. The reason endpoints are preferred for AWS service access is not that NAT makes instances publicly reachable; it is that endpoints keep supported service traffic on private paths and avoid unnecessary internet-routable egress patterns and NAT cost.
Session Manager is the preferred administrative access pattern for EC2 when the goal is to avoid inbound SSH or RDP. Once the prerequisites are in place—SSM Agent, an IAM instance profile, and connectivity to Systems Manager endpoints through internet/NAT or interface VPC endpoints like SSM, EC2Messages, and SSMMessages—it usually cuts operational overhead compared with bastions.
If Session Manager fails, the likely checks are IAM role permissions, agent status, endpoint reachability, and instance network path.
One more network nuance that shows up in serverless designs: if you attach Lambda to a VPC so it can reach private resources, it may need NAT or VPC endpoints to reach public AWS APIs or the internet. “Put Lambda in a VPC” is not automatically free of networking consequences.
Application Edge Security and Service Baselines
For public web applications, the common secure pattern is CloudFront or ALB at the edge, ACM for TLS, WAF for layer-7 filtering, and private backends. ALB is the standard answer for regional web apps, while CloudFront often turns into the better pattern for global delivery, CDN caching, origin protection, and centralized WAF attachment.
If the application is internet-facing and the answer exposes EC2 instances directly, that is usually the distractor.
AWS WAF is for request filtering. Think managed rule groups, SQL injection and XSS protection, and rate limiting. AWS Shield Standard is included for DDoS protection. Shield Advanced adds stronger visibility and response features, cost protection for scaling charges caused by DDoS events, and access to the DDoS Response Team. Firewall Manager centralizes policies across accounts for WAF, Shield Advanced, security groups, and related controls.
For APIs, match authentication to the caller. IAM authorization fits AWS principals. Cognito user pools fit end-user sign-in. Identity pools are for brokering temporary AWS credentials to users. For API Gateway, remember that auth options differ somewhat between REST APIs and HTTP APIs; HTTP APIs commonly use JWT authorizers, while custom logic may use Lambda authorizers.
Service baselines matter too. For S3, combine account-level and bucket-level Block Public Access, use Object Ownership with ACLs disabled where possible, and use bucket policies or Access Points for controlled sharing. For EC2, enforce IMDSv2 through instance metadata options, prefer instance profiles, encrypt EBS by default, and avoid open admin ports. For RDS/Aurora, use DB subnet groups across private subnets, keep public accessibility disabled unless explicitly required, enable encryption at rest, and enable and enforce TLS where supported by the engine and application. IAM database authentication is useful, but only for supported engines and scenarios, so don’t try to force it into every design just because it sounds secure.
For EFS, remember encryption at rest, encryption in transit, and access points as security-relevant controls.
One compact S3 bucket policy pattern to know is restricting access through a VPC endpoint:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonVPCEAccess", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": ["arn:aws:s3:::example-data-bucket", "arn:aws:s3:::example-data-bucket/*"], "Condition": { "StringNotEquals": { "aws:SourceVpce": "vpce-1234567890abcdef0" } } } ] }
That is a strong exam pattern, but in real environments it can block console access or some AWS service access unless you intentionally add exceptions.
Monitoring, Governance, and Multi-Account Security
Strong security designs combine preventive, detective, and sometimes responsive controls. Preventive examples include SCPs, security groups, bucket policies, and Block Public Access.
Detective examples include CloudTrail, Config, GuardDuty, Security Hub, VPC Flow Logs, and access logs. Responsive examples: EventBridge plus Lambda or Systems Manager Automation to remediate noncompliant changes.
CloudTrail is your API audit trail, and in organizations you should know the pattern of an organization trail writing to a centralized log archive account. Add encryption, log file validation, and restrictive bucket policies so the trail is actually useful when you need it.
But do not assume a log archive account is automatically immutable; immutability requires controls such as S3 Object Lock, versioning, separate-account ownership, and tightly restricted administration.
AWS Config answers what changed and whether resources are compliant. GuardDuty provides threat detection by analyzing sources such as CloudTrail events, VPC Flow Logs, and DNS logs. Security Hub aggregates and normalizes findings and can run security standards checks. Amazon Inspector performs automated vulnerability management for supported EC2 instances, ECR container images, and Lambda functions. In multi-account environments, look for delegated administrator patterns so a central security account can manage GuardDuty, Security Hub, and Inspector without broad admin in every account.
For enterprise AWS, AWS Organizations is the backbone. Separate accounts for production, non-production, security, and log archive help reduce blast radius and make governance a whole lot simpler.
Use SCPs as ceilings, not grants—that’s a small phrase, but it’s a really important one. Also lock down the root user with MFA and use it only for tasks that truly require root.
Scenarios, Troubleshooting, and Exam Decisions
Scenario 1: Private EC2 needs S3 and Secrets Manager access without internet. Best design: use an S3 gateway endpoint plus interface endpoints for Secrets Manager and Systems Manager if needed.
Wrong distractor: NAT Gateway alone, because the requirement is private AWS service access, not generic internet egress.
Scenario 2: Public three-tier web app with minimal admin exposure. Best design: ALB with ACM, WAF, an app tier in private subnets, non-public RDS in DB subnet groups, security group references between tiers, and Session Manager for administration.
Wrong distractor: public EC2 app servers with SSH open to admins.
Scenario 3: Regulated S3 data lake. Best design: account-level Block Public Access, bucket policy restrictions, Object Ownership with ACLs disabled, SSE-KMS with a customer managed key, CloudTrail data events for object-level audit, and Object Lock if retention is required.
tention is required. Wrong distractor: basic public bucket controls without KMS governance or audit depth.
When a design fails, diagnose in layers. AccessDenied usually means IAM policy, role trust, SCP, permission boundary, bucket policy, or KMS key policy. Cannot connect to private resource usually means route tables, security groups, NACLs, endpoint configuration, or DNS. Session Manager fails usually means missing instance profile permissions, no SSM Agent, or no path to SSM endpoints. KMS decrypt fails often means the caller has access to the secret but not to the KMS key.
My final exam cheat sheet is this:
Keyword decoder: temporary credentials → IAM role/STS; workforce SSO → IAM Identity Center; private S3 access → gateway endpoint; secret rotation → Secrets Manager; no inbound admin ports → Session Manager; compliance and key control → customer managed KMS key; prevent account-level risky actions → SCP; object-level S3 audit → CloudTrail data events.
If an answer uses long-term access keys for workloads, public databases, wide-open admin ports, self-managed certificates where ACM works, or per-account IAM users instead of federation, it is usually the wrong architecture. The best SAA-C03 answers are secure by default, private where possible, temporary by design, and auditable when something goes wrong.