SAA-C03 Cheat Sheet

EC2 → instance profile, Lambda → execution role, ECS → task role, EKS → IRSA, GitHub Actions → OIDC AssumeRoleWithWebIdentity. Static access keys are last resort only (legacy SaaS without OIDC). Roles deliver short-lived auto-rotating credentials; keys are permanent secrets that leak once and stay compromised.

For 5+ humans, centralize in your IdP (AD, Okta, Entra, Google) and bind via Identity Center permission sets to (group × account × permission set). Local IAM users are a 2-3-person startup pattern at most; Cognito User Pools are for end-customers, not workforce. AWS rebranded AWS SSO to IAM Identity Center^[7] in 2022. On the exam, treat 'AWS SSO' and 'IAM Identity Center' as synonymous — same service. Identity Center replaces federated IAM for workforce access in any new design.

A permission boundary is the ceiling on what an IAM principal can do — never a grant. Effective permissions = identity Allow ∩ boundary Allow ∩ no Deny ∩ no SCP Deny. Use boundaries to delegate role creation to developers without iam:* escalation.

Never share access keys across accounts. Account B creates a role whose trust policy permits principals in account A; A calls sts:AssumeRole. For third-party SaaS add sts:ExternalId to defeat confused-deputy; for human-assumed roles add aws:MultiFactorAuthPresent.

When a third-party SaaS assumes a role in your account, ONLY pinning the vendor's principal ARN in the trust policy is unsafe — a different customer of the same vendor can be tricked into using your role ARN. Pin sts:ExternalId^[12] in the trust policy's Condition. The vendor supplies a unique ID per customer; your account validates it on every AssumeRole.

Service Control Policies^[10] attached at the AWS Organizations root or OU level can only RESTRICT what member accounts can do. They never grant permission. Common trap: 'How do I let account B access a bucket in account A?' — SCP is wrong; the answer is a bucket policy in A + a role in A assumed by a principal in B.

When you enable Auto Scaling, Organizations, ECS, Lambda@Edge, etc., AWS auto-creates a service-linked role^[11] in your account. You can't author or scope it. Exam tip: if the question asks 'how do I grant Service X permission to act on my behalf', the answer is usually 'service-linked role already exists' — not a new role you create.

Instance Metadata Service v1 is SSRF-vulnerable — a flaw in a webapp can trick the server into requesting credentials from 169.254.169.254 and leaking them. IMDSv2^[2] requires a session token (PUT) before any GET, breaking SSRF chains. Enforce via launch template HttpTokens=required, or org-wide via SCP denying instance launches without it.

Across all four layers (SCP, permission boundary, identity policy, resource policy), an explicit Deny anywhere short-circuits the entire evaluation^[13]. No Allow can override it. Common debug pattern: 'Admin user can't access bucket' → check resource policy for an explicit Deny on their principal.

Roles default to a 1-hour session; raise via the role's MaxSessionDuration^[14] (1-12 hours). IAM Identity Center permission sets have their own session duration (1-12h). Federation sessions are capped by BOTH the IdP token life AND the role's MaxSessionDuration — the shorter wins.

When a new account joins (or is created in) AWS Organizations^[15], an OrganizationAccountAccessRole is auto-provisioned with full admin in the new account, trusted by the management account. Pattern: central security account assumes this from management account → no per-account setup.

IAM Access Analyzer^[16] scans resource policies (S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, Secrets Manager) and flags grants to principals outside your account / org. Free to enable per region; finds the "this bucket policy accidentally allows the internet" problem.

The aws:PrincipalOrgID global condition key in bucket policies (or other resource policies) ensures that only principals whose accounts are members of the specified AWS Organization can access the resource. It automatically includes any new accounts added to the organization without requiring policy updates. This is the recommended alternative to listing every account ID in the Principal element, and it scales automatically as the organization grows.

When the requesting identity and the S3 bucket are in different AWS accounts, access requires permissions in both accounts: a bucket policy in the resource account granting the specific action to the cross-account principal, and an IAM identity-based policy in the requesting account granting access to the bucket ARN. Neither policy alone is sufficient for cross-account access.

