Domain 1: Organizational Complexity on Album69

Amazon Route 53

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domains 1, 2, 3. Route 53 is tested heavily for routing policies, health checks, hybrid DNS, and multi-region failover. Know every routing policy and when to use it.

1. Overview

Amazon Route 53 is a highly available, scalable DNS service that also provides domain registration, health checking, and traffic routing. At the SAP-C02 level, focus on routing policies, health checks, hybrid DNS with Resolver, and multi-region architectures.

2. Routing Policies

Policy	Use Case	Key Behavior
Simple	Single resource, no health checks	Returns all values; client picks randomly
Weighted	A/B testing, gradual traffic shifts	Distributes traffic by weight (0–255)
Latency	Route to lowest-latency region	Based on AWS latency measurements, not geography
Failover	Active-passive DR	Routes to secondary when primary health check fails
Geolocation	Route by user’s geographic location	Country, continent, or default
Geoproximity	Route by proximity with bias	Requires Traffic Flow; can shift traffic with bias value
Multivalue Answer	Simple load balancing with health checks	Returns up to 8 healthy records
IP-based	Route by client IP CIDR	Route specific IP ranges to specific endpoints

Weighted Routing — Traffic Shifting

Record A: weight 90 → us-east-1 (production)
Record B: weight 10 → us-west-2 (canary)

Set weight to 0 to stop sending traffic to a record without deleting it.

AWS Config

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domains 1, 3. Config is the detective compliance engine. Know rules, conformance packs, aggregators, and remediation patterns.

1. Overview

AWS Config continuously records AWS resource configurations and evaluates them against desired rules. It provides a configuration history, change notifications, and compliance dashboards.

Problems it solves:

No visibility into what changed, when, and by whom
Manual compliance auditing across accounts
Inability to detect configuration drift from security baselines

2. Core Concepts

Concept	Description
Configuration recorder	Records resource configurations and changes
Delivery channel	Sends snapshots and change notifications to S3 and SNS
Config rule	Evaluates resource configurations against desired state
Conformance pack	Collection of Config rules deployed as a unit
Aggregator	Collects Config data from multiple accounts/regions
Remediation action	SSM Automation document triggered on non-compliance

3. Config Rules

Managed Rules (AWS-provided)

Common exam-relevant managed rules:

AWS Control Tower

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 1 (26%). Control Tower is the AWS-recommended way to set up and govern multi-account environments. Know how it relates to Organizations, SCPs, and Config.

1. Overview

AWS Control Tower automates the setup of a secure, multi-account AWS environment (landing zone) based on AWS best practices. It builds on top of AWS Organizations, AWS Config, CloudTrail, IAM Identity Center, and Service Catalog.

Problems it solves:

Manual, error-prone multi-account setup
Inconsistent security baselines across accounts
No automated guardrails for new accounts
Complex compliance tracking across accounts

2. Core Components

Landing Zone

The overall multi-account environment set up by Control Tower. Includes:

AWS Direct Connect

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 1 (26%). Direct Connect is the standard answer for dedicated, low-latency hybrid connectivity. Know connection types, VIFs, resilience patterns, and encryption.

1. Overview

AWS Direct Connect (DX) provides a dedicated private network connection from on-premises to AWS, bypassing the public internet. It offers consistent bandwidth, lower latency, and reduced data transfer costs compared to internet-based VPN.

Problems it solves:

Inconsistent internet-based connectivity to AWS
High data transfer costs over the internet
Latency-sensitive workloads requiring predictable performance
Compliance requirements for private connectivity

2. Connection Types

Type	Speed	How
Dedicated connection	1, 10, or 100 Gbps	Physical port at DX location, ordered directly from AWS
Hosted connection	50 Mbps – 10 Gbps	Ordered through an APN partner; shares partner’s port

Dedicated: longer lead time (weeks), full port, higher cost
Hosted: faster provisioning, flexible bandwidth, shared infrastructure

3. Virtual Interfaces (VIFs)

VIFs are logical connections over a DX connection:

AWS IAM

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domains 1, 2, 3. IAM is the security foundation of every AWS architecture. At the professional level, focus on cross-account patterns, federation, permission boundaries, and policy evaluation.

1. Overview

AWS Identity and Access Management (IAM) controls who can do what on which AWS resources. At the SAP-C02 level, the focus is on:

