Design Secure Architectures Study Guide — SAA-C03

Design Secure Architectures

This domain accounts for 30% of the AWS SAA-C03 exam — the single largest domain. It tests your ability to select the correct AWS security service or configuration for a given architectural requirement, distinguish between similarly named services with overlapping functions, and apply the principle of least privilege across IAM, network, data, and application layers. Expect scenario-based questions where one or two options are plausible but only one matches the exact requirement.

IAM Users, Roles, Policies, and Permission Boundaries

Core Concepts

IAM users are long-term identities with static credentials. IAM roles are temporary identities assumed by principals (users, services, external accounts). Exam questions that involve EC2 accessing S3, Lambda reading DynamoDB, or cross-account access always point to roles, never users with access keys.

Policy evaluation logic (must memorize):

1. Explicit Deny always wins.
2. If no explicit Allow exists → implicit Deny.
3. SCPs (see next section) act as a ceiling on effective permissions.
4. Permission boundaries set a maximum allowed scope for a principal — they do not grant permissions on their own.
5. Session policies further restrict what a role session can do.

Inline policies are embedded in one principal; managed policies (AWS-managed or customer-managed) are reusable. Prefer customer-managed policies when fine-grained reuse is needed.

Common Traps

• Permission boundaries do not grant access — a boundary of S3:* + an identity policy of EC2:* = no effective permissions for either service.
• Access keys on an IAM role do not exist — roles produce temporary credentials via STS.
• iam:PassRole is required whenever a service (e.g., CodePipeline) needs to pass a role to another service (e.g., EC2). Missing this is a common distractor.
• The exam treats "least privilege" as always requiring a role over a user for compute services.

Worked Scenario

Requirement: A developer must be able to create IAM roles for Lambda functions, but must not be able to create roles with more permissions than the developer themselves has.

Reasoning: Attach a permission boundary to any role the developer creates. Without this, the developer could escalate privileges by creating an over-privileged role and then assuming it. The boundary enforces a ceiling equal to the developer's own permissions.

AWS Organizations, SCPs, and Multi-Account Strategies

Core Concepts

AWS Organizations groups accounts into a hierarchy: Management account (root) → Organizational Units (OUs) → Member accounts. The management account is never restricted by SCPs.

Service Control Policies (SCPs) are allow/deny lists attached to OUs or accounts. They restrict what IAM principals in that account can do, even if the IAM policy grants it. They do not affect the management account or service-linked roles.

Key multi-account patterns:

AWS Control Tower automates multi-account setup, enforces guardrails (preventive = SCPs, detective = Config rules), and manages the landing zone.

Resource Access Manager (RAM) shares resources (e.g., VPC subnets, Transit Gateway, Route 53 Resolver rules) across accounts within an organization without needing account-level cross-account policies for every resource.

Common Traps

• SCPs must have both an Allow policy and no Deny for an action to be permitted. A common trap: an SCP with Allow * and a member IAM Deny — the deny wins at the IAM level.
• SCPs do not grant permissions — even Allow * in an SCP requires an IAM policy to actually permit access.
• Management account is exempt from SCPs — never place workloads there.
• RAM does not copy resources — it shares the original resource. A shared subnet is still owned by the source account.