Compliance (HIPAA, PCI, GDPR) requires both: SSE or KMS at rest, TLS in transit. S3 default encryption is SSE-S3 since Jan 2023; enable bucket policy that requires aws:SecureTransport=true to enforce TLS for clients.

AWS-owned: free, no visibility. AWS-managed: free, audit trail. Customer-managed: ~$1/key/month + per-request, full control + cross-account share + rotation. CloudHSM: dedicated FIPS 140-2 Level 3, highest cost.

Block Public Access at account + bucket level kills ACL footguns. Default encryption applies to all objects. Object-level ACLs and per-object policies should be the exception, not the pattern — they're hard to audit at scale.

Macie scans S3 buckets for PII, PHI, financial data, and credentials using managed identifiers + custom regex. Findings route via EventBridge for auto-remediation. Cost is ~$1/GB scanned — scope by bucket selectively, not org-wide blind.

Every new S3 bucket gets SSE-S3 enabled automatically^[1]. You can upgrade to SSE-KMS at any time. Pre-2023 buckets may still be unencrypted — audit with AWS Config rule s3-bucket-server-side-encryption-enabled.

Customer-managed KMS keys support automatic yearly rotation^[18] — opt-in via EnableKeyRotation API. AWS-managed keys rotate every year automatically with no opt-in. Imported key material doesn't auto-rotate; you must re-import.

ScheduleKeyDeletion^[19] requires a 7–30 day waiting period — there's no instant delete. Within that window, you can CancelKeyDeletion. Use for accidental-deletion protection. CloudHSM, by contrast, allows immediate key destruction.

Initial discovery scan can be expensive on petabyte-scale buckets. Common pattern: full scan once after migration, then scheduled monthly scans on critical buckets only. Use excludes^[15] filters to skip large non-sensitive prefixes.

Key policies are static — edit them and you change permanent permissions. Grants^[20] are temporary, programmatic permissions issued via kms:CreateGrant — perfect for short-lived workloads that need temporary access to a key. AWS services (e.g. RDS encryption) create grants automatically.

Add Condition: { StringEquals: { kms:ViaService: "s3.us-east-1.amazonaws.com" } }^[21] to a key policy → that key can only be used via S3 in us-east-1. Defense against credentials being misused to decrypt the key elsewhere.

Two modes: Governance (admin can override) vs Compliance (no one, not even root, can shorten retention or delete during the window). Required for SEC 17a-4(f) / FINRA / CFTC compliance^[22]. Set per-object or via default retention policy on the bucket. Versioning must be on.

AWS Certificate Manager certificates used with Amazon CloudFront must be requested or imported in the US East (N. Virginia) Region (us-east-1), regardless of where the origin or end users are located. CloudFront is a global service, and certificates in us-east-1 are automatically distributed to all edge locations configured for the distribution. A certificate in any other region will not appear in the CloudFront console.

Setting S3 Object Ownership to Bucket owner enforced disables all ACLs on the bucket and makes the bucket owner the automatic owner of every object, including objects uploaded by other AWS accounts. Access is then controlled exclusively through bucket policies and IAM policies. This is the AWS-recommended default for new buckets and resolves cross-account upload scenarios where the uploader would otherwise retain object ownership.

S3 Block Public Access can be enforced at the AWS Organizations level by attaching the policy at the root or OU. This setting propagates to all member accounts, including newly joined accounts, and overrides account-level and bucket-level Block Public Access settings. Individual account administrators cannot remove it. To allow a specific account to host a public bucket, the org administrator must exclude that account from the policy.

When S3 Bucket Keys are enabled on a bucket configured with SSE-KMS, AWS KMS generates a bucket-level key that S3 uses to create data keys for individual objects, dramatically reducing the number of direct calls to AWS KMS. This can cut KMS request costs by up to 99% on high-traffic buckets while keeping all objects encrypted with the customer managed key.