Cross-account role assumption
Identity federation (SAML, OIDC, web identity)
Permission boundaries and policy evaluation order
Least-privilege design at scale
Integration with Organizations, IAM Identity Center, and resource-based policies

2. Policy Types and Evaluation Order

Policy Type	Attached To	Purpose
Identity-based policy	IAM user/role/group	Grant permissions to a principal
Resource-based policy	AWS resource (S3, KMS, etc.)	Grant access to a resource from any principal
Permission boundary	IAM user/role	Maximum permissions a principal can have
SCP	Organizations account/OU	Maximum permissions for all principals in an account
Session policy	AssumeRole call	Restrict permissions for a specific session
RCP	Organizations account/OU	Restrict what resources can accept

Evaluation Logic (simplified)

1. Explicit DENY anywhere → DENY (final)
2. SCP allows the action? No → DENY
3. RCP allows the action? No → DENY
4. Resource-based policy allows? → ALLOW (for cross-account, both identity + resource policy needed)
5. Permission boundary allows? No → DENY
6. Session policy allows? No → DENY
7. Identity-based policy allows? Yes → ALLOW

3. Cross-Account Role Assumption

The standard pattern for cross-account access:

AWS IAM Identity Center

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 1 (26%). IAM Identity Center is the AWS-recommended solution for workforce identity across multiple accounts. Know permission sets, identity sources, and attribute-based access control.

1. Overview

AWS IAM Identity Center (formerly AWS SSO) provides centralized access management for human users across all AWS accounts in an organization and business applications. It replaces the need for individual IAM users in every account.

Problems it solves:

Managing IAM users in dozens of accounts
Inconsistent access controls across accounts
No single sign-on for AWS console and CLI
Complex SAML federation setup per account

2. Core Concepts

Identity Sources

Source	Use Case
IAM Identity Center directory (built-in)	Small teams, no existing IdP
Active Directory (AWS Managed AD or AD Connector)	Enterprise with on-premises AD
External IdP (Okta, Azure AD, Ping, etc.) via SAML 2.0 / SCIM	Enterprise with existing cloud IdP

Only one identity source can be active at a time. Changing it requires careful planning.

AWS KMS

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domains 1 and 2. KMS underpins encryption across S3, EBS, RDS, and more. At the Professional level, focus on key types, the key policy vs grant distinction, and cross-account patterns — not just “KMS encrypts things.”

1. Key Types

Type	Control	Use when
AWS-managed key (`aws/<service>`)	AWS creates, manages, rotates	Default; no key policy control
Customer-managed key (CMK)	You define key policy, rotation, aliases	Cross-account access, audit requirements, custom rotation
AWS-owned key	Fully AWS-managed, invisible	Default S3-SSE, no configuration

Decision rule: Use AWS-managed keys unless the scenario requires cross-account sharing, custom key policies, or CloudTrail audit of key usage — then it is a CMK. The exam often hides the requirement in “the security team must audit key usage” or “shared with another account.”

AWS Landing Zone Design

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 1 (26%). Landing zone design is a core SAP-C02 topic. Know the components, account structure, and customization options.

1. What Is a Landing Zone?

A landing zone is a pre-configured, secure, multi-account AWS environment that serves as a starting point for deploying workloads at scale. It enforces security baselines, centralized logging, and governance guardrails from day one.

AWS provides two paths:

AWS Control Tower — managed landing zone with automated setup (recommended)
Custom landing zone — built manually using Organizations, CloudFormation StackSets, and Config

2. Core Accounts

Account	Purpose
Management account	Organizations root, billing, Control Tower management. No workloads.
Log Archive account	Centralized S3 bucket for CloudTrail logs, Config snapshots, VPC flow logs
Audit account	Security team read-only access, Security Hub/GuardDuty delegated admin
Network Hub account	Transit Gateway, Direct Connect, shared DNS (Route 53 Resolver)
Shared Services account	Shared AMIs, Service Catalog, common tooling
Workload accounts	Dev, Staging, Prod — isolated per environment or per application

3. OU Design Principles

Root
├── Security OU (restricted SCPs — no workloads)
│ ├── Log Archive Account
│ └── Audit Account
├── Infrastructure OU
│ ├── Network Hub Account
│ └── Shared Services Account
├── Sandbox OU (loose SCPs — experimentation)
├── Workloads OU
│ ├── Dev OU
│ │ └── Dev Accounts (per team or per app)
│ ├── Staging OU
│ └── Prod OU
│ └── Prod Accounts
├── Suspended OU (closed/decommissioned accounts)
└── Exceptions OU (accounts needing SCP exemptions)