Granting cross-account access to a customer managed KMS key requires two configurations: the key policy in the key-owning account must grant permissions to the external account (or specific principal), and an IAM policy in the external account must explicitly allow the principals to use that specific key ARN. The key policy determines who can have access; the IAM policy determines who does have access. Neither alone is sufficient.

Changing a bucket's default encryption configuration only affects newly uploaded objects; existing objects retain their original encryption. To re-encrypt billions of existing objects with a new SSE-KMS customer managed key, use S3 Batch Operations with the Copy operation, which copies objects back to the same bucket while applying the new encryption settings.

AWS KMS keys are Regional resources and cannot be used across AWS Regions. When creating an encrypted cross-Region RDS read replica, you must specify a customer managed key (or AWS managed key) that exists in the destination Region. Similarly, an S3 bucket can only use a KMS key from the same Region for SSE-KMS encryption.

In an AWS Organizations environment, the management account designates a dedicated security account as the Macie delegated administrator. The delegated administrator can enable Macie in member accounts, run sensitive data discovery jobs across the organization, and aggregate findings centrally. AWS best practice is to use a separate security account rather than the management account for day-to-day Macie operations. Automated sensitive data discovery uses sampling to assign sensitivity scores to every S3 bucket, providing broad visibility cost-efficiently.

Server Name Indication (SNI) allows CloudFront to serve HTTPS requests with custom SSL certificates without requiring a dedicated IP address per certificate, incurring no additional monthly charge. All modern browsers released after 2010 support SNI. The alternative, Dedicated IP SSL, incurs an additional monthly fee per distribution and is only needed for legacy clients that do not support SNI.

To enforce HTTPS between CloudFront and a custom origin, set the Origin Protocol Policy to HTTPS Only and configure the minimum origin SSL protocol to TLSv1.2. CloudFront returns HTTP 502 (Bad Gateway) if the origin presents a self-signed certificate or an untrusted certificate chain when HTTPS Only is active — the origin certificate must be signed by a trusted CA.

When uploading objects to an S3 bucket configured with SSE-KMS, Amazon S3 calls AWS KMS to generate a data key, requiring kms:GenerateDataKey on the key. When downloading, S3 must decrypt the data key, requiring kms:Decrypt. Both permissions are needed for an application that both uploads and downloads. An IAM policy missing either permission will cause the corresponding S3 operation to fail with an AccessDenied error.

Accessing a Secrets Manager secret from a different AWS account requires both a resource-based policy on the secret (granting secretsmanager:GetSecretValue) and a key policy on the encrypting KMS key (granting kms:Decrypt). The AWS managed key aws/secretsmanager cannot be used for cross-account access because its key policy cannot be modified; a customer managed key is required.

When a Secrets Manager secret is encrypted with a customer managed KMS key, the Lambda rotation function's execution role needs kms:Decrypt on that key. Adding a condition using the kms:EncryptionContext:SecretARN key restricts the function to decrypt only the specific secret it is authorized to rotate, following least-privilege. Without this condition, a single KMS permission would allow decryption of any secret encrypted with the same key.

An Interface or Gateway endpoint can carry its own endpoint policy^[23] restricting which API actions and resources are allowed through it. Common pattern: S3 Gateway endpoint allows s3:GetObject on your specific buckets only — anything else through the endpoint is denied.

Spread stateless tiers across ≥2 AZs behind a load balancer. RDS Multi-AZ: synchronous standby, 60-120 s failover. Multi-Region only when single-region failure is in your threat model — adds latency, cost, replication complexity.

Four canonical strategies in increasing cost / decreasing RTO/RPO: backup-and-restore (hours), pilot-light (minutes-hours), warm-standby (minutes), multi-site active-active (near-zero). The exam picks the cheapest one that meets the stated RTO/RPO.

Auto Scaling Group across ≥2 AZs + ALB/NLB with health checks at the target group. Unhealthy instances drain + replace automatically. ASG min/max/desired control capacity; target-tracking or step scaling policies handle demand changes.

Simple (one answer), Weighted (split traffic), Latency (route to closest region), Failover (active/passive via health check), Geolocation (by user country), Geoproximity (by lat/lon + bias), Multi-value (DNS-level load balancing).