Design principles:

AWS Organizations

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 1 (26%). Foundation of every multi-account architecture question. Appears in Domains 3 and 4 as well.

1. Overview

AWS Organizations lets you centrally manage multiple AWS accounts under a single management account. It provides consolidated billing, policy-based governance via SCPs, and integration with nearly every AWS governance service.

Problems it solves:

Sprawling, ungoverned AWS accounts
Inconsistent security controls across teams
Complex cross-account billing and cost allocation
Manual account provisioning and configuration

2. Core Concepts

Account Types

Account Type	Role
Management account	Root of the organization. Creates and manages member accounts. SCPs do NOT apply to it.
Member account	Any account that joins the organization. Subject to SCPs.
Delegated administrator	Member account granted admin rights for a specific AWS service (e.g., GuardDuty, Security Hub).

Organizational Units (OUs)

Hierarchical grouping of accounts under the root
SCPs applied to an OU are inherited by all child OUs and accounts
Best practice: model OUs around security/compliance boundaries, not team structure
Maximum OU nesting depth: 5 levels

Root

Top-level container for all OUs and accounts
SCPs applied at root affect all accounts (except management account)

Policies

Policy Type	Purpose
Service Control Policies (SCPs)	Restrict what actions principals in member accounts can perform
Resource Control Policies (RCPs)	Restrict what resources in member accounts can accept (data perimeter)
Tag Policies	Enforce tag key/value standards across accounts
Backup Policies	Enforce AWS Backup plans across accounts
AI Services Opt-Out Policies	Control whether AWS AI services can use data for improvement

3. Architecture Patterns

Recommended OU Structure

Root
├── Security OU
│ ├── Log Archive Account ← centralized CloudTrail, S3 access logs
│ └── Audit Account ← Security Hub, GuardDuty delegated admin
├── Infrastructure OU
│ └── Network Hub Account ← Transit Gateway, Direct Connect, DNS
├── Sandbox OU ← developer experimentation, loose SCPs
├── Workloads OU
│ ├── Dev OU
│ ├── Staging OU
│ └── Prod OU
└── Exceptions OU ← accounts needing SCP exemptions

Consolidated Billing

All member account charges roll up to the management account
Volume discounts (e.g., S3, EC2 Reserved Instances) are pooled across the organization
Use Cost Allocation Tags + AWS Cost Explorer for per-account visibility

Delegated Administration

Management Account
 └── enables GuardDuty
 └── delegates admin to Audit Account
 └── Audit Account manages GuardDuty for all member accounts

Supported services for delegated admin include: GuardDuty, Security Hub, Config, Firewall Manager, IAM Access Analyzer, Macie, Inspector, and more.

AWS Resource Access Manager (RAM)

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 1 (26%). RAM is the mechanism for sharing AWS resources across accounts without cross-account IAM roles. Know what can be shared and how it integrates with Organizations.

1. Overview

AWS Resource Access Manager (RAM) lets you share AWS resources with other AWS accounts, OUs, or your entire organization — without duplicating resources or creating complex cross-account IAM setups.

Problems it solves:

Duplicating resources (e.g., Transit Gateway) in every account
Complex cross-account IAM role chains for shared infrastructure
Inconsistent shared resource configurations across accounts

2. Commonly Shared Resources

Resource	Use Case
Transit Gateway	Central network hub shared to all spoke accounts
VPC Subnets	VPC sharing — workload accounts deploy into shared subnets
Route 53 Resolver Rules	Share DNS forwarding rules to all accounts
AWS License Manager configurations	Share license rules across accounts
Aurora DB clusters	Share read replicas across accounts
AWS Glue Data Catalog	Share data catalog across accounts
AWS Network Firewall policies	Share firewall policies
Resource Groups	Share resource groups
EC2 Capacity Reservations	Share reserved capacity across accounts

Verify the current full list at https://docs.aws.amazon.com/ram/latest/userguide/shareable.html

AWS Security Hub

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domains 1, 3. Security Hub is the central security findings aggregator. Know standards, integrations, and automated response patterns.

1. Overview

AWS Security Hub provides a centralized view of security findings across AWS accounts, aggregating results from AWS security services and third-party tools. It evaluates your environment against security standards and best practices.