Automatic failover^[1] updates the DNS endpoint to the standby; clients with cached DNS will see ~60-120 s of errors. App needs to reconnect on connection failure. Standby is NOT readable — for read scaling, use Read Replicas^[13] (separate feature).

Replicates Aurora across regions^[2] via dedicated network. RPO typically <1 s; failover RTO ~1 min (managed promotion). Secondary regions support read-only and can be promoted to writer. Big advantage over manual cross-region replicas.

Default check interval 30 s^[14], healthy threshold 3, unhealthy threshold 3. Fast failover requires faster checks (10 s interval supported, paid). Use 'calculated' health checks to combine multiple endpoint checks for AND/OR logic.

ASG HealthCheckType=EC2^[15] only replaces instances that the EC2 instance itself reports as unhealthy (hardware fail). HealthCheckType=ELB replaces instances that the load balancer's health check fails — catches app-layer failures too. Use ELB for production.

CRR replicates new objects^[4] from source to destination bucket asynchronously (typically seconds). Existing objects need a one-time batch operation. Can filter by prefix or tag. Versioning must be on for both buckets.

Backup plans + selections^[8] cover RDS, DynamoDB, EFS, EBS, FSx, Storage Gateway, etc. Cross-region, cross-account copy supported. Audit Manager + Backup Vault Lock for compliance scenarios.

Active/passive failover routing^[16] needs the primary record to have an associated health check. If the check fails, the secondary record is served. Without the health check, Route 53 always serves the primary.

The health check grace period tells Auto Scaling how long to wait before evaluating the health of a newly launched instance after it enters InService state. Set it to at least as long as the application startup time; otherwise ELB health check failures during initialization cause continuous termination and replacement loops.

When a target is removed from an ALB target group, the load balancer stops sending new requests but waits for the deregistration delay (default 300 s, range 0-3600 s) before completing deregistration. Set this value to at least the maximum expected request processing time to prevent HTTP 5xx errors during scale-in events.

Slow start mode causes the ALB to linearly increase the share of requests sent to a newly registered target over a configurable duration of 30–900 seconds. Use it when instances need a warm-up period (e.g., JIT cache warming, dataset loading) before they can handle their full share of traffic.

For Application Load Balancers, cross-zone load balancing is always enabled at the load balancer level and cannot be turned off. However, it can be explicitly disabled at the target group level, overriding the load balancer default. When enabled, each LB node distributes traffic evenly across all registered targets in all enabled Availability Zones.

Network Load Balancers automatically provide one static IP address per enabled Availability Zone. For internet-facing NLBs you can also assign your own Elastic IP per AZ, giving external clients fixed addresses to allowlist in firewalls. NLB operates at Layer 4, supports ultra-low latency, and preserves the client source IP address by default.

Latency-based routing records with Evaluate Target Health set to Yes implement active-active failover: all healthy regions serve traffic based on lowest latency, and Route 53 automatically stops routing to a region when its resources become unhealthy. For hierarchical configurations (latency over weighted), ETH on the top-level alias causes Route 53 to traverse the tree and consider the region unhealthy only when all underlying weighted records fail.

A calculated health check monitors other health checks (child health checks) and reports healthy when the number of healthy children meets a configurable threshold. This lets you trigger DNS failover only when a minimum number of endpoints are down (e.g., healthy if at least 2 of 6 servers are up), rather than reacting to individual endpoint failures.

Any routing policy other than Failover combined with health checks creates an active-active configuration. With weighted records, Route 53 distributes traffic according to weights while all records are healthy; when a record's health check fails, Route 53 excludes it from responses and redistributes remaining traffic to healthy records. A zero-weight record acts as a standby, receiving traffic only when all nonzero-weight records are unhealthy.

A common multi-tier DNS pattern uses latency alias records at the top level (for region selection) pointing to weighted records within each region (for intra-region distribution). Enabling Evaluate Target Health on the latency alias causes Route 53 to consider a region healthy only if at least one of its weighted child records is healthy, enabling cascading health propagation.