Problems it solves:

Security findings scattered across GuardDuty, Inspector, Macie, Config, etc.
No single compliance dashboard across accounts
Manual security review processes

2. Core Concepts

Security Standards

Pre-built compliance frameworks evaluated automatically:

AWS Transit Gateway

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 1 (26%). Transit Gateway is the standard answer for hub-and-spoke networking at scale. Know route tables, inter-region peering, and multicast.

1. Overview

AWS Transit Gateway (TGW) is a regional network transit hub that connects VPCs and on-premises networks through a central gateway. It replaces complex VPC peering meshes with a scalable hub-and-spoke model.

Problems it solves:

VPC peering does not scale (N*(N-1)/2 connections for N VPCs)
Separate VPN connections per VPC
No transitive routing between peered VPCs
Complex on-premises connectivity to multiple VPCs

2. Core Concepts

Attachments

Attachment Type	Connects
VPC attachment	VPC to TGW
VPN attachment	Site-to-Site VPN to TGW
Direct Connect Gateway attachment	DX Gateway to TGW
TGW peering attachment	TGW in another region or account
Connect attachment	SD-WAN/third-party appliances via GRE

Route Tables

TGW has one or more route tables
Each attachment is associated with one route table (for inbound routing)
Each attachment can propagate routes to one or more route tables
Default: all attachments share one route table (full mesh)
Custom: separate route tables per environment (Dev, Prod, Shared) for isolation

Associations vs Propagations

Association: which route table an attachment uses to look up routes (one per attachment)
Propagation: which route tables an attachment advertises its CIDR into (can be multiple)

3. Architecture Patterns

Basic Hub-and-Spoke

 Transit Gateway
 / | \
 VPC-Dev VPC-Prod VPC-Shared
 |
 On-Premises
 (VPN or DX)

All VPCs route through TGW. On-premises connects once to TGW and reaches all VPCs.

AWS VPN

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 1 (26%). VPN is the cost-effective hybrid connectivity option and the standard DX backup. Know Site-to-Site VPN, Client VPN, and accelerated VPN.

1. Overview

AWS offers two VPN services:

AWS Site-to-Site VPN — connects on-premises networks to AWS VPCs over IPsec tunnels
AWS Client VPN — allows individual users to connect to AWS or on-premises resources over OpenVPN

2. Site-to-Site VPN

Components

Component	Description
Virtual Private Gateway (VGW)	AWS-side VPN endpoint, attached to a VPC
Transit Gateway (TGW)	AWS-side VPN endpoint for multi-VPC connectivity
Customer Gateway (CGW)	Represents the on-premises VPN device in AWS
VPN Connection	IPsec tunnel between CGW and VGW/TGW

Tunnel Details

Each VPN connection has 2 tunnels for redundancy (different AWS endpoints)
Both tunnels should be configured on the customer device
Supports static routing or dynamic routing (BGP)
BGP is recommended — enables automatic failover and route propagation

Bandwidth and Limits

Limit	Value
Max throughput per tunnel	~1.25 Gbps
Max throughput per VPN connection (2 tunnels)	~2.5 Gbps with ECMP
Max VPN connections per VGW	10
Max VPN connections per TGW	5,000

ECMP with Transit Gateway

Attach multiple VPN connections to a TGW
Enable ECMP on TGW
Traffic is distributed across all active tunnels
Effectively aggregates bandwidth beyond single-tunnel limits

On-Premises ──── VPN Connection 1 (2 tunnels) ──┐
On-Premises ──── VPN Connection 2 (2 tunnels) ──┤── TGW (ECMP) ──── VPCs
On-Premises ──── VPN Connection 3 (2 tunnels) ──┘

3. Accelerated Site-to-Site VPN

Routes VPN traffic over AWS Global Accelerator instead of the public internet
Reduces latency and improves consistency for geographically distant sites
Requires TGW attachment (not VGW)
Additional cost for Global Accelerator usage

On-Premises ──── Internet ──── AWS Global Accelerator ──── TGW ──── VPCs
 (nearest AWS edge location)

4. Client VPN

Overview

AWS Client VPN is a managed OpenVPN service for individual users to connect to AWS or on-premises resources.

Cost Visibility and Optimization

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 1 (26%). Cost optimization and visibility is not merely choosing a cheaper instance: establish who owns spend, how usage is measured, and how the architecture can change safely.

1. Cost Management Tool Selection

Need	Tool	Decision cue
Explore historical spend, trends, forecasts, and filters	AWS Cost Explorer	Analysis and investigation; not a real-time billing ledger
Notify when actual or forecast spend crosses a threshold	AWS Budgets	Budget alerts, actions, and anomaly notifications; configure lead time and recipients
Detailed line-item billing data for custom queries	AWS Cost and Usage Report (CUR / Data Exports)	Deliver billing data to S3, then query with Athena or visualize with QuickSight
Estimate a proposed architecture before deployment	AWS Pricing Calculator	Estimate only; assumptions, regional prices, discounts, and usage drive accuracy
Detect unusual spend patterns	Cost Anomaly Detection	Identify anomalous spend and route alerts; it does not replace budgets or cost allocation
Attribute spend to teams/products	Cost allocation tags, Cost Categories, Organizations billing views	Define owners, tag policies, activation, and a remediation process for untagged resources
Find rightsizing opportunities	Compute Optimizer and Trusted Advisor	Recommendations require workload validation and have plan/coverage constraints

2. A Practical Visibility Loop

Define account/OU ownership and cost-allocation model
 |
Apply tags and Cost Categories; activate cost-allocation tags
 |
Use Cost Explorer for trends + CUR/Data Exports for detail
 |
Set Budgets and anomaly alerts with named owners
 |
Investigate drivers -> validate with workload telemetry
 |
Change architecture/commitments -> measure actual outcome

Use AWS Organizations consolidated billing and account separation to align spend with teams, products, and environments.
Standardize tag keys and allowed values. Tags are not retroactive for every report and do not automatically allocate all shared costs.
Allocate shared networking, support, security, and platform costs with an explicit model; do not leave them invisible.
Give teams dashboards and alerts, but central FinOps should own shared policies and commitment decisions.

3. Purchasing and Architecture Decisions

On-Demand: flexible, no usage commitment; useful for uncertain or short-lived demand.
Savings Plans / Reserved Instances: commitment discounts for eligible usage; analyze the stable baseline, flexibility, term, payment option, and utilization before purchase.
Spot: discounted spare capacity with interruption risk; use for fault-tolerant, restartable, or checkpointed work.
Storage tiers: compare capacity price with retrieval, request, transition, minimum-duration, and restore-time costs.
Data transfer: model inter-AZ, inter-Region, internet egress, NAT, Direct Connect, and replication traffic; high-availability designs may increase data movement.
Managed versus self-managed: include operational labor, patching, backup, resilience, and idle capacity, not just hourly resource price.

4. Governance and Security

Separate payer/management responsibilities from workload administration; restrict access to billing data using least privilege.
Use tag policies and account vending controls to improve allocation at creation time.
Protect CUR/Data Export buckets with scoped IAM and KMS policies; billing data reveals resource and usage metadata.
Use budgets and anomaly alerts as detection/notification controls, not as a guaranteed hard spending cap. Budget actions can restrict selected resources only after configuration and should be tested carefully.

5. Exam Scenario

Scenario: A company sees a 30% increase in cloud spend, but its monthly invoice only identifies account totals. Product owners need cost responsibility, and leadership wants early warning before budget overruns.

Resource Control Policies (RCPs)

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 1 (26%). RCPs are a newer Organizations policy type (2024). Know how they differ from SCPs and how they form the data perimeter.

1. Overview

Resource Control Policies (RCPs) are an Organizations policy type that set the maximum permissions available to resources in member accounts. While SCPs restrict what principals can do, RCPs restrict what resources can accept.

RCPs enable the resource side of a data perimeter — ensuring that even if a resource policy is misconfigured, resources cannot be accessed by untrusted principals or from untrusted networks.

Security Service Selection

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 1 (26%). Security scenarios often require several controls — select services by the control plane they provide, then design IAM, network, data, response, and governance integrations around them.

1. Which Service Answers Which Question?