Each Aurora Replica can be assigned a promotion priority tier from 0 (promoted first) to 15 (promoted last). When the primary instance fails, Aurora promotes the replica with the lowest tier number. Assign tier 0 to the preferred standby (e.g., same instance class as the primary) and higher tiers to replicas used for analytics or reporting.

RDS automatic snapshots are tied to the source region. Manual or copied snapshots^[17] can move cross-region (encrypted with a regional KMS key) or cross-account (share with target account). Used in pilot light / warm standby DR strategies.

Relational (RDS, Aurora) for transactions + joins + ad-hoc queries. Key-value (DynamoDB) for predictable single-item ops at any scale. Document (DocumentDB) for JSON-shaped data. Search (OpenSearch) for full-text. Time-series (Timestream). Graph (Neptune).

RDS Read Replicas: async, up to 15 per source. Aurora Replicas: <100 ms typical lag, up to 15. For write scale, DynamoDB partition design + adaptive capacity, or shard across multiple Aurora clusters by tenant/key.

MySQL/PostgreSQL wire-compatible + distributed storage (6 copies across 3 AZs) + auto-scaling storage (up to 256 TiB) + faster failover (<30 s) + Aurora Serverless v2. Pick Aurora unless you specifically need stock RDS Oracle/SQL Server. Aurora storage grows automatically^[11] up to 256 TiB on current Aurora engine versions (128 TiB on older versions). No manual resize, no downtime, no provisioning. Charged for what you use — drop a table, storage shrinks.

DAX^[15] is a write-through, write-around, and read-through cache for DynamoDB. Reads through DAX = microseconds (vs single-digit ms direct). Writes go through DAX and to DynamoDB. Eventual consistency by default. Sits in your VPC; uses DynamoDB API.

Shared storage layer^[11] (not log shipping) means much lower replica lag than RDS async replicas. 15 read replicas max. Reader endpoint load-balances across replicas. Failover promotes a replica → typically ~1 minute.