Requirement	Service / control	Role and boundary
Detect suspicious account/API/network behavior	Amazon GuardDuty	Threat detection from supported data sources; findings require triage/remediation
Find software vulnerabilities and unintended exposure	Amazon Inspector	Vulnerability management for supported compute, container, and code resources
Discover sensitive data in S3	Amazon Macie	Sensitive-data discovery and classification for S3; scope findings and access carefully
Investigate relationships around security findings	Amazon Detective	Helps analyze and visualize security data; complements, does not replace, detection
Aggregate/normalize security findings and posture signals	AWS Security Hub CSPM	Central security posture/findings view; it does not generate every integrated service’s finding
Detect configuration drift/noncompliance	AWS Config	Resource configuration history and rule evaluation; remediation needs automation/policy
Analyze unintended resource access	IAM Access Analyzer	Findings for public/cross-account access and policy validation features
Filter HTTP/S requests to web applications	AWS WAF	Web ACLs, managed/custom rules, rate controls; applies at supported associations
Mitigate common and large-scale DDoS risks	AWS Shield	Standard protections plus paid Advanced capabilities; use WAF/architecture controls as required
Inspect and filter VPC network traffic	AWS Network Firewall	Stateful/stateless network policy at VPC boundaries; design routing and symmetry
Centrally apply supported security policies across accounts/resources	AWS Firewall Manager	Organization-wide policy management when prerequisites and supported resource types fit
Manage encryption keys	AWS KMS / CloudHSM	Select managed key service or dedicated HSM control based on key custody/compliance requirements
Store/rotate application secrets	AWS Secrets Manager / Systems Manager Parameter Store	Choose secret rotation and lifecycle features versus parameter/configuration storage needs

2. Layered Detection and Response Pattern

GuardDuty / Inspector / Macie / Config
 |
 Security Hub CSPM (aggregate)
 |
 EventBridge finding rule / workflow
 |
 Lambda or Systems Manager Automation
 |
 ticket, isolate, revoke, notify, remediate
 |
 CloudTrail + CloudWatch evidence

Keep management, delegated administration, and workload accounts distinct; use Organizations/Control Tower for enrollment and guardrails.
Configure least-privilege service roles, organization enablement, delegated administrators, Regions, and finding aggregation explicitly.
Make remediation idempotent, auditable, and reversible where possible. A finding should not automatically trigger a destructive action without severity/context checks.
Protect findings, logs, and investigation data with retention, encryption, and access controls.

3. Network and Web Application Controls

Use security groups for stateful workload boundaries; NACLs for subnet-level stateless filtering; route tables and firewall appliances for traffic paths.
Use AWS WAF for application-layer request inspection at supported endpoints. Shield addresses DDoS resilience; neither replaces application scaling, caching, origin protection, or incident plans.
Use Network Firewall or a centralized inspection design for VPC network traffic. Validate return paths, AZ resilience, routing symmetry, and throughput.
Use Firewall Manager when central policy administration across an Organization is required and its supported resource types match.

4. Exam Scenario

Scenario: A regulated organization needs to find exposed S3 buckets, detect suspicious account behavior, identify vulnerable EC2 packages, and route high-severity findings to a security team across many accounts.

Service Control Policies (SCPs)

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 1 (26%). SCPs appear in almost every multi-account governance scenario. Know deny strategies, inheritance, and interaction with IAM policies cold.

1. Overview

SCPs are a type of Organizations policy that set the maximum permissions available to IAM principals (users, roles) in member accounts. They do not grant permissions — they define the ceiling.

Effective permissions = IAM policy permissions ∩ SCP permissions

If an action is denied by an SCP, no IAM policy can allow it. If an action is not in the SCP allow list (allow-list strategy), it cannot be performed regardless of IAM.

VPC Advanced

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 1 (26%), Domain 2 (29%). Advanced VPC features are tested heavily at the professional level. Know VPC sharing, PrivateLink, endpoints, and peering limitations.

1. VPC Endpoints

Gateway Endpoints

Free; route-table based
Supported services: S3 and DynamoDB only
Traffic stays within AWS network — does not leave to internet
Add a route in the route table pointing to the endpoint

Interface Endpoints (AWS PrivateLink)

ENI with private IP in your VPC subnet
Supports 100+ AWS services and custom services
Billed per hour + per GB
DNS resolves service hostname to private IP within VPC
Supports endpoint policies to restrict access

VPC
├── Subnet
│ └── Interface Endpoint ENI (private IP: 10.0.1.50)
│ └── PrivateLink → AWS Service (e.g., Secrets Manager)
└── Route Table (no change needed — DNS-based)

Gateway Load Balancer Endpoints

Used for inline traffic inspection (third-party appliances)
Integrates with Gateway Load Balancer for transparent bump-in-the-wire inspection

VPC sharing allows multiple accounts to use subnets from a single VPC owned by one account (the owner).