Adaptive capacity^[16] helps, but a low-cardinality partition key still hurts. Use high-cardinality keys (UUIDs, hashes) or composite keys (tenant#item). GSI helps query different attributes but doesn't fix hot-key writes on the base table.

Redis^[17]: data structures (lists, sets, sorted sets, streams, geo, hyperloglog), pub/sub, persistence, replication, cluster mode for sharding, transactions. Memcached: simple key-value, no persistence, multi-threaded per node, auto-discovery. Use Redis unless you specifically need simple multi-threaded caching.

Capture every insert/update/delete^[18] as a stream record (4 view types: KEYS_ONLY, NEW_IMAGE, OLD_IMAGE, NEW_AND_OLD_IMAGES). 24h retention. Common consumer: Lambda for change-data-capture (CDC) → other services. Enable for Global Tables under the hood.

For large fact-to-large-dimension joins, set DISTSTYLE KEY on the same join column in both tables so matching rows land on the same slice, eliminating redistribution. For small, slowly changing dimension tables (typically under a few million rows), use DISTSTYLE ALL to place a full copy on every node, making any join column work without data movement. EVEN distribution is the default but rarely optimal once join patterns are known.

Applications must connect to the Aurora reader endpoint (not individual instance endpoints) to benefit from Aurora Auto Scaling. The reader endpoint uses DNS round-robin and automatically adds newly provisioned replicas once they pass health checks, distributing connections across all available replicas. Using instance-specific endpoints causes new Auto Scaling replicas to receive no traffic.

Aurora MySQL supports rewinding the cluster^[12] up to 72 hours back without a restore (no downtime; cluster reverts in-place). For "oops, dropped a table" recovery. Different from PITR (which restores to a new cluster).

Steady-state EC2/Fargate/Lambda running >70% of any 1- or 3-year window fits a capacity commitment. Reserved Instances are workload-specific; Savings Plans are usage-based across families. RIs apply BEFORE Savings Plans — buy order matters.

Spot Instances use AWS spare capacity at up to 90% off On-Demand. 2-minute interruption notice; allocation strategy price-capacity-optimized is the modern default. Use for stateless workers, batch, big-data, CI fleets. Never for stateful workloads without checkpointing.

Compute Optimizer analyzes utilization and recommends smaller instances or different families for EC2, EBS, Lambda, ECS-on-Fargate. Lambda recommendations need ≥50 invocations in 14 days. Trusted Advisor surfaces RI / SP recommendations separately.

Each billing hour AWS applies discounts in a fixed order: RIs first (to matching family/region/AZ/OS usage), then Savings Plans (to any remaining eligible usage, highest-discount-first), then on-demand. If you already own RIs covering your baseline, a fresh Compute SP overlapping that usage sits idle — the RIs consume the hours first. Buy SPs to cover un-RI-covered usage, then add RIs only for instance types with reliably steady utilization.

Standard RI: family-locked, can sell on RI Marketplace if no longer needed. Convertible RI: can exchange for a different family/OS/tenancy without selling. Compute SP: cover EC2 + Fargate + Lambda across any family and any region; the most flexible commitment but slightly lower max discount.

lowest-price^[10] minimizes hourly cost but maximizes interruption risk (cheapest pools are reclaimed first). capacity-optimized launches from the pool with lowest predicted interruption — best for long-running workloads. price-capacity-optimized (current AWS default for Fleet/ASG) balances both. For HPC/ML with instance-type preferences, capacity-optimized-prioritized respects your priority list.

Below 50 invocations / 14 days^[9], Lambda functions get NO Compute Optimizer recommendation. Exam pattern: 'Compute Optimizer cannot generate a recommendation' for a low-traffic Lambda → root cause is this threshold, not a configuration issue.

AWS Graviton (ARM64) instances^[11] deliver up to 40% better price-performance vs comparable x86. Most managed services support Graviton (RDS, Aurora, ElastiCache, Lambda, Fargate). When the question says 'reduce cost' and doesn't restrict architecture, Graviton is usually a correct answer.

Fargate Spot^[12] uses spare ECS Fargate capacity at deep discount. Same 2-minute interruption notice as EC2 Spot. Good for: CI builds, fault-tolerant containerized batch, dev/test. Mixed capacity provider: FARGATE for baseline + FARGATE_SPOT for burst.

Free Trusted Advisor^[13] checks include "underutilized EC2 instances" (right-sizing), "RI optimization", and "Savings Plans recommendations" — once you have ~30 days of usage. Business / Enterprise support tier unlocks the full check set.

When Capacity Rebalancing is enabled on an Auto Scaling group, it responds to EC2 instance rebalance recommendation signals — which arrive before the 2-minute interruption notice — by launching a replacement instance proactively. Pair it with lifecycle hooks to allow in-flight requests to drain gracefully before the old instance terminates.

By default Compute Optimizer analyses 14 days of CloudWatch metrics, which misses monthly or quarterly utilization spikes. The Enhanced Infrastructure Metrics paid add-on extends the lookback period to up to 93 days, enabling accurate recommendations for workloads with cyclical billing or processing patterns.

Recommendation preferences (approved instance families, CPU headroom, lookback period) configured from the management account automatically propagate to all member accounts in an AWS Organization, minimizing per-account overhead. Compute Optimizer does NOT generate rightsizing recommendations for Spot Instances. It does support RDS MySQL and PostgreSQL (with Performance Insights) alongside EC2, Lambda, EBS, and ECS.

A Regional Reserved Instance applies a billing discount across all AZs in a Region but does NOT reserve capacity. A Zonal Reserved Instance scoped to a specific Availability Zone provides both the billing discount and a guaranteed capacity reservation matching the instance attributes, ensuring instances can launch even during peak demand in that AZ.

AWS-designed ARM64 processors deliver up to 40% better price-performance vs x86 equivalents. Requires ARM-compatible runtime (most modern languages OK; some Windows AMIs + legacy binaries don't). When the question says "reduce cost" + workload is portable: Graviton.