⭐ Design Secure Access to AWS Resources

🔹 Root User Security

The root user has full, unrestricted access to the AWS account.

Should be used only for initial setup tasks, such as:

Creating the first IAM admin user

Setting up billing

Enabling MFA

After initial setup:

Lock it away

Enable MFA immediately

Never use it for daily operations

🔹 IAM Users (Daily Operational Identities)

Represent individual people or applications needing AWS access.

Used for day‑to‑day operations, not administrative bootstrap tasks.

Each user should have:

Unique credentials

Permissions based on job role

MFA enabled

🔹 Key IAM Security Best Practices

1. Principle of Least Privilege

Grant only the permissions required for the task.

Avoid broad permissions like AdministratorAccess unless absolutely necessary.

2. Multi‑Factor Authentication (MFA)

Mandatory for:

Root user

All IAM users

Adds a second authentication factor (authenticator app, hardware key).

Protects against compromised passwords.

3. Strong Password Policies

Enforce:

Minimum length

Complexity (uppercase, lowercase, numbers, symbols)

Regular rotation

Prevents weak password vulnerabilities.

4. Regular Credential Rotation

Rotate IAM access keys frequently.

Never embed access keys in code.

Use IAM roles for EC2, Lambda, ECS, etc.

5. Monitor Activity

Use AWS CloudTrail to log all API calls.

Detect suspicious or unauthorized activity.

Enable CloudTrail in all regions.

⭐ Designing a Flexible Authorization Model (IAM Users, Groups, Roles, Policies)

🔹 IAM Users

Represent individual identities.

Can have policies attached directly, but:

Hard to manage at scale

Not recommended for large teams

🔹 IAM Groups

Collections of IAM users.

Simplify permission management:

Attach policies to groups

Users inherit group permissions

Best practice for teams with similar job functions.

🔹 IAM Roles

Roles provide temporary credentials via AWS STS.
Used by:

1. AWS Services

EC2, Lambda, ECS tasks, etc.

Preferred method for applications to access AWS resources.

Eliminates need for embedded credentials.

2. Federated Users

Users from corporate directories (AD, Okta, Azure AD).

Access AWS without creating IAM users.

Improves security and centralizes identity management.

3. Cross‑Account IAM Users

Users in Account A can access resources in Account B.

Achieved by:

Creating a role in the resource account

Adding a trust policy

Allowing the principal to assume the role

🔹 IAM Policies

Policies define permissions in JSON format.

Policy Components

Actions — what actions are allowed (e.g., `s3:GetObject`)

Resources — which resources the actions apply to

Effect — Allow or Deny

Types of IAM Policies

1. AWS Managed Policies

Predefined by AWS

Good starting point

Updated automatically by AWS

2. Customer Managed Policies

Created and managed by you

Recommended for specific business requirements

Reusable and version‑controlled

3. Inline Policies

Embedded directly in a user, group, or role

Deleted when the entity is deleted

Not reusable

Use only for one‑off, tightly‑scoped permissions

⭐ Example Scenario (Fully Detailed)

Users

Each developer has an IAM user.

Group

All developers added to a Developers IAM group.

Policy

Create a customer‑managed policy named DevAccess with permissions to:

Deploy code to specific S3 buckets

Start/stop EC2 instances in a specific environment

Access CloudWatch logs

Group Attachment

Attach DevAccess policy to the Developers group.

Role

Create an IAM role EC2AppRole for EC2 instances to read configuration from an S3 bucket.

Instance Profile

Associate EC2AppRole with an instance profile.

Attach the instance profile to EC2 instances.

⭐ S3 IMMUTABILITY — ULTRA‑CRISP EXAM TIPS

S3 Retrieval Time Table

Storage Class Retrieval Time Simple Meaning
S3 Standard Milliseconds Fast — real‑time access
S3 Standard‑IA Milliseconds Fast but cheaper — for infrequent access
S3 Intelligent‑Tiering Milliseconds Always fast — auto‑moves data
S3 Glacier Instant Retrieval Milliseconds Cold storage but still instant
S3 Glacier Flexible Retrieval Minutes to hours Slow — for occasional restores
S3 Glacier Deep Archive 12–48 hours Very slow — long‑term archive

Storage Class	Retrieval Time	Simple Meaning
S3 Standard	Milliseconds	Fast — real‑time access
S3 Standard‑IA	Milliseconds	Fast but cheaper — for infrequent access
S3 Intelligent‑Tiering	Milliseconds	Always fast — auto‑moves data
S3 Glacier Instant Retrieval	Milliseconds	Cold storage but still instant
S3 Glacier Flexible Retrieval	Minutes to hours	Slow — for occasional restores
S3 Glacier Deep Archive	12–48 hours	Very slow — long‑term archive

S3 Storage Lens can3detect incomplete multipart uploads

🟩 1. Compliance Mode = “NO ONE can delete — not even root”

Use when the question mentions:

WORM
SEC / FINRA / HIPAA / SOX
“Even root cannot delete”
“Regulatory retention”
“Immutable for 7–10 years”
“Legal hold required”

Exam rule:
👉 If the scenario says regulatory + immutability → ALWAYS Compliance Mode.

Memory hook:
Compliance = Concrete Box (sealed, unbreakable).

🟩 2. Governance Mode = “Protected, but override allowed”

Use when:

No regulatory requirement
Only want to prevent accidental deletion
Senior admins can override using s3:BypassGovernanceRetention

Exam rule:
👉 Governance = internal protection, NOT legal compliance.

Memory hook:
Governance = Gate with a Key (admins can unlock).

🟩 3. Glacier Vault Lock = WORM for Glacier Vaults ONLY

Use when:

Long‑term archives (10–25 years)
Government archival laws
Need a policy that becomes immutable once locked
Data is stored in Glacier Vaults, not S3 buckets

Exam trap:
👉 Glacier Vault Lock ≠ S3 Object Lock
👉 Glacier Vault Lock does NOT support legal holds.

🟩 4. MFA Delete = NOT compliance, NOT WORM

Use when:

Only want protection from accidental deletion
Small teams
Root user involvement is acceptable

Exam rule:
👉 If the question mentions compliance → MFA Delete is ALWAYS wrong.

Memory hook:
MFA Delete = Seatbelt, not a Safe.

🟩 5. Versioning = Recover from accidental deletes/overwrites

Use when:

Need to restore previous versions
No WORM requirement
No regulatory requirement

Exam trap:
👉 Versioning alone does NOT prevent deletion.
👉 Delete markers can still be added.

⭐ SET 2 — S3 SECURITY & ACCESS CONTROL

🟩 Block Public Access — MEMORY TIPS

If the bucket must NEVER be public → Block Public Access
“NEVER public” → Block Public Access
Overrides ACLs + Bucket Policies
Use for accidental exposure prevention
Account‑level = strongest
If question says “ensure bucket can NEVER be public” → this.
When to Use Block Public Access (Exam Triggers)

Use it when the question says:
“Ensure bucket can NEVER be public”
“Prevent accidental exposure”
“Security team requires no public access”
“Company wants central control over S3 public access”
“Need to enforce private-only buckets across the account”

🟩 CloudTrail Data Events — MEMORY TIPS

Logs GetObject / PutObject / DeleteObject
Shows WHO accessed the object
Required for compliance audits
S3 Access Logs ≠ identity, ≠ object‑level
If question says “audit object access” → Data Events.

🟩 CloudTrail — MEMORY TIPS

Logs API calls across AWS.
Enabled by default (90‑day event history).
Trails store logs in S3.
Multi‑region trails recommended.
Logs include who, when, source IP.
Integrates with CloudWatch Logs.
Required for compliance audits.
Organization trails cover all accounts.
Data events = S3 object‑level, Lambda invoke.
Exam keyword: “API auditing”.

CloudTrail_tracks_every_action — CloudTrail records every action taken in your AWS account, like a CCTV camera for API calls.
CloudTrail_shows_who_did_what — It tells you exactly which user, role, or service performed an action, and when they did it.
CloudTrail_logs_console_and_CLI — Whether someone uses the AWS Console, CLI, or SDK, CloudTrail logs it all.
CloudTrail_records_changes — Any change to AWS resources (security groups, IAM roles, S3 policies, EC2 actions) is captured for auditing.
CloudTrail_stores_logs_in_S3 — All CloudTrail logs are saved in an S3 bucket so you can keep them for months or years for compliance.
CloudTrail_integrates_with_CloudWatch — You can send CloudTrail events to CloudWatch Logs and create alarms for sensitive actions like root login or KMS key deletion.
CloudTrail_multi_region_trail — A multi‑region trail ensures you don’t miss activity happening in other AWS regions (common exam trap).
CloudTrail_organization_trail — One trail can capture API activity from all AWS accounts in an AWS Organization, making auditing easier.
CloudTrail_log_file_validation — It can verify that logs haven’t been tampered with, which is important for security audits.
CloudTrail_Insights_detects_unusual_activity — CloudTrail Insights automatically detects abnormal API behavior, like sudden spikes in IAM changes.
CloudTrail_is_for_auditing_not_performance — It does NOT show performance metrics like CPU, latency, or errors. It is only for auditing and tracking actions.
CloudTrail_data_events — It can log detailed events like S3 object access and Lambda function invocations (more detailed but more expensive).
CloudTrail_triggers_EventBridge — You can automate responses to sensitive actions (e.g., alert on root login, block key deletion) using EventBridge rules.
CloudTrail_compliance_support — CloudTrail helps meet compliance requirements like PCI, HIPAA, SOC by providing a full audit history.
CloudTrail_exam_keyword — In the exam, if the question says “audit,” “track changes,” “API history,” “who accessed,” or “compliance,” the answer is CloudTrail.

🟩 CloudTrail Insights — MEMORY TIPS

Detects unusual API activity.
Flags spikes in write/read events.
Helps detect compromised credentials.
Works on management events.
Sends notifications via SNS.
Not enabled by default.
Good for anomaly detection.
Integrates with Security Hub.
Useful for governance teams.
Exam keyword: “unusual API behavior”.

🟩 S3 Access Logs — MEMORY TIPS

Logs requests to bucket, NOT object API calls
No IAM identity
Used for traffic analysis, not compliance
If question says “monitor bucket traffic” → Access Logs.

🟩 S3 Replication — MEMORY TIPS

Requires Versioning
CRR = cross‑region, SRR = same region
Can replicate delete markers
Batch Replication = replicate existing objects
Cannot replicate from Glacier
If question says “DR copy” → Replication.

🟩 Default Encryption — MEMORY TIPS

Enforces encryption for all new objects
SSE‑S3 or SSE‑KMS
Combine with deny unencrypted uploads policy
If question says “ensure all objects are encrypted automatically” → Default Encryption.

🟩 Pre‑Signed URLs — MEMORY TIPS

Temporary access to one object
No IAM creds on client
Time‑limited
If question says “mobile app upload/download securely” → Pre‑Signed URL.

⭐ SUPER‑FAST MASTER TABLE (MEMORIZE THIS)

Requirement	Correct Feature
Never allow public access	Block Public Access
Audit object‑level access	CloudTrail Data Events
Monitor bucket traffic	S3 Access Logs
Cross‑region DR copy	S3 Replication
Enforce encryption	Default Encryption
Temporary object access	Pre‑Signed URLs

⭐ SET 3 — S3 LIFECYCLE, TIERING, SELECT, ATHENA, EVENTS, PERFORMANCE

🟩 Lifecycle Rules — MEMORY TIPS

“Move objects to cheaper storage automatically”
30 → IA, 60 → Glacier, 180 → Deep Archive (common exam pattern)
Works on prefix or tags
Cannot transition Glacier → IA (one‑way only)
Expiration deletes objects
Versioning: can expire noncurrent versions

🟩 Intelligent‑Tiering — MEMORY TIPS

Best for unknown or unpredictable access patterns
No retrieval fees
No performance impact
Small monthly monitoring fee
Automatically moves between tiers
If question says “unpredictable access” → Intelligent‑Tiering.

🟩 S3 Select — MEMORY TIPS

Query one object
Extract only needed rows/columns
Faster + cheaper than downloading whole object
Works on CSV, JSON, Parquet
If question says “filter data inside a single object” → S3 Select.

🟩 Athena — MEMORY TIPS

Query multiple objects using SQL
Serverless
Pay per TB scanned
Requires Glue Data Catalog
If question says “run SQL on S3 data lake” → Athena.

🟩 S3 Event Notifications — MEMORY TIPS

Triggers: PUT, POST, COPY, DELETE
Targets: Lambda, SQS, SNS
No prefix overlap allowed (one event per object)
No event for Glacier restore completion
If question says “trigger Lambda on upload” → Event Notifications.

🟩 S3 Performance Optimization — MEMORY TIPS

S3 auto‑scales — no need for random prefixes
Multipart upload for >100 MB
Byte‑range GET for parallel reads
Transfer Acceleration for global uploads
KMS encryption can throttle if high request rate
If question says “improve upload speed globally” → Transfer Acceleration.

⭐ SUPER‑FAST MASTER TABLE (SET 3)

Requirement	Correct Feature
Automatic tiering	Lifecycle Rules
Unpredictable access	Intelligent‑Tiering
Query inside one object	S3 Select
SQL over many objects	Athena
Trigger Lambda/SQS/SNS	Event Notifications
Faster uploads/downloads	Performance Optimization

⭐ SET 4 — S3 ENCRYPTION, KMS, ACCESS POINTS, MRAP, STORAGE CLASSES

🟩 SSE‑S3 — MEMORY TIPS

“AES‑256, fully managed by AWS”
No key management
Cheapest, simplest
If question says “easy encryption, no KMS” → SSE‑S3.

🟩 SSE‑KMS — MEMORY TIPS

Uses KMS CMKs
Audit logs in CloudTrail
Can enforce per‑object encryption
Can throttle at high request rates
If question says “audit key usage” → SSE‑KMS.

🟩 Client‑Side Encryption — MEMORY TIPS

Encryption happens before upload
S3 never sees plaintext
Customer manages keys
If question says “must not trust AWS with keys” → CSE.

🟩 KMS Key Policies — MEMORY TIPS

Key policy MUST allow S3 to use the key
IAM alone is NOT enough
Cross‑account access requires:
- Key policy
- Bucket policy
- IAM policy
If question says “KMS access denied” → key policy missing.
KMS key policy controls who can decrypt. Bucket policy controls who can access the S3 object.
KMS checks the key policy → “Are you allowed to decrypt the data key?”
KMS Key Policy — Controls Decryption Rights

Decides who can use the CMK to decrypt objects.
Even if the bucket policy allows access, without KMS decrypt permission the customer cannot read the object.
Used to exclude the company’s AWS account so staff cannot decrypt customer data.
Strongest enforcement point because KMS is the final gatekeeper.

🟩 S3 Access Points — MEMORY TIPS

Simplifies access for large multi‑team environments
Each access point has its own policy + hostname
Works with VPC‑only access
If question says “many apps need different access to same bucket” → Access Points.

🟩 Multi‑Region Access Points (MRAP) — MEMORY TIPS

Global endpoint
Automatic routing to nearest region
Built for multi‑region active‑active
Uses CRR under the hood
If question says “global low‑latency access to S3” → MRAP.

🟩 S3 Standard‑IA — MEMORY TIPS

Infrequent access
Retrieval fee
High durability
Multi‑AZ
If question says “infrequent but must be highly available” → Standard‑IA.

🟩 One Zone‑IA — MEMORY TIPS

Single AZ
20% cheaper
Not for critical data
If question says “re‑creatable data, low cost” → One Zone‑IA.

🟩 Glacier Instant Retrieval — MEMORY TIPS

Millisecond retrieval
Cheaper than IA
For long‑term but fast‑access workloads
If question says “archive but need fast retrieval” → Instant Retrieval.

🟩 Glacier Flexible Retrieval — MEMORY TIPS

Former “Glacier”
Minutes to hours retrieval
Cheapest for mid‑term archives
If question says “cheap archive, occasional retrieval” → Flexible Retrieval.

🟩 Glacier Deep Archive — MEMORY TIPS

Lowest cost
12–48 hour retrieval
For 7–25 year retention
If question says “long‑term cold archive” → Deep Archive.

⭐ SUPER‑FAST MASTER TABLE (SET 4)

Requirement	Correct Feature
Simple encryption	SSE‑S3
Audit key usage	SSE‑KMS
Don’t trust AWS with keys	Client‑Side Encryption
Multi‑team bucket access	Access Points
Global low‑latency S3	MRAP
Infrequent access	Standard‑IA
Cheap, single AZ	One Zone‑IA
Fast archive retrieval	Glacier Instant Retrieval
Cheap archive	Glacier Flexible Retrieval
Long‑term cold archive	Deep Archive

⭐ SET 5 — S3 NETWORKING, SECURITY MODELS, PERFORMANCE, COST

🟩 VPC Gateway Endpoint — MEMORY TIPS

Free
Scales automatically
For S3 & DynamoDB only
Route‑table based
If question says “private S3 access without NAT” → Gateway Endpoint.

🟩 VPC Interface Endpoint — MEMORY TIPS

Paid ENIs
Required for most AWS services, NOT S3
Adds private DNS
If question says “private access to non‑S3 services” → Interface Endpoint.

🟩 IAM Policy — MEMORY TIPS

Controls WHO can access S3
Attached to users/roles
Identity‑based
If question says “grant user access to S3” → IAM Policy.

🟩 Bucket Policy — MEMORY TIPS

Controls WHAT can access the bucket
Resource‑based
Needed for cross‑account access
If question says “allow another account to access bucket” → Bucket Policy.
Decides who can perform S3 actions like GetObject, PutObject, ListBucket.
Used to ensure each customer can access only their own prefix.
Can restrict access by:
AWS account ID

IAM role
Prefix (customer123/*)
VPC endpoint
IP address

controls s3 object access

🟩 ACLs — MEMORY TIPS

Legacy
Only used for object‑level cross‑account or Access Points
Avoid unless required
If question says “object‑level cross‑account access” → ACL.

🟩 Multipart Upload — MEMORY TIPS

Required for >100 MB
Recommended for >5 GB
Parallel upload = faster
If question says “improve upload performance” → Multipart.

🟩 Byte‑Range GET — MEMORY TIPS

Parallel download
Resume partial downloads
If question says “speed up large file downloads” → Byte‑Range GET.

🟩 Transfer Acceleration — MEMORY TIPS

Uses CloudFront edge network
Best for global uploads
If question says “improve upload speed from worldwide clients” → Transfer Acceleration.

🟩 S3 Requester Pays — MEMORY TIPS

Requester pays for data transfer + requests
Used for public datasets
If question says “owner should not pay for downloads” → Requester Pays.

🟩 S3 Storage Cost Optimization — MEMORY TIPS

Unknown access → Intelligent‑Tiering
Predictable cold → IA / One Zone IA
Long‑term archive → Glacier / Deep Archive
Many small objects → avoid Glacier (minimum billable size)
If question says “optimize cost for unpredictable access” → Intelligent‑Tiering.

⭐ SUPER‑FAST MASTER TABLE (SET 5)

Requirement	Correct Feature
Private S3 access without NAT	Gateway Endpoint
Private access to other AWS services	Interface Endpoint
User‑based permissions	IAM Policy
Cross‑account bucket access	Bucket Policy
Object‑level cross‑account	ACL
Faster uploads	Multipart Upload
Faster downloads	Byte‑Range GET
Global upload acceleration	Transfer Acceleration
Requester pays for downloads	Requester Pays
Cheapest unpredictable access	Intelligent‑Tiering

⭐ SET 6 — CLOUDFRONT + S3, CORS, SIGNED URLS, STATIC HOSTING, LAMBDA

🟩 CloudFront + S3 — MEMORY TIPS

CloudFront = global CDN for S3
Reduces latency
Protects S3 with Origin Access Control (OAC)
S3 bucket must block public access
If question says “secure S3 behind CDN” → CloudFront + OAC.

🟩 S3 CORS — MEMORY TIPS

Needed when browser accesses S3 from another domain
Allows cross‑origin GET/PUT
Configured at bucket level
If question says “browser blocked by CORS” → Enable CORS.

🟩 CloudFront Signed URLs — MEMORY TIPS

Restrict access to individual files
Short‑lived access
Used for private content
If question says “restrict access to one file via CDN” → Signed URL.

🟩 CloudFront Signed Cookies — MEMORY TIPS

Restrict access to multiple files
Better for websites with many assets
If question says “grant access to many files at once” → Signed Cookies.

🟩 S3 Static Website Hosting — MEMORY TIPS

Only works with public buckets
No HTTPS unless using CloudFront
Used for static sites (HTML/CSS/JS)
If question says “host static site cheaply” → S3 Website Hosting.

🟩 Lambda + S3 Events — MEMORY TIPS

Triggers on PUT, POST, COPY, DELETE
Cannot trigger on Glacier restore complete
One event per object (no overlapping prefixes)
If question says “process file on upload” → S3 → Lambda.

🟩 CloudFront Caching — MEMORY TIPS

TTL controls caching
Invalidation = expensive
Use cache‑busting (versioned filenames)
If question says “update content quickly” → versioned objects.

🟩 Origin Access Control (OAC) — MEMORY TIPS

Replaces OAI
Stronger security
Signs requests to S3
If question says “CloudFront must be ONLY access path” → OAC.

⭐ SUPER‑FAST MASTER TABLE (SET 6)

Requirement	Correct Feature
Secure S3 behind CDN	CloudFront + OAC
Browser blocked cross‑domain	CORS
Restrict access to one file	Signed URL
Restrict access to many files	Signed Cookies
Host static website	S3 Website Hosting
Trigger Lambda on upload	S3 Event Notifications
Fast global delivery	CloudFront Caching

⭐ SET 7 — ATHENA, REDSHIFT SPECTRUM, DATA LAKE, GLUE, LAKE FORMATION, PARTITIONING

🟩 Athena — MEMORY TIPS

Serverless SQL on S3
Pay per TB scanned
Uses Glue Data Catalog
Best for ad‑hoc queries
If question says “SQL on S3 without infrastructure” → Athena.

🟩 Redshift Spectrum — MEMORY TIPS

Redshift cluster required
Queries S3 external tables
Good for joining S3 + Redshift
If question says “extend Redshift to S3” → Spectrum.

🟩 Glue Data Catalog — MEMORY TIPS

Central metadata store
Used by Athena, Spectrum, EMR, Glue ETL

Athena cannot query S3 unless the table exists in the Data Catalog.
Redshift Spectrum reads external tables from the Data Catalog.

Stores tables, schemas, partitions
If question says “metadata for S3 data lake” → Glue Catalog.
It stores:
- Table definitions
- Schema (columns, types, partitions)
- Location of data in S3
- Crawler results
- Job bookmarks
- Version history

🟩 Lake Formation — MEMORY TIPS

Fine‑grained permissions on tables, columns, rows- A centralized security and governance service for S3‑based data lakes.

It manages:
- Table‑level permissions
- Column‑level permissions
- Row‑level filters
- Cross‑service access control (Athena, Glue, Redshift Spectrum, EMR)
It uses the Glue Data Catalog as the metadata store but adds security + governance on top.

Centralized data lake security
Works on top of Glue Catalog
If question says “central permissions for data lake” → Lake Formation.

🟩 S3 Partitioning — MEMORY TIPS

Reduces data scanned → reduces cost
Common pattern: year/month/day/
Queries only read relevant partitions
If question says “Athena query too expensive” → add partitions.

🟩 Parquet / ORC — MEMORY TIPS

Columnar formats
Compress well
Reduce Athena scan cost massively - Parquet and ORC are columnar, compressed, optimized formats that massively reduce Athena scan cost and speed up queries.
If question says “optimize Athena cost/performance” → Parquet.

🟩 Glue Crawlers — MEMORY TIPS

A Glue Crawler automatically detects schema, discovers new partitions, and keeps the Glue Data Catalog updated.

A crawler scans your S3 data, figures out:
- File format (CSV, JSON, Parquet, ORC)
- Columns & data types
- Partitions (e.g., year=2025/month=06/day=07)
- Table structure

Auto‑detect schema
Auto‑update partitions
Used for dynamic data lakes
If question says “automatically detect new partitions” → Crawler.

🟩 Athena Workgroups — MEMORY TIPS

Athena Workgroups let you control query costs, separate teams, and set usage limits. If the exam says “limit Athena spend” → Workgroups.

A Workgroup is like a separate environment inside Athena with its own:
- Query limits
- Budgets
- Encryption settings
- Query history
- Usage metrics

Control query costs
Separate teams
Apply limits + monitor usage
If question says “limit Athena spend” → Workgroups.

⭐ SUPER‑FAST MASTER TABLE (SET 7)

Requirement	Correct Feature
SQL on S3, serverless	Athena
Extend Redshift to S3	Spectrum
Metadata for S3 tables	Glue Catalog
Central data lake permissions	Lake Formation
Reduce Athena cost	Partitioning
Best file format for analytics	Parquet
Auto‑detect schema	Glue Crawlers
Control Athena spend	Workgroups

⭐ SET 8 — EMR, KINESIS, REDSHIFT COPY, DATA LAKE PATTERNS

🟩 EMR + S3 — MEMORY TIPS

S3 = data lake, EMR = compute
EMRFS supports consistent view
EMR clusters can be transient (terminate after job)
If question says “separate storage + compute” → EMR + S3.

🟩 Kinesis → S3 — MEMORY TIPS

Use Firehose to deliver streaming data to S3
Supports buffering, compression, transformation
If question says “stream → S3 automatically” → Firehose.

🟩 Redshift COPY from S3 — MEMORY TIPS

Fastest way to load data into Redshift
Requires manifest for multiple files
Best with Parquet or compressed files
If question says “load large data into Redshift quickly” → COPY.

🟩 Redshift UNLOAD to S3 — MEMORY TIPS

Export query results to S3
Parallel, fast
Good for data lake integration
If question says “export Redshift data to S3” → UNLOAD.

🟩 Data Lake Best Practices — MEMORY TIPS

Store raw → curated → analytics layers
Use Parquet for analytics
Use partitioning for cost reduction
Use Glue Catalog for metadata
If question says “optimize S3 data lake” → Parquet + partitions.

🟩 Firehose Transformations — MEMORY TIPS

Lambda transforms data before S3
Supports JSON → Parquet conversion
If question says “convert streaming data before storing” → Firehose transform.

🟩 Athena + S3 Analytics Pattern — MEMORY TIPS

Serverless SQL
Best for ad‑hoc queries
Cost = data scanned
Reduce cost with Parquet + partitions
If question says “query S3 without cluster” → Athena.

🟩 EMR vs Athena — MEMORY TIPS

EMR = heavy ETL, Spark, Hadoop
Athena = ad‑hoc SQL
If question says “big ETL job” → EMR
If question says “quick SQL on S3” → Athena.

⭐ SUPER‑FAST MASTER TABLE (SET 8)

Requirement	Correct Feature
Compute on S3 data lake	EMR + S3
Stream → S3	Firehose
Fast load into Redshift	COPY
Export from Redshift	UNLOAD
Optimize data lake	Parquet + Partitions
Transform streaming data	Firehose Transform
SQL on S3	Athena
Heavy ETL	EMR

⭐ HYBRID CONNECTIVITY — EXAM MEMORY TIPS

🟩 Site‑to‑Site VPN — MEMORY TIPS

Cheap, quick, IPsec
Works over internet → not guaranteed latency
Good for backup to Direct Connect
Supports 2 tunnels (HA)
If question says “fast setup” or “backup link” → VPN.

🟩 Direct Connect (DX) — MEMORY TIPS

Private, dedicated fiber
Low latency, consistent performance
Not encrypted by default
Takes weeks to provision
If question says “consistent latency” → DX.

🟩 Virtual Private Gateway (VGW) — MEMORY TIPS

Used for VPN and Private VIF
Connects one VPC
No transitive routing
If question says “DX to a single VPC” → VGW + Private VIF.

🟩 Private VIF — MEMORY TIPS

DX → one VPC via VGW
No transitive routing
If question says “DX to one VPC only” → Private VIF.

🟩 Transit Gateway (TGW) — MEMORY TIPS

Connects many VPCs + VPN + DX
Central router
Supports transitive routing
If question says “hub‑and‑spoke” → TGW.

🟩 Direct Connect Gateway (DXGW) — MEMORY TIPS

DX → multiple VPCs (even cross‑region)
Requires Transit VIF
No transitive routing by itself
If question says “DX to many VPCs” → DXGW.

🟩 Transit VIF — MEMORY TIPS

DX → DXGW → TGW → many VPCs
Best for enterprise multi‑VPC, multi‑region
If question says “DX to many VPCs via TGW” → Transit VIF.

🟩 VPN + TGW — MEMORY TIPS

Scalable VPN hub
Supports thousands of sites
If question says “many branch offices via VPN” → TGW VPN.

🟩 DX + VPN (Hybrid HA) — MEMORY TIPS

DX = primary
VPN = backup
Classic exam pattern
If question says “high availability hybrid” → DX + VPN.

⭐ SUPER‑FAST MASTER TABLE (HYBRID CONNECTIVITY)

Requirement	Correct Feature
Quick, cheap hybrid link	VPN
Consistent low latency	Direct Connect
DX to one VPC	Private VIF + VGW
DX to many VPCs	DXGW
DX to many VPCs + transitive routing	Transit VIF + TGW
Central router for VPCs	TGW
Multi‑branch VPN hub	TGW VPN
HA hybrid	DX + VPN

⭐ ULTRA‑FAST EXAM TRIGGERS (MEMORIZE THESE)

“Low latency” → Direct Connect
“Backup link” → VPN
“DX to multiple VPCs” → DXGW
“DX to multiple VPCs + transitive” → Transit VIF + TGW
“Hub‑and‑spoke” → TGW
“Cross‑region DX” → DXGW
“Many branches” → TGW VPN
“Single VPC” → Private VIF + VGW

⭐ SET 10 — PRIVATELINK, PEERING, TGW, NAT, IGW, HYBRID DNS, FAILOVER

🟩 VPC Peering — MEMORY TIPS

One‑to‑one connection
No transitive routing
No overlapping CIDRs
Low latency, private
If question says “simple private connection between 2 VPCs” → Peering.

🟩 PrivateLink — MEMORY TIPS

Access services privately via ENI
Does NOT require VPC peering
No transitive routing
Best for SaaS / cross‑account services
If question says “expose service privately to other VPCs” → PrivateLink.
PrivateLink creates a private, point‑to‑point connection between:
- A service provider VPC (your service behind an NLB)
- A consumer VPC (other accounts, teams, or SaaS customers)
It does this by creating:
- VPC Endpoint Service (provider side)
- Interface Endpoints (ENIs) (consumer side)
No routing. No peering. No shared CIDRs. No transitive access.
PrivateLink uses ENIs with private IPs inside the consumer VPC. Traffic stays inside AWS’s private network.
No IGW No NAT No VPN No Direct Connect No public IPs
Just private ENI → NLB → service.

🟩 Transit Gateway (TGW) — MEMORY TIPS

Hub‑and‑spoke
Supports transitive routing
Connects VPCs + VPN + DX
If question says “many VPCs need to talk” → TGW.

🟩 NAT Gateway — MEMORY TIPS

Private subnets → Internet (outbound only)
No inbound connections
Managed, scalable
If question says “private subnet needs internet” → NAT Gateway.

🟩 Internet Gateway (IGW) — MEMORY TIPS

Public subnets
Bi‑directional internet access
Required for public IPs
If question says “public access to EC2” → IGW.

🟩 Egress‑Only IGW — MEMORY TIPS

IPv6 only
Outbound only
No inbound IPv6
If question says “IPv6 outbound only” → Egress‑Only IGW.

🟩 Route 53 Resolver Inbound Endpoint — MEMORY TIPS

On‑prem → AWS DNS
Allows on‑prem DNS servers to query VPC
If question says “on‑prem needs to resolve AWS private DNS” → Inbound Endpoint.

🟩 Route 53 Resolver Outbound Endpoint — MEMORY TIPS

AWS → on‑prem DNS
Forward queries to on‑prem DNS servers
If question says “VPC needs to resolve on‑prem domains” → Outbound Endpoint.

🟩 Hybrid DNS (Forwarding Rules) — MEMORY TIPS

Conditional forwarding
Example: corp.local → on‑prem DNS
aws.internal → VPC DNS
If question says “split DNS between AWS and on‑prem” → Hybrid DNS.

🟩 Failover Routing — MEMORY TIPS

Active‑passive
Health checks required
If question says “DR failover between regions” → Failover Routing.

🟩 Latency Routing — MEMORY TIPS

Routes to lowest latency region
If question says “global users need fastest region” → Latency Routing.

🟩 Geolocation Routing — MEMORY TIPS

Route based on user’s location
If question says “serve different content by country” → Geolocation.

⭐ SUPER‑FAST MASTER TABLE (SET 10)

Requirement	Correct Feature
Simple VPC‑to‑VPC	VPC Peering
Private access to a service	PrivateLink
Many VPCs, transitive	TGW
Private subnet → internet	NAT Gateway
Public subnet internet	IGW
IPv6 outbound only	Egress‑Only IGW
On‑prem → AWS DNS	Inbound Resolver
AWS → on‑prem DNS	Outbound Resolver
Split DNS	Hybrid DNS
DR failover	Failover Routing
Lowest latency region	Latency Routing

⭐ SET 11 — LOAD BALANCERS (ALB, NLB, GWLB)

🟩 Application Load Balancer (ALB) — MEMORY TIPS

Layer 7 (HTTP/HTTPS)
Path‑based + host‑based routing
WebSockets supported
Best for microservices, containers, HTTP apps
If question says “intelligent routing” → ALB.

🟩 Network Load Balancer (NLB) — MEMORY TIPS

Layer 4 (TCP/UDP)
Static IPs + 1 IP per AZ
Ultra‑low latency
Best for high‑performance, millions of requests
If question says “static IP” or “TCP performance” → NLB.

🟩 Gateway Load Balancer (GWLB) — MEMORY TIPS

For security appliances (firewalls, IDS/IPS)
Uses GENEVE protocol
Provides transparent insertion of appliances
If question says “deploy third‑party firewall at scale” → GWLB.

🟩 Cross‑Zone Load Balancing — MEMORY TIPS

ALB → always ON
NLB → optional, may incur charges
Distributes traffic evenly across AZs
If question says “uneven AZ traffic” → enable cross‑zone.

🟩 ALB Advanced Routing — MEMORY TIPS

Path‑based: /api/*, /images/*
Host‑based: app.example.com
Header‑based, method‑based
Weighted target groups
If question says “route based on URL or headers” → ALB.

🟩 NLB Health Checks — MEMORY TIPS

TCP, HTTP, HTTPS
Faster failover than ALB
If question says “fast failover for TCP apps” → NLB.

🟩 ALB vs NLB — MEMORY TIPS

ALB = Layer 7, smart routing
NLB = Layer 4, static IP, extreme performance
If question says “smart routing” → ALB
If question says “static IP” → NLB.

🟩 GWLB vs NLB — MEMORY TIPS

GWLB = security appliances
NLB = TCP/UDP performance
If question says “firewall fleet” → GWLB.

🟩 Target Groups — MEMORY TIPS

ALB → HTTP/HTTPS
NLB → IP, instance, ALB
GWLB → appliance endpoints
If question says “route to Lambda” → ALB supports Lambda targets.

🟩 Sticky Sessions — MEMORY TIPS

ALB + NLB support stickiness
Based on cookies (ALB) or source IP (NLB)
If question says “session affinity” → enable stickiness.

⭐ SUPER‑FAST MASTER TABLE (SET 11)

Requirement	Correct Feature
Intelligent HTTP routing	ALB
Static IP, TCP/UDP	NLB
Deploy firewalls/IDS	GWLB
Even traffic across AZs	Cross‑Zone LB
Route by path/host/header	ALB Advanced Routing
Fast TCP failover	NLB Health Checks
Session affinity	Sticky Sessions

Got you—so you want it like this:

Auto Scaling Group — MEMORY TIPS
Target Tracking — MEMORY TIPS
…and under each, ~10 sharp exam points.

Let’s do that properly for SET 12–16. I’ll keep each bullet short but meaningful.

⭐ SET 12 — Auto Scaling

🟩 Auto Scaling Group — MEMORY TIPS

Maintains capacity: Always tries to keep desired capacity running.
Health checks: Can use EC2 or ALB health checks to replace bad instances.
Multi‑AZ: Best practice—spread across multiple AZs for HA.
Scaling boundaries: Uses min, max, desired capacity.
Self‑healing: Terminates unhealthy instances and launches new ones automatically.
Launch template/config: Defines AMI, instance type, security groups, etc.
Integration: Commonly fronted by ALB; targets are in target groups.
Termination policy: Default—oldest launch config, then AZ rebalancing.
Lifecycle hooks: Let you run custom actions (e.g., config, registration) on launch/terminate.
Spot + On‑Demand: Can mix instance types and purchase options for cost optimization.

🟩 Target Tracking — MEMORY TIPS

Most recommended: Default choice for dynamic scaling in exams.
Metric based: Keeps a metric (e.g., CPU 50%) near a target value.
Automatic math: You don’t define step sizes—ASG calculates.
Fast to configure: Minimal parameters—great for “simple scaling” questions.
Supports custom metrics: Can track app‑level metrics via CloudWatch.
Cool‑down handled: Uses built‑in cooldown logic; less manual tuning.
Scale in/out: Works both ways based on metric deviation.
Good for unpredictable load: Automatically adapts to changes.
Per‑target metric: Often used with ALB request count per target.
Exam keyword: “Keep CPU around X%” → Target Tracking.

🟩 Step Scaling — MEMORY TIPS

Threshold‑based: Different actions for different alarm levels.
Multiple steps: Example: CPU > 60% add 1, > 80% add 3.
Manual sizing: You decide how many instances to add/remove.
Uses CloudWatch alarms: Each step tied to alarm thresholds.
More control: Good when you want aggressive scaling at high load.
Scale‑in/out symmetry: Can define separate steps for scale‑in.
Requires tuning: More parameters than Target Tracking.
Not “keep at X%”: That’s Target Tracking, not Step.
Exam keyword: “Scale differently at different CPU levels” → Step Scaling.
Good for bursty workloads: When you know how much capacity each step needs.

🟩 Scheduled Scaling — MEMORY TIPS

Time‑based: Triggered at specific times (cron‑like).
Predictable patterns: Office hours, business hours, batch windows.
No metric needed: Works even without CloudWatch metrics.
Pre‑warm capacity: Scale up before known traffic spikes.
Scale down off‑hours: Save cost at night/weekends.
Combines with dynamic: Can use with Target Tracking/Step.
Timezone awareness: Be careful with region/timezone in real life.
Exam keyword: “Known daily spike at 9 AM” → Scheduled Scaling.
Good for batch jobs: Nightly processing windows.
Not reactive: It doesn’t respond to unexpected spikes.

🟩 Warm Pools — MEMORY TIPS

Pre‑initialized instances: Kept stopped or running, ready to join ASG.
Reduce cold start: Faster scale‑out because boot/config already done.
Stateful apps: Helpful when startup is heavy (agents, caches, etc.).
Capacity types: Can keep instances Stopped, Running, or Hibernated.
Cost vs speed trade‑off: Running = fastest, most expensive.
Works with lifecycle hooks: Pre‑warm, then move to InService.
Exam keyword: “Reduce scale‑out latency” → Warm Pool.
Good for spiky workloads: Where you know spikes will come but not exactly when.
Separate from desired capacity: Warm pool is extra, not counted as in‑service.
Not for scale‑in: It optimizes scale‑out, not scale‑in behavior.

🟩 Launch Templates — MEMORY TIPS

Preferred over configs: Newer, more features than Launch Configs.
Versioning: Can have multiple versions and roll out gradually.
Mixed instances: Supports multiple instance types and purchase options.
Required for some features: E.g., TGP, Spot allocation strategies.
Reusable: Can be used by ASG, Spot Fleet, EC2 directly.
Supports network settings: Subnets, security groups, etc.
Supports tags: Tag instances and volumes at launch.
Exam keyword: “Use multiple instance types in ASG” → Launch Template.
Launch Configs are legacy: No versioning, fewer features.
Immutable versions: You can pin ASG to a specific template version.

⭐ SET 13 — Route 53 & Global Networking

🟩 Weighted Routing — MEMORY TIPS

Traffic split: Route X% to one endpoint, Y% to another.
Blue/green: Gradual rollout of new version.
Canary releases: Send small % to new stack first.
Weights are relative: 1:9 = 10% / 90%.
Health checks: Unhealthy endpoints removed from responses.
Works globally: Not region‑bound.
No latency awareness: Purely weight‑based.
Good for migrations: Move traffic slowly between regions.
Exam keyword: “Gradually shift traffic” → Weighted.
Can combine with other types: But exam usually keeps it simple.

🟩 Latency Routing — MEMORY TIPS

Chooses region with lowest latency to user.
Uses AWS latency measurements, not your own.
Great for multi‑region active‑active.
Health checks: Only healthy endpoints used.
User‑based: Different users may hit different regions.
Not geo‑based: That’s Geolocation/Geoproximity.
Exam keyword: “Send users to closest/fastest region” → Latency.
Works with ALB/NLB/EC2/ELB.
Good for global apps: Multi‑region deployments.
No traffic weighting: That’s Weighted Routing.

🟩 Failover Routing — MEMORY TIPS

Active‑passive: Primary + secondary.
Health checks mandatory on primary.
If primary fails → Route to secondary.
Used for DR: Region or on‑prem failover.
Simple pattern: One main, one backup.
Can be nested with other policies (but exam rarely goes deep).
Exam keyword: “DR failover between regions” → Failover.
Secondary can be S3 static site for DR landing page.
Health check can be on HTTP endpoint or other.
Not for load sharing: That’s Weighted/Multi‑Value.

🟩 Geolocation Routing — MEMORY TIPS

Route by user’s location (country/continent).
Compliance / localization: Different content per region.
Default location: For unmatched users.
Good for legal restrictions: E.g., EU vs US content.
Not latency‑based: That’s Latency Routing.
Exam keyword: “Serve different content by country” → Geolocation.
Can block regions: Route them to “no service” endpoint.
DNS‑level decision: Based on resolver IP.
Static mapping: No dynamic performance logic.
Useful for language‑specific sites.

🟩 Global Accelerator — MEMORY TIPS

Static anycast IPs fronting multiple endpoints.
Improves TCP/UDP performance globally.
Uses AWS edge network, not DNS tricks.
Health‑based routing to nearest healthy endpoint.
Faster failover than DNS (seconds vs TTL).
Supports ALB, NLB, EC2, EIP as endpoints.
Good for non‑HTTP protocols too.
Exam keyword: “Static IP + global performance” → Global Accelerator.
Not a CDN: That’s CloudFront (HTTP caching).
Works well with multi‑region active‑active.

⭐ SET 14 — Containers (ECS, EKS, Fargate)

🟩 ECS on EC2 — MEMORY TIPS

You manage EC2 cluster (capacity, patching).
Use Auto Scaling for cluster capacity.
Cheaper if well‑utilized and reserved/spot.
More control: Custom AMIs, agents, sidecars.
Integrates with ALB via target groups.
Task placement strategies: spread, binpack, random.
Good for lift‑and‑shift containerization.
Exam keyword: “Need control over underlying instances” → ECS EC2.
Requires ECS agent on instances.
Scaling is two‑layer: cluster scaling + service scaling.

🟩 ECS Fargate — MEMORY TIPS

Serverless containers: No EC2 to manage.
Pay per vCPU + memory per task.
Great for spiky or unpredictable workloads.
No SSH access to underlying hosts.
Simpler ops: Just define task + service.
Integrates with ALB same as EC2 mode.
Good for microservices with variable load.
Exam keyword: “No servers / no cluster management” → Fargate.
Supports ECS & EKS (Fargate profiles).
Higher cost per unit vs well‑tuned EC2, but lower ops overhead.

🟩 EKS (Kubernetes) — MEMORY TIPS

Managed control plane (API server, etcd).
You manage worker nodes (unless Fargate).
Best when Kubernetes is a requirement.
Integrates with ALB via ingress controllers.
More complex than ECS, but portable skills.
Supports standard K8s tooling (kubectl, Helm).
Good for multi‑cloud / on‑prem K8s alignment.
Exam keyword: “Must use Kubernetes” → EKS.
Control plane billed separately.
Can use Fargate for serverless pods.

🟩 ECR — MEMORY TIPS

Private container registry managed by AWS.
Stores Docker/OCI images.
Integrates with ECS/EKS seamlessly.
Supports image scanning (vulnerability).
Can replicate across regions.
IAM‑based access control.
Encrypted at rest.
Exam keyword: “Where to store container images?” → ECR.
Supports lifecycle policies to clean old images.
Can be used by on‑prem if networked.

⭐ SET 15 — Serverless (Lambda, API Gateway, EventBridge)

🟩 Lambda — MEMORY TIPS

Max 15 minutes runtime.
Scales per request automatically.
Billed per ms + memory.
Cold starts when new execution environment created.
Supports many runtimes (Python, Node, Java, etc.).
Integrates with S3, DynamoDB, Kinesis, EventBridge, API Gateway.
Environment variables for config.
Concurrency limits can be set (account + function).
Provisioned concurrency reduces cold starts.
Exam keyword: “Run code without managing servers” → Lambda.

🟩 API Gateway REST vs HTTP — MEMORY TIPS

REST API: Full features—API keys, usage plans, advanced auth, request/response mapping, caching.
HTTP API: Cheaper, simpler—good for Lambda + HTTP backends.
Both are fully managed and scale automatically.
Custom domain names supported.
Can integrate with Lambda, ALB, HTTP endpoints.
Supports throttling and WAF integration.
REST better for complex enterprise APIs.
HTTP better for cost‑sensitive simple APIs.
Exam keyword: “Low‑cost simple API” → HTTP API.
“Full control, transformations, legacy features” → REST API.

🟩 EventBridge — MEMORY TIPS

Event bus for routing events between services.
Pattern‑based rules (source, detail‑type, etc.).
Integrates with many AWS services + SaaS.
Decouples producers and consumers.
Supports scheduled events (cron).
Replaces many CloudWatch Events use cases.
Targets include Lambda, SQS, Step Functions, etc.
Schema registry for event structure.
Exam keyword: “Event‑driven integration between services” → EventBridge.
Not a queue: That’s SQS.

⭐ SET 16 — Security (IAM, KMS, WAF, Shield, GuardDuty)

🟩 IAM Roles — MEMORY TIPS

Used by AWS services (EC2, Lambda, ECS) to access other services.
Temporary credentials via STS.
No long‑lived keys on instances.
Attached to resources, not users.
Cross‑account access via role assumption.
Best practice vs embedding keys.
Exam keyword: “EC2 needs S3 access securely” → IAM Role.
Can use permission boundaries to limit delegated roles.
Trust policy defines who can assume the role.
Inline + managed policies define permissions.

🟩 KMS & Key Policies — MEMORY TIPS

CMKs control encryption for many services (S3, EBS, RDS, etc.).
Key policy is primary control—IAM alone not enough.
Grants allow temporary cross‑account use.
Customer managed keys vs AWS managed keys.
Rotation: Automatic for some keys (1 year).
CloudTrail logs KMS usage.
Cross‑account encryption needs key policy + IAM + resource policy.
Exam keyword: “Access denied using KMS key” → check key policy.
SSE‑KMS can throttle at high request rates.
S3 Bucket Keys reduce KMS calls and cost.

🟩 WAF — MEMORY TIPS

Protects ALB, API Gateway, CloudFront.
Blocks SQLi, XSS, bad patterns.
Uses Web ACLs with rules.
Managed rule groups for common threats.
Rate‑based rules for basic DDoS‑like patterns.
Exam keyword: “Protect web app from SQL injection” → WAF.
Layer 7 protection, not network‑level.
Integrates with Shield Advanced for more protection.
Can block by IP, country, headers, URI.
Logs to Kinesis Firehose / CloudWatch.

🟩 Shield Advanced — MEMORY TIPS

DDoS protection for CloudFront, Route 53, ALB, NLB, Global Accelerator.
24/7 DDoS response team.
Cost protection for DDoS‑related scaling.
More advanced detection than standard Shield.
Subscription‑based, enterprise feature.
Exam keyword: “Enterprise DDoS protection” → Shield Advanced.
Integrates with WAF for L7 + L3/4 protection.
Global coverage.
Useful for mission‑critical public endpoints.
Standard Shield is always on, free, but basic.

🟩 GuardDuty — MEMORY TIPS

Threat detection service.
Analyzes CloudTrail, VPC Flow Logs, DNS logs.
Finds anomalies, compromised IAM, crypto‑mining, etc.
No agents required.
Regional service.
Findings integrated with Security Hub.
Exam keyword: “Detect suspicious activity in AWS accounts” → GuardDuty.
Does NOT block traffic—just detects.
Pay per data analyzed.
Turn on per account/region (or via org).

⭐ SET 17 — RDS / AURORA

🟩 RDS — MEMORY TIPS

Managed DB: backups, patching, monitoring handled by AWS.
Multi‑AZ = synchronous replication (HA, not scaling).
Read Replicas = asynchronous (scaling, not HA).
Automated backups stored in S3; PITR supported.
Storage types: GP3, IO‑Optimized, Magnetic (legacy).
RDS cannot scale writes horizontally.
Failover happens automatically in Multi‑AZ.
RDS Proxy reduces connection storms.
Encryption uses KMS; cannot enable later (must snapshot‑restore).
IAM Authentication supported for MySQL/Postgres.

🟩 Aurora — MEMORY TIPS

6 copies across 3 AZs (2‑2‑2).
Failover in <30 seconds.
Reader endpoint load‑balances read replicas.
Storage auto‑scales up to 128 TB.
Aurora Serverless v2 auto‑scales instantly.
Faster replication (<10 ms).
Backtrack = rewind DB without restore.
Global Database = <1 sec cross‑region replication.
Parallel query for analytics.
More expensive but higher performance than RDS.

⭐ SET 18 — DYNAMODB

🟩 DynamoDB Core — MEMORY TIPS

Partition key determines data distribution.
Hot partition = uneven key distribution.
RCU/WCU define throughput; On‑Demand removes planning.
Strong vs eventual consistency (default eventual).
Streams capture item‑level changes.
TTL auto‑deletes items.
GSIs = flexible queries; LSIs = same partition key.
Transactions supported (ACID).
DAX = in‑memory read cache.
Export to S3 for analytics (Glue → Athena).
A corporation relies on AWS DynamoDB tables to store vital data. An IT manager accidentally removed one of these tables, leading to significant data loss and business disruption. To prevent similar issues in the future, what solution should the company adopt that minimizes operational complexity?

DynamoDB deletion protection prevents accidental table deletion entirely, directly addressing the root cause with a single-click enablement per table. No ongoing management, backups, or automation required.

A business conducts weekly trials lasting 4 hours on an application that utilizes a DynamoDB table. The business understands the frequency of read and write operations required by the application during these tests. No other use cases currently employ DynamoDB. A solutions architect must devise a cost-efficient strategy for the table. What approach should be taken?

Opt for provisioned mode and set the read and write capacity as needed
Correct because the workload is predictable and limited to weekly 4‑hour trials.
Provisioned mode allows the architect to configure the exact read/write capacity units required for the test window, avoiding unnecessary costs outside of those hours.
This is more cost‑efficient than on‑demand mode, which charges per request and is better suited for unpredictable traffic.
Reserved capacity (Options C and D) would lock the business into long‑term commitments, which is unnecessary given the short, infrequent usage.

Incorrect

🟩 DAX — MEMORY TIPS

Fully managed in‑memory cache.
Microsecond reads.
API‑compatible with DynamoDB.
Great for read‑heavy workloads.
Does NOT improve writes.
Reduces hot partition impact.
Cluster of nodes (multi‑AZ).
TTL respected.
No schema changes needed.
Exam keyword: “minimal code changes + faster reads”.

⭐ SET 19 — CACHING (ELASTICACHE, DAX)

🟩 ElastiCache Redis — MEMORY TIPS

In‑memory key‑value store.
Sub‑millisecond latency.
Supports pub/sub, sorted sets, streams.
Multi‑AZ with failover.
Best for leaderboards, sessions, caching.
Supports clustering (sharding).
Persistence optional (AOF/RDB).
Encryption in‑transit + at‑rest supported.
Not durable like RDS.
Exam keyword: “real‑time, low latency”.
Amazon ElastiCache for Redis is an excellent choice for handling session data and maintaining low-latency access to frequently accessed data such as shopping cart information. Redis is an in-memory data store that provides high performance, which is ideal for quick user session management, ensuring data is preserved across connectivity interruptions. Additionally, integrating with Amazon DynamoDB ensures that catalog data can be efficiently cached and updated monthly as needed.

🟩 ElastiCache Memcached — MEMORY TIPS

Simple distributed cache.
Multi‑node, no replication.
No persistence.
Horizontal scaling easy.
Good for object caching.
Stateless.
No failover.
No complex data types.
Lower cost.
Exam keyword: “simple cache, scale‑out”.

⭐ SET 20 — MESSAGING (SNS, SQS, MQ)

🟩 SNS — MEMORY TIPS

Pub/sub messaging.
Push‑based delivery.
Supports HTTP, Lambda, SQS, email, SMS.
Fan‑out pattern (SNS → SQS).
No message retention.
No ordering guarantees.
No consumer polling.
Good for broadcast notifications.
High throughput.
Exam keyword: “fan‑out”.

🟩 SQS — MEMORY TIPS

Pull‑based queue.
Standard = unlimited throughput, best‑effort ordering.
FIFO = strict ordering + dedupe.
Visibility timeout prevents double processing.
DLQ for failed messages.
Retention up to 14 days.
Long polling reduces cost.
No fan‑out (use SNS).
Scales automatically.
Exam keyword: “decouple producers/consumers”.

🟩 Amazon MQ — MEMORY TIPS

Managed ActiveMQ/RabbitMQ.
For legacy apps needing AMQP, MQTT, STOMP.
Not serverless.
Supports durable subscriptions.
Multi‑AZ brokers.
Migration path from on‑prem MQ.
Lower throughput than SQS/SNS.
Not designed for massive scale.
Exam keyword: “legacy protocols”.
Use when SQS/SNS cannot replace existing MQ.

⭐ SET 21 — MONITORING (CLOUDWATCH, X‑RAY)

🟩 CloudWatch — MEMORY TIPS

CloudWatch_is_for_monitoring — CloudWatch is AWS’s main tool for watching your systems. It tells you if something is slow, overloaded, failing, or behaving unusually.
CloudWatch_collects_metrics — It collects numbers like CPU %, memory, network traffic, latency, and error counts so you can see how healthy your application is.
CloudWatch_stores_logs — It gathers logs from EC2, Lambda, ECS, API Gateway, and more, so you can troubleshoot problems without logging into servers.
CloudWatch_sends_alerts — It can alert you when something goes wrong (via email, SMS, Slack, SNS) or even automatically fix issues (like restarting EC2).
CloudWatch_visualizes_data — It shows graphs and dashboards so you can see performance trends and spot problems quickly.
CloudWatch_queries_logs — With Log Insights, you can search millions of log lines instantly to find errors or slow parts of your code.
CloudWatch_automates_responses — Using EventBridge, CloudWatch can trigger actions when events happen (e.g., EC2 stops, IAM changes, Lambda errors).
CloudWatch_collects_system_metrics — The unified agent collects deeper OS metrics like memory, disk, and processes from EC2 or on‑prem servers.
CloudWatch_controls_log_retention — You choose how long logs stay stored (days, months, or forever), balancing cost and compliance.
CloudWatch_supports_cross_account — You can build dashboards that show data from multiple AWS accounts in one place.
CloudWatch_exam_keyword — In the exam, if the question says “monitor,” “alert,” “metrics,” or “logs,” the answer is almost always CloudWatch.
CloudWatch_cross_account_observability — It lets one AWS account see metrics, logs, traces, alarms, and dashboards from many other AWS accounts without manual setup.
CloudWatch_observability_setup — It works by deploying a CloudFormation stack in each source account, which automatically creates secure IAM roles and links them to the observing account.
CloudWatch_central_visibility — This gives a single “master view” of all CloudWatch data across accounts, making troubleshooting and monitoring much easier.

🟩 X‑Ray — MEMORY TIPS

Distributed tracing.
Shows service map.
Identifies slow segments.
Great for microservices.
Integrates with Lambda, ECS, API Gateway.
Sampling reduces cost.
Traces requests end‑to‑end.
Helps debug latency issues.
Shows cold starts in Lambda.
Exam keyword: “trace request path”.

⭐ SET 22 — VPC (Core Networking)

🟩 VPC — MEMORY TIPS

Regional, isolated network environment.
Subnets are AZ‑specific.
Public subnet = route to IGW.
Private subnet = route to NAT Gateway.
Security Groups = stateful.
NACLs = stateless.
VPC Flow Logs capture traffic metadata.
Default VPC comes with IGW + subnets.
Custom VPC = no IGW/NAT by default.
DNS hostnames must be enabled for EC2 public DNS.

🟩 VPC Peering — MEMORY TIPS

One‑to‑one connection between VPCs.
No transitive routing.
No overlapping CIDRs allowed.
Low latency, private.
Works cross‑region.
Uses route tables for connectivity.
Cannot use to access third VPC.
No centralized hub.
Good for simple two‑VPC architectures.
Exam keyword: “simple private connection”.

🟩 PrivateLink — MEMORY TIPS

Expose services, not networks.
Uses ENIs in consumer VPC.
No need for VPC peering.
No transitive routing.
Great for SaaS providers.
Works cross‑account.
Traffic stays on AWS backbone.
More secure than public endpoints.
Supports NLB/ALB as service endpoints.
Exam keyword: “access service privately”.

🟩 Transit Gateway — MEMORY TIPS

Hub‑and‑spoke architecture.
Supports transitive routing.
Connects VPCs + VPN + DX.
Scales to thousands of VPCs.
Route tables control segmentation.
Replaces complex peering meshes.
Multi‑region peering supported.
Centralized inspection possible.
High throughput backbone.
Exam keyword: “many VPCs need to talk”.

⭐ SET 23 — CloudFront (CDN)

🟩 CloudFront — MEMORY TIPS

Global CDN with edge locations.
Reduces latency for static/dynamic content.
Integrates with S3, ALB, API Gateway.
Supports caching with TTLs.
Signed URLs/Cookies for private content.
Origin Access Control (OAC) secures S3.
Geo‑restriction supported.
HTTP/2, HTTP/3 supported.
WAF integrates for security.
Exam keyword: “global low‑latency content delivery”.

🟩 CloudFront Signed URLs — MEMORY TIPS

Restrict access to one file.
Short‑lived access tokens.
Good for downloads, pay‑per‑view.
Uses CloudFront key pairs.
Works with S3 private buckets.
No need to expose S3 URLs.
TTL controls access window.
Can revoke by rotating keys.
Not ideal for many files.
Exam keyword: “single object access control”.

🟩 CloudFront Signed Cookies — MEMORY TIPS

Restrict access to many files.
Ideal for websites with multiple assets.
Same policy applies to all objects.
Uses policy + signature.
Works with OAC for S3.
No URL rewriting needed.
Good for authenticated portals.
TTL controls session.
Can combine with WAF.
Exam keyword: “multiple protected files”.

⭐ SET 24 — IAM (Identity & Access Management)

🟩 IAM Users — MEMORY TIPS

Long‑term credentials.
Should be minimized; prefer roles.
MFA recommended.
Access keys must be rotated.
Inline policies = user‑specific.
Managed policies = reusable.
Cannot assume roles by default.
Used for humans, not apps.
Password policies configurable.
Exam keyword: “human access”.

🟩 IAM Roles — MEMORY TIPS

Temporary credentials via STS.
Used by EC2, Lambda, ECS, etc.
Trust policy defines who can assume.
No long‑term keys.
Cross‑account access via role assumption.
More secure than embedding keys.
Can attach permission boundaries.
Supports session tags.
Used for SSO federation.
Exam keyword: “EC2 needs S3 access”.

🟩 IAM Policies — MEMORY TIPS

JSON documents defining permissions.
Identity‑based vs resource‑based.
Explicit deny overrides allow.
Wildcards allowed.
Condition keys refine access.
AWS managed vs customer managed.
Inline policies not reusable.
Policy evaluation logic: deny → allow.
Permissions boundary limits max allowed.
Exam keyword: “fine‑grained access control”.

⭐ SET 25 — KMS (Encryption & Key Management)

🟩 KMS CMKs — MEMORY TIPS

Customer‑managed or AWS‑managed.
Key policy is primary permission control.
IAM alone is not enough.
Automatic rotation optional.
Used by S3, EBS, RDS, Lambda, etc.
Grants allow temporary access.
CloudTrail logs all KMS usage.
Regional keys (except multi‑region keys).
Cannot export private key material.
Exam keyword: “Access denied → check key policy”.

🟩 KMS Multi‑Region Keys — MEMORY TIPS

Same logical key across regions.
Useful for multi‑region apps.
Replicated keys stay in sync.
Still region‑isolated for security.
Faster cross‑region failover.
Good for Aurora Global, DynamoDB Global.
Not auto‑replicated; you create replicas.
Same key ID across regions.
Supports encryption/decryption in each region.
Exam keyword: “multi‑region encryption”.

🟩 Envelope Encryption — MEMORY TIPS

KMS encrypts data keys, not data directly.
Data encrypted locally with DEK.
Reduces KMS API calls.
Faster performance.
Used by S3, EBS, RDS.
DEK stored encrypted alongside data.
Decrypt requires KMS.
Good for large objects.
Secure key lifecycle.
Exam keyword: “KMS encrypts data key”.

Absolutely, Savi — here are SET 26, SET 27, SET 28, SET 29, SET 30, each with 10‑tips‑per‑subtitle, in the exact same crisp exam‑memory style you prefer.

All topics: EC2, EBS, Networking Security, CloudTrail, Organizations & Control Tower
All bullets: ultra‑compressed, exam‑ready, zero fluff
All items include Guided Links.

⭐ SET 26 — EC2 (Compute)

🟩 EC2 — MEMORY TIPS

Instance families: M = general, C = compute, R = memory, I = storage.
Burstable T‑series uses CPU credits.
Placement groups: Cluster = low latency, Spread = HA, Partition = big data.
Instance metadata v2 = IMDSv2 (token‑based).
EC2 Hibernate saves RAM to EBS.
Dedicated Hosts = compliance, bring‑your‑own‑license.
Spot instances = 70–90% cheaper, interruptible.
ENI = network interface; can attach multiple.
User data runs once at launch.
EC2 Auto Recovery restarts instance on hardware failure.

🟩 EC2 Placement Groups — MEMORY TIPS

Cluster: same rack, low latency, HPC.
Spread: max 7 instances per AZ, high isolation.
Partition: big data (Hadoop, HDFS).
Cluster = performance; Spread = resilience.
Partition = failure‑domain isolation.
Cannot mix types in some cases.
Must launch together for best placement.
AZ‑specific behavior.
Spread best for critical small fleets.
Cluster best for 10Gbps+ networking.

⭐ SET 27 — EBS (Block Storage)

🟩 EBS — MEMORY TIPS

Volumes are AZ‑specific.
Snapshots stored in S3 (managed).
Snapshots incremental.
Encryption via KMS; cannot unencrypt later.
gp3 = baseline 3,000 IOPS + configurable.
io1/io2 = provisioned IOPS.
io2 Block Express = highest performance.
EBS‑optimized instances recommended.
Multi‑Attach for io1/io2 (clustered FS).
Restore from snapshot = lazy loading.

🟩 EBS Snapshots — MEMORY TIPS

Incremental backups.
Can copy cross‑region.
Used for AMI creation.
Fast snapshot restore for performance.
Snapshots encrypted if source encrypted.
Can share snapshots (unencrypted only).
Lifecycle policies automate retention.
Crash‑consistent, not app‑consistent.
Snapshot restore warms blocks on demand.
Good for DR replication.

⭐ SET 28 — Networking Security (NACL, SG, Firewall, GWLB)

🟩 Security Groups — MEMORY TIPS

Stateful.
Allow rules only.
Return traffic automatically allowed.
Attached to ENIs.
Can reference other SGs.
Default SG allows intra‑SG traffic.
No deny rules.
Good for instance‑level security.
Evaluated before NACLs.
Unlimited rules (soft limits).

🟩 NACLs — MEMORY TIPS

Stateless.
Allow + deny rules.
Evaluated in order.
Default NACL = allow all.
Custom NACL = deny all by default.
Good for subnet‑level filtering.
Must allow ephemeral ports.
No SG references.
Rules numbered 1–32766.
Use for coarse‑grained filtering.

🟩 Gateway Load Balancer — MEMORY TIPS

Deploys 3rd‑party firewalls at scale.
Uses GENEVE encapsulation.
Transparent insertion.
Auto‑scales appliance fleet.
Works with TGW.
Good for IDS/IPS.
Centralized inspection.
High availability built‑in.
Replaces manual firewall chaining.
Exam keyword: “firewall fleet”.

⭐ SET 30 — Organizations & Control Tower

🟩 AWS Organizations — MEMORY TIPS

Multi‑account management.
OU hierarchy for grouping.
SCPs restrict max permissions.
Consolidated billing.
Service control policies apply to accounts/OUs.
Deny overrides allow.
Tag policies enforce tagging standards.
Backup policies automate backups.
Guardrails via Control Tower.
Exam keyword: “multi‑account governance”.

🟩 Service Control Policies (SCPs) — MEMORY TIPS

Restrict maximum permissions.
Do NOT grant permissions.
Applied at OU or account level.
Root user also restricted.
Explicit deny always wins.
Must allow required services explicitly.
Useful for blocking regions.
Useful for blocking IAM changes.
Combine with IAM for final permissions.
Exam keyword: “prevent actions across accounts”.

🟩 Control Tower — MEMORY TIPS

Automates multi‑account setup.
Landing Zone creation.
Guardrails = preventive + detective.
preventive - Stop non‑compliant resources before creation. They block API calls at the Organization level.
Control Tower preventive controls can stop IAM roles/policies with “”* in inline or managed policy statements.
Preventive controls can block EC2 instance launches that assign a public IP (including CloudFormation).
CloudFormation cannot bypass Control Tower preventive controls — blocked API calls fail stack creation.
SCPs cannot inspect IAM policy JSON for “*”. They block actions, not content inside policies.
Config = detect + remediate after creation. Control Tower preventive =
Control Tower preventive = block before creation → required for exam scenarios asking “stop”.
Detective controls - Only monitor and report violations. They do NOT block CloudFormation.
Integrates with Organizations.
Preconfigured OUs (Sandbox, Prod).
Account Factory for provisioning.
Control Tower applies controls across all accounts in the Organization automatically.
Enforces governance best practices.
If a preventive control blocks an API call, the stack enters ROLLBACK — exam loves this detail.
Centralized logging + audit accounts.
Blueprint for enterprise onboarding.
Exam keyword: “automated multi‑account governance”.

Absolutely, Savi — here are SET 31, SET 32, SET 33, SET 34, SET 35, each with 10+ elaborated exam‑memory points per subtitle, beginner‑friendly but still crisp and exam‑oriented.

No templates needed here because this is not a certification‑steps question — this is deep AWS architecture content.

Let’s go.

⭐ SET 31 — CloudWatch Advanced

🟩 CloudWatch Metrics — MEMORY TIPS

Default EC2 metrics are 5‑minute; detailed monitoring gives 1‑minute.
Memory & disk metrics require CloudWatch Agent (not provided by default).
Custom metrics cost money — exam trap.
Metrics are regional; dashboards can be cross‑region.
Metric math lets you combine metrics (e.g., CPU + network).
Alarms can trigger SNS, Auto Scaling, EC2 actions.
Composite alarms reduce noise by combining multiple alarms.
High‑resolution metrics (1‑second) available for custom metrics.
CloudWatch retains metrics for 15 months.
Exam keyword: “Need memory metrics” → install CloudWatch Agent.

🟩 CloudWatch Logs — MEMORY TIPS

Stores logs from EC2, Lambda, API Gateway, VPC Flow Logs, etc.
Log retention is configurable (default = never expire).
Log Insights allows SQL‑like queries on logs.
Subscription filters stream logs to Lambda, Kinesis, or Firehose.
Encryption at rest via KMS.
Can export logs to S3 for long‑term retention.
Lambda logs automatically go to CloudWatch Logs.
VPC Flow Logs also stored here.
Cross‑account log sharing supported.
Exam keyword: “search logs quickly” → CloudWatch Logs Insights.

🟩 CloudWatch Events / EventBridge — MEMORY TIPS

EventBridge is the evolution of CloudWatch Events.
Event patterns match events from AWS services.
Targets include Lambda, SQS, SNS, Step Functions.
Supports scheduled (cron) events.
Integrates with SaaS providers (Zendesk, Datadog, etc.).
Decouples event producers and consumers.
Schema registry helps discover event structure.
Event buses: default, custom, partner.
Retry logic built‑in.
Exam keyword: “event‑driven architecture” → EventBridge.

⭐ SET 32 — Lambda Deep Dive

🟩 Lambda Execution Model — MEMORY TIPS

Lambda creates execution environments reused across invocations.
Cold start happens when a new environment is created.
Provisioned Concurrency reduces cold starts.
Max runtime = 15 minutes.
Memory size controls CPU allocation.
Environment variables store config.
/tmp storage = 512 MB (can be increased to 10 GB).
IAM role attached to Lambda controls permissions.
Lambda scales automatically per request.
Exam keyword: “cold start issue” → Provisioned Concurrency.

🟩 Lambda Triggers — MEMORY TIPS

S3 triggers on PUT/POST/COPY/DELETE.
DynamoDB Streams trigger Lambda for item changes.
Kinesis triggers require Lambda to checkpoint.
API Gateway triggers synchronous invocations.
EventBridge triggers asynchronous invocations.
SQS triggers batch messages.
SNS triggers fan‑out to Lambda.
CloudWatch Logs subscription filters trigger Lambda.
ALB can invoke Lambda directly (HTTP).
Exam keyword: “process file on upload” → S3 → Lambda.

🟩 Lambda Error Handling — MEMORY TIPS

Async invocations retry twice.
DLQ supported via SNS/SQS.
Kinesis/DynamoDB Streams retry until success or data expires.
API Gateway returns error to client.
CloudWatch Logs capture stack traces.
Lambda Destinations route success/failure events.
Timeout errors common — increase timeout or optimize code.
Memory errors → increase memory.
Concurrency throttling → increase concurrency limit.
Exam keyword: “capture failed events” → DLQ or Lambda Destinations.

⭐ SET 33 — API Gateway Deep Dive

🟩 REST API — MEMORY TIPS

Full‑featured API platform.
Supports request/response mapping templates.
Supports API keys + usage plans.
Integrates with Lambda, HTTP, VPC Link.
Caching available at stage level.
Supports WAF integration.
Can throttle per stage or per API key.
Custom domain names supported.
More expensive than HTTP API.
Exam keyword: “full control, transformations” → REST API.

🟩 HTTP API — MEMORY TIPS

Cheaper, faster, simpler.
Best for Lambda + HTTP backends.
No request/response mapping templates.
JWT authorizers supported.
No usage plans or API keys.
Custom domains supported.
Lower latency than REST API.
No caching.
Ideal for microservices.
Exam keyword: “low‑cost API” → HTTP API.

🟩 API Gateway Security — MEMORY TIPS

IAM auth for internal APIs.
Cognito User Pools for user authentication.
Lambda authorizers for custom logic.
WAF for L7 protection.
Resource policies restrict access by IP/VPC.
TLS enforced by default.
Throttling protects backend.
CORS must be configured manually.
API keys for rate limiting (REST only).
Exam keyword: “custom authentication logic” → Lambda Authorizer.

⭐ SET 34 — VPC Advanced

🟩 Advanced Routing — MEMORY TIPS

Route tables determine traffic flow.
Longest prefix match wins.
Blackhole routes occur when target missing.
Propagated routes from VPN/DX.
TGW route tables control segmentation.
VPC peering requires manual route entries.
PrivateLink does NOT require route changes.
IGW only for public subnets.
NAT Gateway only for private subnets.
Exam keyword: “transitive routing” → only TGW supports it.

🟩 Hybrid DNS — MEMORY TIPS

Inbound resolver = on‑prem → AWS DNS.
Outbound resolver = AWS → on‑prem DNS.
Conditional forwarding rules.
Split‑horizon DNS supported.
Private hosted zones only inside VPC.
Resolver endpoints are ENIs.
Multi‑VPC sharing supported.
DNSSEC supported for Route 53.
Exam keyword: “resolve on‑prem domain from VPC” → Outbound Endpoint.
Exam keyword: “on‑prem resolve private hosted zone” → Inbound Endpoint.

🟩 Hybrid Connectivity — MEMORY TIPS

VPN = quick, cheap, encrypted.
DX = consistent, private, not encrypted.
DX + VPN = HA hybrid.
Private VIF = DX → single VPC.
Transit VIF = DX → many VPCs via TGW.
DXGW = multi‑region VPC connectivity.
TGW = hub‑and‑spoke.
Peering = simple 1‑to‑1.
PrivateLink = service‑level access.
Exam keyword: “DX to multiple VPCs” → DXGW.

⭐ SET 35 — Multi‑Region Architectures

🟩 Active‑Active — MEMORY TIPS

Traffic served from multiple regions simultaneously.
Requires global routing (Latency/Geolocation).
Data must be replicated (Aurora Global, DynamoDB Global).
Stateless apps easiest to run active‑active.
Session stickiness avoided; use JWT or DynamoDB.
Failover is instant because both regions active.
Higher cost but highest availability.
Needs conflict resolution for writes.
Global Accelerator improves performance.
Exam keyword: “serve users from nearest region” → Active‑Active.

🟩 Active‑Passive — MEMORY TIPS

Primary region handles traffic.
Secondary region on standby.
Failover via Route 53 Failover Routing.
RDS cross‑region read replicas used for DR.
S3 CRR replicates objects.
DynamoDB Global Tables optional.
Lower cost than active‑active.
Recovery time depends on automation.
Good for DR compliance.
Exam keyword: “DR failover” → Active‑Passive.

🟩 Global Data Patterns — MEMORY TIPS

Aurora Global Database = <1 sec replication.
DynamoDB Global Tables = multi‑master.
S3 CRR = asynchronous replication.
ElastiCache cannot replicate cross‑region.
RDS read replicas cross‑region supported.
Kinesis cannot replicate cross‑region natively.
CloudFront caches globally.
Global Accelerator routes globally.
Multi‑region KMS keys simplify encryption.
Exam keyword: “multi‑region writes” → DynamoDB Global Tables.

Here you go, Savi — SET 36 to SET 40, each with 10+ elaborated exam‑memory points per subtitle, beginner‑friendly but still crisp and exam‑oriented.

This continues your full AWS exam‑cram series in the exact style you prefer.

⭐ SET 36 — EKS Deep Dive (Kubernetes on AWS)

🟩 EKS — MEMORY TIPS

Managed control plane — AWS runs API server & etcd; you manage worker nodes.
Worker nodes can be EC2 or Fargate (serverless pods).
Cluster Autoscaler scales worker nodes based on pending pods.
Horizontal Pod Autoscaler (HPA) scales pods based on CPU/memory/custom metrics.
Ingress Controller (ALB Ingress) exposes services externally.
EKS Node Groups simplify node lifecycle management.
EKS Fargate Profiles run pods without EC2 management.
IAM Roles for Service Accounts (IRSA) give fine‑grained pod‑level permissions.
EKS is complex — exam keyword: “must use Kubernetes”.
Networking via CNI plugin — each pod gets an ENI‑backed IP.
EKS upgrades require control plane + node group updates.

🟩 EKS Security — MEMORY TIPS

IAM + RBAC integration controls cluster access.
IRSA maps IAM roles to Kubernetes service accounts.
Security Groups for Pods supported with AWS CNI.
Private cluster = API server accessible only inside VPC.
Secrets encrypted with KMS via envelope encryption.
Network Policies restrict pod‑to‑pod traffic.
Audit logs can be sent to CloudWatch.
Node IAM roles separate from pod IAM roles.
Least privilege is critical for exam scenarios.
Exam keyword: “pod‑level IAM permissions” → IRSA.

⭐ SET 37 — ECS Deep Dive (EC2 + Fargate)

🟩 ECS EC2 Mode — MEMORY TIPS

You manage EC2 cluster capacity.
Use Auto Scaling for cluster scaling.
ECS Agent runs on EC2 instances.
Best for predictable workloads with reserved/spot instances.
Supports placement strategies (spread, binpack).
Integrates with ALB via target groups.
More control over networking, storage, AMIs.
Cheaper at scale if optimized.
Requires patching & maintenance.
Exam keyword: “need control over EC2” → ECS EC2.

🟩 ECS Fargate — MEMORY TIPS

Serverless containers — no EC2 management.
Pay per vCPU + memory per task.
Ideal for microservices with unpredictable load.
No SSH access to underlying hosts.
Integrates with ALB/NLB.
Simplifies security — no host patching.
Supports task‑level IAM roles.
Good for bursty workloads.
Higher cost per unit vs EC2.
Exam keyword: “no servers” → Fargate.

⭐ SET 38 — Step Functions (Orchestration)

🟩 Step Functions — MEMORY TIPS

Serverless workflow orchestrator.
Supports parallel, sequential, choice, retry, wait states.
Integrates with Lambda, ECS, DynamoDB, SNS, SQS, Glue, SageMaker.
Standard workflows = long‑running (up to 1 year).
Express workflows = high‑throughput, short‑lived.
Built‑in retry logic reduces code complexity.
Visual workflow debugging.
Great for ETL, ML pipelines, microservice orchestration.
IAM policies required per state.
Exam keyword: “orchestrate multiple Lambda functions” → Step Functions.

🟩 Step Functions Error Handling — MEMORY TIPS

Retry block handles transient errors.
Catch block routes failures to fallback states.
Can retry with exponential backoff.
Supports custom error types.
Express workflows retry automatically.
Good for flaky external APIs.
Reduces need for try/catch in Lambda.
Can send failures to SNS/SQS.
State machine execution logs in CloudWatch.
Exam keyword: “automatic retries” → Step Functions.

⭐ SET 39 — Glue (ETL, Data Catalog, Crawlers)

🟩 Glue ETL — MEMORY TIPS

Serverless Spark ETL engine.
Jobs written in Python/Scala.
Glue Studio for visual ETL.
Glue Job Bookmarks track processed data.
Glue Workers = compute units.
Glue can convert CSV → Parquet.
Integrates with S3, Redshift, RDS, DynamoDB.
Glue Job triggers via EventBridge.
Glue 4.0 supports latest Spark/Python.
Exam keyword: “serverless ETL” → Glue.

🟩 Glue Data Catalog — MEMORY TIPS

Central metadata store for S3 tables.
Used by Athena, Redshift Spectrum, EMR.
Stores schema, partitions, table definitions.
Glue Crawlers auto‑detect schema.
Versioning supported.
Lake Formation permissions built on top.
Supports partition projection.
Catalog is regional.
Can import Hive Metastore.
Exam keyword: “metadata for S3 data lake” → Glue Catalog.

⭐ SET 40 — Redshift & Kinesis

🟩 Redshift — MEMORY TIPS

Columnar storage optimized for analytics.
Massively Parallel Processing (MPP).
COPY command loads data from S3 fast.
UNLOAD exports data to S3.
Redshift Spectrum queries S3 external tables.
RA3 nodes separate compute & storage.
Concurrency Scaling adds temporary clusters.
Materialized views improve performance.
Workload Management (WLM) controls query queues.
Exam keyword: “petabyte‑scale analytics” → Redshift.

🟩 Kinesis Data Streams — MEMORY TIPS

Real‑time streaming ingestion.
Shards define throughput (1 MB/s in, 2 MB/s out).
Consumers read in parallel.
Retention up to 1 year.
Enhanced Fan‑Out = dedicated throughput per consumer.
Lambda can process streams.
Checkpointing required to avoid reprocessing.
Ordering guaranteed within a shard.
Scaling = add shards.
Exam keyword: “real‑time streaming ingestion” → Kinesis Streams.

🟩 Kinesis Firehose — MEMORY TIPS

Fully managed delivery to S3, Redshift, OpenSearch.
No shard management.
Supports buffering (size/time).
Supports Lambda transformations.
Converts JSON → Parquet/ORC.
Near‑real‑time, not real‑time.
Automatic scaling.
Great for log ingestion.
No replay capability.
Exam keyword: “deliver streaming data to S3 automatically” → Firehose.

Here you go, Savi — SET 41 to SET 45, each with 10+ elaborated, beginner‑friendly, exam‑focused points per subtitle, in the exact crisp style you prefer.

These sets cover:
Advanced SQS/SNS, EventBridge Deep, CloudFront Advanced, RDS/Aurora Advanced, DynamoDB Advanced.

Every bullet is written to help you recognize exam patterns instantly.

⭐ SET 41 — Advanced SQS / SNS

🟩 SQS Advanced — MEMORY TIPS

Visibility Timeout prevents multiple consumers from processing the same message; increase it for long tasks.
Long Polling (20 sec) reduces cost by avoiding empty responses — exam loves this.
DLQ (Dead‑Letter Queue) stores messages that fail repeatedly; used for debugging.
Message Retention up to 14 days — not for long‑term storage.
FIFO Queues guarantee ordering + deduplication; throughput = 300 msg/s (or 3,000 with batching).
Standard Queues = unlimited throughput, best‑effort ordering.
Batching reduces cost and increases throughput.
SQS does NOT push messages — consumers must poll.
Encryption via SSE‑KMS; throttling may occur if KMS limits hit.
Exam keyword: “decouple producers/consumers” → SQS.

🟩 SNS Advanced — MEMORY TIPS

Pub/Sub model — one message → many subscribers.
Supports HTTP, Lambda, SQS, SMS, email, mobile push.
Fan‑out pattern: SNS → multiple SQS queues.
Message filtering allows subscribers to receive only relevant messages.
No message retention — if subscriber offline, message lost (unless SQS).
FIFO SNS supports ordering + dedupe (new feature).
Delivery retries for HTTP endpoints.
Encryption at rest (KMS) + in transit (TLS).
Cross‑account publishing supported via topic policies.
Exam keyword: “broadcast to multiple systems” → SNS.

⭐ SET 42 — EventBridge Deep

🟩 EventBridge Core — MEMORY TIPS

EventBridge is an event bus, not a queue — events are routed, not stored long‑term.
Event Patterns match events based on fields (source, detail‑type, etc.).
Targets include Lambda, SQS, SNS, Step Functions, Kinesis, API Gateway.
Decouples microservices — producers don’t know consumers.
Schema Registry auto‑discovers event structure.
Retry logic built‑in for failed deliveries.
Event buses: default, custom, partner (SaaS).
Cross‑account event routing supported.
Scheduled events replace cron jobs.
Exam keyword: “event routing between services” → EventBridge.

🟩 EventBridge vs SQS vs SNS — MEMORY TIPS

EventBridge = routing + filtering + SaaS integration.
SNS = broadcast notifications (push).
SQS = durable queue (pull).
EventBridge = rules, SQS = buffer, SNS = fan‑out.
EventBridge supports complex filtering; SNS supports simple filtering.
SQS stores messages; EventBridge does not.
SNS + SQS = fan‑out with durability.
EventBridge integrates with SaaS (Zendesk, Datadog).
SQS FIFO = strict ordering; EventBridge has no ordering guarantee.
Exam keyword: “decouple + route + filter” → EventBridge.

⭐ SET 43 — CloudFront Advanced

🟩 CloudFront Advanced — MEMORY TIPS

Edge caching reduces latency globally.
Origin Access Control (OAC) secures S3 origins without public access.
Lambda@Edge modifies requests/responses at edge locations.
CloudFront Functions = ultra‑fast JS functions for lightweight logic.
Signed URLs/Cookies restrict access to premium content.
Geo‑restriction blocks countries/regions.
Origin Failover supports primary + secondary origins.
Field‑level encryption protects sensitive data.
HTTP/3 + QUIC supported for faster performance.
Exam keyword: “global caching + security” → CloudFront.

🟩 Lambda@Edge — MEMORY TIPS

Runs at CloudFront edge locations.
Can modify headers, cookies, URLs.
Great for A/B testing, redirects, auth.
Lower latency than Lambda in region.
Must deploy to us‑east‑1.
No VPC access.
Limited runtime support.
Good for SEO redirects.
Can block bots at edge.
Exam keyword: “modify request at edge” → Lambda@Edge.

⭐ SET 44 — RDS / Aurora Advanced

🟩 RDS Advanced — MEMORY TIPS

Multi‑AZ = synchronous replication for HA.
Read Replicas = asynchronous for scaling reads.
Cross‑region read replicas for DR.
RDS Proxy reduces connection storms.
Performance Insights helps identify slow queries.
Parameter Groups customize DB engine settings.
Option Groups enable features like SQL Server features.
Storage Auto‑Scaling expands storage automatically.
Backups stored in S3; PITR supported.
Exam keyword: “HA but not scaling” → Multi‑AZ.

🟩 Aurora Advanced — MEMORY TIPS

6 copies across 3 AZs — highly durable.
Aurora Global Database replicates <1 sec cross‑region.
Backtrack rewinds DB without restore.
Parallel Query accelerates analytics.
Serverless v2 scales instantly.
Reader Endpoint load‑balances read replicas.
Cluster Volume auto‑scales to 128 TB.
Fast failover (<30 seconds).
Storage‑compute separation improves performance.
Exam keyword: “high performance + high availability” → Aurora.

⭐ SET 45 — DynamoDB Advanced

🟩 DynamoDB Advanced — MEMORY TIPS

Partition key design determines performance — avoid hot keys.
GSIs allow flexible queries; LSIs share partition key.
On‑Demand mode removes capacity planning.
Adaptive capacity automatically handles uneven workloads.
DynamoDB Streams capture item changes for Lambda.
Transactions provide ACID guarantees.
DAX provides microsecond caching.
TTL auto‑expires items.
Export to S3 for analytics.
Exam keyword: “high‑scale NoSQL with predictable performance” → DynamoDB.

🟩 DynamoDB Global Tables — MEMORY TIPS

Multi‑region, multi‑master replication.
Writes accepted in any region.
Conflict resolution = last writer wins.
Great for global apps with low latency.
Requires identical table schema in all regions.
Streams used for replication.
Automatic failover between regions.
Strong consistency only in same region.
Good for gaming, IoT, global apps.
Exam keyword: “multi‑region active‑active NoSQL” → Global Tables.

Here you go, Savi — SET 46 to SET 50, each with 10+ elaborated, beginner‑friendly, exam‑focused points per subtitle, in the exact crisp style you prefer.

All topics: Kinesis Advanced, Redshift Advanced, VPC Security Deep, CloudFront Security, Lambda Scaling Deep
All bullets include Guided Links exactly as required.

⭐ SET 46 — Kinesis Advanced

🟩 Kinesis Data Streams — Advanced MEMORY TIPS

Shards = throughput units — 1 MB/s write, 2 MB/s read; scaling = add shards.
Enhanced Fan‑Out gives each consumer 2 MB/s dedicated throughput, avoiding shared limits.
Consumers must checkpoint using DynamoDB to avoid reprocessing.
Ordering guaranteed only within a shard — exam trap.
Retention up to 1 year for replay; default 24 hours.
Hot shard occurs when partition key not distributed — fix by randomizing keys.
Lambda consumers scale with number of shards (1 Lambda per shard).
Provisioned vs On‑Demand Streams — On‑Demand auto‑scales without shard management.
Data encryption via KMS; throttling possible if KMS limits hit.
Exam keyword: “real‑time streaming with ordering” → Kinesis Streams.

🟩 Kinesis Firehose — Advanced MEMORY TIPS

Fully managed — no shards, no scaling management.
Delivers to S3, Redshift, OpenSearch, HTTP endpoints.
Buffering (size/time) controls delivery frequency.
Lambda transforms allow JSON → Parquet/ORC conversion.
Near‑real‑time, not real‑time (1–60 sec delay).
Compression (GZIP, Snappy) reduces S3 cost.
Dynamic partitioning supports S3 folder structures.
No replay — once delivered, cannot reprocess.
Automatic scaling based on incoming throughput.
Exam keyword: “deliver streaming data to S3 automatically” → Firehose.

⭐ SET 47 — Redshift Advanced

🟩 Redshift Core — Advanced MEMORY TIPS

Columnar storage improves analytical query performance.
MPP architecture distributes queries across nodes.
Sort keys improve query speed by reducing scanned blocks.
Distribution styles (KEY, EVEN, ALL) control data placement.
COPY command loads data in parallel from S3 — fastest ingestion.
UNLOAD exports query results to S3.
Spectrum queries S3 external tables without loading data.
RA3 nodes separate compute & storage for cost efficiency.
Concurrency Scaling adds temporary clusters for peak load.
Exam keyword: “petabyte‑scale analytics with MPP” → Redshift.

🟩 Redshift Performance — MEMORY TIPS

Vacuum reclaims space and sorts data — needed after heavy deletes.
Analyze updates table statistics for query planner.
Materialized views speed up repeated queries.
Result caching returns cached results for identical queries.
WLM (Workload Management) controls query queues.
Compression encoding reduces storage + improves speed.
Short query acceleration prioritizes small queries.
Spectrum offloads cold data to S3.
Distribution key should be chosen based on join patterns.
Exam keyword: “optimize Redshift performance” → Sort keys + dist keys.

⭐ SET 48 — VPC Security Deep

🟩 Security Groups — Deep MEMORY TIPS

Stateful — return traffic automatically allowed.
Allow rules only — no deny.
Attached to ENIs, not subnets.
Can reference other SGs for dynamic trust.
Default SG allows intra‑SG communication.
Good for instance‑level protection.
Evaluated before NACLs.
Unlimited rules (soft limits).
SGs apply to inbound + outbound.
Exam keyword: “stateful firewall at instance level” → SG.

🟩 NACLs — Deep MEMORY TIPS

Stateless — return traffic must be explicitly allowed.
Allow + deny rules supported.
Rules evaluated in order (lowest number first).
Default NACL = allow all; custom = deny all.
Good for subnet‑level filtering.
Must allow ephemeral ports for return traffic.
No SG references — IP‑based only.
Use for blocking specific IP ranges.
Good for compliance‑driven segmentation.
Exam keyword: “subnet‑level stateless filtering” → NACL.

🟩 Network Firewall — Deep MEMORY TIPS

Managed L3/L4/L7 firewall.
Supports Suricata rules for deep packet inspection.
Integrates with VPC routing and Transit Gateway.
Centralized inspection for many VPCs.
Scales automatically — no appliance management.
Good for egress filtering (block malicious domains).
Logs to S3/CloudWatch for analysis.
Replaces 3rd‑party firewall fleets.
Works with AWS Firewall Manager for org‑wide rules.
Exam keyword: “stateful inspection at scale” → Network Firewall.

⭐ SET 49 — CloudFront Security

🟩 CloudFront Security — MEMORY TIPS

Origin Access Control (OAC) locks S3 buckets to CloudFront only.
WAF integration protects against SQLi, XSS, bots.
Geo‑restriction blocks countries/regions.
Field‑level encryption protects sensitive form fields.
TLS termination at edge locations.
DDoS protection via AWS Shield (Standard or Advanced).
Signed URLs restrict access to single objects.
Signed Cookies restrict access to multiple objects.
Origin failover improves availability.
Exam keyword: “secure global content delivery” → CloudFront.

🟩 Lambda@Edge Security — MEMORY TIPS

Modify headers to enforce security policies (HSTS, CSP).
Block malicious user agents at edge.
Redirect HTTP → HTTPS globally.
Implement custom authentication at edge.
Remove sensitive headers before reaching origin.
Validate JWT tokens at edge.
Prevent hotlinking by checking referer header.
Rate‑limit based on IP.
Lower latency than regional Lambda.
Exam keyword: “security logic at edge” → Lambda@Edge.

⭐ SET 50 — Lambda Scaling Deep

🟩 Lambda Scaling — MEMORY TIPS

Lambda scales per request — no servers to manage.
Each new concurrent request = new execution environment.
Burst limits vary by region (e.g., 3,000 → then linear scaling).
Reserved Concurrency guarantees capacity for a function.
Account Concurrency Limit shared across all functions.
Provisioned Concurrency eliminates cold starts.
Cold starts occur when new environment created.
Warm starts reuse existing environment.
VPC‑enabled Lambdas create ENIs — slower cold starts (improved now).
Exam keyword: “predictable low‑latency Lambda” → Provisioned Concurrency.

🟩 Lambda Performance Optimization — MEMORY TIPS

Increase memory to increase CPU → faster execution.
Use Provisioned Concurrency for APIs.
Keep dependencies small (bundle only what’s needed).
Use Lambda Layers for shared libraries.
Avoid large initialization code.
Use async invocation for background tasks.
Use SQS batching to reduce invocations.
Use CloudWatch Logs Insights to find slow code.
Use ARM64 architecture for cost/performance.
Exam keyword: “reduce cold start impact” → Provisioned Concurrency + smaller packages.

Here you go, Savi — SET 51 to SET 55, each with 10+ elaborated, beginner‑friendly, exam‑focused points per subtitle, in the exact crisp style you prefer.

These sets cover:
Advanced SQS/SNS/Kinesis patterns, Lambda Scaling Deep, VPC Security Deep, S3 Cost Optimization, CloudFront Architectures.

Every bullet includes Guided Links so you can jump deeper instantly.

⭐ SET 51 — Advanced SQS / SNS / Kinesis Patterns

🟩 SQS Advanced Patterns — MEMORY TIPS

Decoupling pattern: Producer doesn’t wait for consumer; SQS absorbs spikes.
Fan‑out with durability: SNS → SQS queues → consumers; ensures no message loss.
Message batching: Reduce cost + increase throughput (up to 10 messages per batch).
Idempotent consumers: Required because SQS may deliver duplicates.
Visibility timeout tuning: Must be longer than processing time to avoid double‑processing.
DLQ isolation: Failed messages go to DLQ for debugging without blocking main queue.
FIFO strict ordering: Use MessageGroupId to maintain order per group.
Long polling: Reduces empty responses and cost; exam loves this.
SQS + Lambda: Lambda polls SQS automatically; batch size configurable.
Exam keyword: “buffer spikes + prevent overload” → SQS.

🟩 SNS Advanced Patterns — MEMORY TIPS

Fan‑out pattern: One message → many subscribers (SQS, Lambda, HTTP).
Message filtering: Subscribers only receive messages matching attributes.
FIFO SNS: Guarantees ordering + dedupe for event pipelines.
Cross‑account publishing: Topic policies allow external accounts to publish.
Retry logic: HTTP endpoints retried with exponential backoff.
Mobile push: SNS integrates with APNS/FCM for mobile notifications.
No retention: If subscriber offline, message lost (unless SQS used).
Encryption: SSE‑KMS for at‑rest encryption.
SNS + SQS = reliable fan‑out: Ensures no message loss.
Exam keyword: “broadcast to multiple systems” → SNS.

🟩 Kinesis Patterns — MEMORY TIPS

Real‑time ingestion: Streams handle millions of events per second.
Shard‑based scaling: Add shards to increase throughput.
Enhanced Fan‑Out: Dedicated throughput per consumer.
Replay capability: Retention up to 1 year for reprocessing.
Hot partition fix: Randomize partition keys to distribute load.
Lambda consumers: One Lambda per shard; scaling tied to shard count.
Firehose for delivery: Use Firehose for S3/Redshift/OpenSearch delivery.
Checkpointing: Prevents reprocessing; stored in DynamoDB.
On‑Demand Streams: Auto‑scale without shard management.
Exam keyword: “ordered real‑time streaming” → Kinesis Streams.

⭐ SET 52 — Lambda Scaling Deep

🟩 Lambda Concurrency — MEMORY TIPS

Concurrency = number of parallel executions.
Burst scaling: Region‑dependent initial burst (e.g., 3,000).
Reserved concurrency: Guarantees capacity for a function.
Account concurrency limit: Shared across all functions.
Provisioned concurrency: Pre‑warms environments → no cold starts.
Cold starts: Occur when new execution environment created.
Warm starts: Reuse existing environment → faster.
VPC Lambdas: ENI creation adds latency (improved now).
Async invocations: Retries twice automatically.
Exam keyword: “predictable low latency” → Provisioned Concurrency.

🟩 Lambda Scaling Patterns — MEMORY TIPS

SQS → Lambda: Lambda scales with queue depth; batch size reduces cost.
Kinesis → Lambda: One Lambda per shard; scaling limited by shard count.
API Gateway → Lambda: Scales instantly per request.
EventBridge → Lambda: Async scaling with retries.
S3 → Lambda: Triggers per object event; high concurrency possible.
Throttling: Happens when concurrency limit reached.
DLQ: Capture failed async events.
Lambda Destinations: Route success/failure to SQS/SNS/EventBridge.
Memory tuning: More memory = more CPU = faster execution.
Exam keyword: “Lambda scaling bottleneck with Kinesis” → shard count.

⭐ SET 53 — VPC Security Deep

🟩 Advanced SG/NACL Patterns — MEMORY TIPS

SG = stateful, NACL = stateless — exam trap.
SG references: Allow SG‑to‑SG trust without IPs.
NACL order matters: Lowest rule number wins.
Ephemeral ports: Must be allowed in NACL for return traffic.
SGs apply to ENIs, not subnets.
NACLs apply to subnets, not ENIs.
Default SG allows intra‑SG traffic.
Custom NACL denies all by default.
Use SGs for app‑level security, NACLs for subnet‑level filtering.
Exam keyword: “block specific IP range” → NACL.

🟩 Network Firewall / GWLB — MEMORY TIPS

Network Firewall: Managed L3/L4/L7 firewall with Suricata rules.
Centralized inspection: Works with Transit Gateway.
Egress filtering: Block malicious domains.
Scales automatically: No appliance management.
GWLB: Deploys 3rd‑party firewalls at scale.
GENEVE encapsulation for traffic forwarding.
Transparent insertion: No app changes needed.
High availability: Built‑in failover.
Firewall Manager: Org‑wide rule enforcement.
Exam keyword: “firewall fleet scaling” → GWLB.

⭐ SET 54 — S3 Cost Optimization

🟩 S3 Storage Classes — MEMORY TIPS

S3 Standard: Frequent access; high cost.
S3 IA: Lower cost; retrieval fee; 30‑day minimum.
S3 One Zone‑IA: Cheaper; single AZ; not for critical data.
S3 Glacier Instant Retrieval: Millisecond access; cheaper than IA.
S3 Glacier Flexible Retrieval: Minutes to hours; cheaper.
S3 Glacier Deep Archive: 12–48 hours; cheapest.
S3 Intelligent‑Tiering: Auto‑moves objects based on access patterns.
Lifecycle rules: Move objects to cheaper tiers automatically.
Delete incomplete multipart uploads to save cost.
Exam keyword: “unknown access pattern” → Intelligent‑Tiering.

🟩 S3 Optimization Patterns — MEMORY TIPS

Bucket Keys: Reduce KMS cost for SSE‑KMS.
Compression: Store compressed objects to reduce size.
Prefix optimization: S3 auto‑scales; no need for random prefixes anymore.
Multipart upload: Faster + resilient for large files.
Replication: Use CRR/SRR only when required (adds cost).
Requester Pays: Useful for public datasets.
S3 Select: Query only needed data; reduces transfer cost.
Transfer Acceleration: Faster uploads globally.
Inventory reports: Track storage usage.
Exam keyword: “reduce KMS cost” → S3 Bucket Keys.

⭐ SET 55 — CloudFront Architectures

🟩 CloudFront Architecture — MEMORY TIPS

Edge caching reduces latency for global users.
Multi‑origin setup: Route different paths to different origins (S3, ALB, API Gateway).
Origin failover: Primary + secondary origin for HA.
Lambda@Edge: Modify requests/responses at edge.
CloudFront Functions: Ultra‑fast JS for lightweight logic.
Signed URLs/Cookies: Protect premium content.
OAC: Secure S3 origins without public access.
Geo‑restriction: Block or allow countries.
Field‑level encryption: Protect sensitive form fields.
Exam keyword: “global caching + security + multi‑origin” → CloudFront.

🟩 CloudFront Performance Patterns — MEMORY TIPS

Cache key customization: Control what parameters affect caching.
Compression: GZIP/Brotli reduces size.
TTL tuning: Longer TTL = better performance, lower cost.
Origin Shield: Adds extra caching layer before origin.
HTTP/3 support: Faster for mobile networks.
Pre‑signed URLs: Reduce load on origin.
Regional Edge Caches: Larger caches closer to users.
Cache invalidation: Remove outdated content quickly.
Path‑based routing: Route /api/* to API Gateway, /images/* to S3.
Exam keyword: “reduce origin load” → Origin Shield + caching.

Absolutely, Savi — here are SET 56 to SET 60, each with 10+ advanced, tech‑layman, exam‑focused points per subtitle, in the exact crisp style you prefer.

No templates are used because this is not a step‑by‑step procedural task — this is deep AWS architecture knowledge.

Let’s continue your exam‑cram mastery.

⭐ SET 56 — EKS Networking (Advanced)

🟩 EKS Networking — MEMORY TIPS

AWS VPC CNI gives each pod a real VPC IP, enabling native VPC routing.
This means pod‑to‑pod traffic behaves like EC2 traffic — no overlay network.
IP exhaustion can happen because each pod consumes an ENI IP.
Prefix Delegation allows ENIs to allocate /28 prefixes, giving more pod IPs.
Security Groups for Pods allow pod‑level firewalling (unique to AWS).
ClusterIP services use kube‑proxy; LoadBalancer services create NLB/ALB.
Ingress Controller (ALB) exposes HTTP/HTTPS apps with path/host routing.
NodePort exposes service on each node’s port — rarely used in production.
EKS Fargate uses ENI per pod — simpler but limited networking features.
Exam keyword: “pod gets VPC IP” → AWS VPC CNI.

🟩 EKS Load Balancing — MEMORY TIPS

ALB Ingress Controller creates ALB per Ingress resource.
Supports path‑based and host‑based routing.
NLB used for TCP/UDP workloads.
Internal load balancers supported via annotations.
Target groups map to Kubernetes pods.
Health checks map to pod readiness probes.
Sticky sessions supported via ALB.
SSL termination at ALB or pod.
Multi‑AZ load balancing by default.
Exam keyword: “Ingress with path routing” → ALB Ingress Controller.

⭐ SET 57 — ECS Networking (Advanced)

🟩 ECS Networking — MEMORY TIPS

Bridge mode: Containers share host network namespace; NAT used.
Host mode: Containers use host ports directly; best for high‑performance.
awsvpc mode: Each task gets its own ENI + VPC IP (like EKS pods).
awsvpc required for Fargate tasks.
Security Groups apply at task level in awsvpc mode.
Service discovery via Cloud Map for internal DNS.
Load balancers (ALB/NLB) integrate with ECS services.
Dynamic port mapping allows multiple tasks on same host.
Task IAM roles provide least‑privilege access.
Exam keyword: “task gets ENI + VPC IP” → awsvpc mode.

🟩 ECS Load Balancing — MEMORY TIPS

ALB for HTTP/HTTPS microservices.
NLB for TCP/UDP high‑performance workloads.
Target groups map to ECS tasks.
Health checks tied to container health.
Service Auto Scaling based on CPU/memory or ALB request count.
Blue/green deployments via CodeDeploy + ALB.
Sticky sessions supported via ALB.
Internal load balancers for private services.
Multi‑AZ balancing by default.
Exam keyword: “dynamic port mapping” → ALB + ECS.

⭐ SET 58 — Step Functions Advanced

🟩 Step Functions Advanced — MEMORY TIPS

Standard workflows support long‑running tasks (up to 1 year).
Express workflows support high‑throughput, short‑lived tasks.
Parallel states run multiple branches simultaneously.
Map state processes items in a list (like a loop).
Retry policies handle transient errors automatically.
Catch blocks route failures to fallback logic.
Wait states add delays between steps.
Choice states implement branching logic.
Service Integrations allow calling AWS APIs without Lambda.
Exam keyword: “orchestrate multiple AWS services without Lambda” → Step Functions Service Integrations.

🟩 Step Functions vs Lambda — MEMORY TIPS

Lambda = compute; Step Functions = orchestration.
Step Functions reduce code complexity by handling retries.
Step Functions visualize workflows for debugging.
Lambda alone cannot orchestrate multi‑step processes.
Step Functions handle long‑running tasks; Lambda max = 15 min.
Step Functions integrate with 200+ AWS services.
Step Functions reduce “glue code” in Lambda.
Express workflows ideal for event‑driven pipelines.
Standard workflows ideal for ETL/ML pipelines.
Exam keyword: “state machine” → Step Functions.

⭐ SET 59 — Glue Advanced (ETL + Catalog + Crawlers)

🟩 Glue ETL Advanced — MEMORY TIPS

Glue uses Apache Spark under the hood.
Job bookmarks prevent reprocessing of already‑processed data.
DynamicFrames handle semi‑structured data better than DataFrames.
Glue Studio provides visual ETL design.
Glue Workflows orchestrate multiple jobs.
Glue Triggers schedule or event‑trigger jobs.
Glue Job Types: Spark, Python Shell, Ray.
Glue 4.0 supports latest Spark + Python versions.
Glue can convert CSV → Parquet for analytics optimization.
Exam keyword: “serverless Spark ETL” → Glue.

🟩 Glue Catalog & Crawlers — MEMORY TIPS

Glue Catalog stores table schemas for S3 data.
Used by Athena, Redshift Spectrum, EMR.
Crawlers auto‑detect schema + partitions.
Partition projection reduces crawler cost.
Catalog is regional.
Supports schema versioning.
Integrates with Lake Formation for permissions.
Can import Hive Metastore.
Table metadata stored in Catalog, not S3.
Exam keyword: “metadata for S3 data lake” → Glue Catalog.

⭐ SET 60 — Redshift Spectrum & Lake Formation

🟩 Redshift Spectrum — MEMORY TIPS

Allows Redshift to query S3 data directly without loading.
Uses Glue Catalog for table definitions.
Ideal for cold data stored in S3.
Reduces Redshift storage cost.
Supports Parquet/ORC for fast scanning.
Spectrum workers scale automatically.
Combine Redshift local tables + S3 external tables.
Great for data lake + warehouse hybrid.
Requires IAM role for S3 access.
Exam keyword: “query S3 without loading” → Spectrum.

🟩 Lake Formation — MEMORY TIPS

Centralized data lake permissions for S3 + Glue Catalog.
Fine‑grained access: table, column, row‑level.
Replaces bucket policies for data lake governance.
Integrates with Athena, Redshift, EMR.
Data filters restrict access to subsets of data.
Blueprints automate ingestion pipelines.
Tag‑based access control supported.
Cross‑account sharing supported.
Works with S3 Lake Formation‑managed locations.
Exam keyword: “centralized data lake permissions” → Lake Formation.

Here you go, Savi — SET 61 to SET 65, each with 10+ advanced, tech‑layman, exam‑focused points per subtitle, in the exact crisp style you prefer.

These sets cover:
S3 Security Deep, CloudFront Performance Deep, Lambda Security, VPC Endpoint Patterns, Multi‑Account Governance Advanced.

Every bullet begins with a Guided Link, exactly as required.

⭐ SET 61 — S3 Security Deep

🟩 S3 Bucket Policies — MEMORY TIPS

Bucket policies are resource‑based permissions applied at bucket level.
Use them to allow cross‑account access without IAM user creation.
Always include "Principal" to specify who can access.
Explicit Deny overrides all allows — exam trap.
Use "aws:SourceIp" to restrict access by IP range.
Use "aws:PrincipalOrgID" to restrict access to your AWS Organization.
Block public access using Block Public Access settings (stronger than policy).
Bucket policies can enforce MFA delete for versioned buckets.
Use "aws:SecureTransport": "true" to enforce HTTPS only.
Exam keyword: “cross‑account S3 access” → Bucket Policy.

🟩 S3 Access Points — MEMORY TIPS

Provide unique hostnames for controlled access to the same bucket.
Each access point has its own policy, simplifying large multi‑team access.
Great for multi‑tenant or big data environments.
Can restrict access by VPC (VPC Access Points).
Enforce private access using VPC‑only endpoints.
Reduce complexity vs giant bucket policies.
Work with S3 Object Lambda for transformations.
Access points scale automatically.
Can be used cross‑account.
Exam keyword: “many teams accessing same bucket” → Access Points.

🟩 S3 Encryption Deep — MEMORY TIPS

SSE‑S3: AWS manages keys; simplest.
SSE‑KMS: Uses KMS CMKs; audit logs + fine‑grained control.
SSE‑C: Customer provides keys; AWS never stores them.
Client‑side encryption: Encrypt before upload; full control.
Bucket Keys reduce KMS cost for SSE‑KMS.
Encryption can be enforced via bucket policy.
KMS throttling can occur at high request rates.
Multipart uploads must include encryption headers.
Replication preserves encryption settings.
Exam keyword: “audit key usage” → SSE‑KMS.

⭐ SET 62 — CloudFront Performance Deep

🟩 CloudFront Caching Optimization — MEMORY TIPS

Cache key controls what variations CloudFront caches (path, headers, cookies).
Use Cache Policies to define what CloudFront forwards to origin.
Longer TTLs reduce origin load and cost.
Origin Shield adds an extra caching layer before origin.
Compression (GZIP/Brotli) reduces object size.
Regional Edge Caches store larger objects closer to users.
Query string normalization improves cache hit ratio.
Lambda@Edge can rewrite URLs to improve caching.
CloudFront Functions handle ultra‑fast header manipulation.
Exam keyword: “reduce origin load” → Origin Shield + TTL tuning.

🟩 CloudFront Multi‑Origin Patterns — MEMORY TIPS

Route /api/* to API Gateway and /static/* to S3.
Use Origin Groups for failover (primary + secondary).
Use path‑based routing for microservices.
Use header‑based routing for A/B testing.
Use signed cookies for authenticated multi‑file access.
Use signed URLs for single‑file access.
Use geo‑restriction to block certain regions.
Use OAC to secure S3 origins.
Use Lambda@Edge for custom auth at edge.
Exam keyword: “multi‑origin global architecture” → CloudFront.

⭐ SET 63 — Lambda Security

🟩 Lambda IAM Security — MEMORY TIPS

Lambda uses an execution role to access AWS services.
Follow least privilege — only required permissions.
Use resource‑based policies for cross‑account invocation.
Use Lambda Layers for shared libraries, not secrets.
Use Secrets Manager or SSM Parameter Store for secrets.
Avoid embedding credentials in code — exam trap.
Use environment variable encryption with KMS.
Use VPC endpoints for private access to AWS services.
Use CloudTrail to audit Lambda API calls.
Exam keyword: “secure Lambda access to S3/DynamoDB” → IAM Role.

🟩 Lambda Runtime Security — MEMORY TIPS

Lambda execution environment is isolated per function.
/tmp storage is ephemeral; cleared after container recycle.
Use runtime updates by redeploying function.
Use code signing to ensure trusted deployments.
Use VPC‑enabled Lambda for private resources.
Use security groups to restrict outbound traffic.
Use WAF + API Gateway for public APIs.
Use X‑Ray for tracing and anomaly detection.
Use CloudWatch Logs for monitoring errors.
Exam keyword: “verify Lambda code integrity” → Code Signing.

⭐ SET 64 — VPC Endpoint Patterns

🟩 Interface Endpoints (PrivateLink) — MEMORY TIPS

Provide private access to AWS services via ENIs.
Traffic stays inside AWS network — no internet.
Supports S3, DynamoDB, SSM, Secrets Manager, etc.
Each endpoint has a security group.
Can restrict access using endpoint policies.
Great for private Lambda → S3/DynamoDB access.
Reduces NAT Gateway cost.
Works across accounts.
Required for S3 Access Points in VPC.
Exam keyword: “private access to AWS APIs” → Interface Endpoint.

🟩 Gateway Endpoints — MEMORY TIPS

Only for S3 and DynamoDB.
Route table entry sends traffic privately.
No cost — free to use.
No ENIs created.
Cannot attach security groups.
Use endpoint policies to restrict access.
Great for private subnets without NAT.
High‑throughput, scalable.
Works with VPC Flow Logs.
Exam keyword: “private S3 access without NAT” → Gateway Endpoint.

⭐ SET 65 — Multi‑Account Governance Advanced

🟩 AWS Organizations Deep — MEMORY TIPS

Manage multiple accounts centrally.
Use OUs to group accounts (Prod, Dev, Sandbox).
SCPs restrict maximum permissions.
SCPs apply even to root user — exam trap.
Tag policies enforce consistent tagging.
Backup policies automate backups across accounts.
Organization‑wide CloudTrail for unified auditing.
Service‑linked roles required for some services.
Consolidated billing reduces cost.
Exam keyword: “restrict actions across accounts” → SCP.

🟩 Control Tower Deep — MEMORY TIPS

Automates multi‑account setup (Landing Zone).
Creates Audit and Log Archive accounts.
Provides guardrails (preventive + detective).
Integrates with Organizations.
Account Factory automates new account creation.
Enforces best practices for security & governance.
Centralized logging across accounts.
Preconfigured OUs for Prod/Dev/Sandbox.
Great for enterprise onboarding.
Exam keyword: “automated multi‑account governance” → Control Tower.

Here you go, Savi — SET 66 to SET 70, each with 10+ advanced, tech‑layman, exam‑focused points per subtitle, in the exact crisp style you prefer.

Every bullet begins with a Guided Link, exactly as required.

⭐ SET 66 — Advanced CloudTrail

🟩 CloudTrail Advanced Features — MEMORY TIPS

Multi‑Region Trails capture events from all regions — exam default best practice.
Organization Trails apply to all accounts in AWS Organizations automatically.
Data Events track S3 object‑level access + Lambda invoke events (extra cost).
Management Events track control‑plane actions (IAM, EC2, RDS, etc.).
CloudTrail Insights detect unusual API spikes (e.g., sudden IAM changes).
EventBridge Integration routes CloudTrail events to automation workflows.
CloudTrail → CloudWatch Logs enables real‑time alerting.
Log File Integrity Validation detects tampering (SHA‑256 digest).
S3 Server Access Logs ≠ CloudTrail — exam trap.
Exam keyword: “who did what, when, from where” → CloudTrail.

🟩 CloudTrail Security — MEMORY TIPS

Store logs in a dedicated security account (Control Tower pattern).
Enable S3 Bucket Policies to restrict log access.
Use KMS encryption for log files.
Enable Log File Validation for compliance.
Use S3 Object Lock for immutability.
Use CloudTrail Insights to detect anomalies.
Use SNS notifications for critical events.
Use Access Analyzer to detect public buckets.
Use GuardDuty to detect suspicious API calls.
Exam keyword: “immutable audit logs” → S3 Object Lock + CloudTrail.

⭐ SET 67 — Advanced IAM

🟩 IAM Advanced Concepts — MEMORY TIPS

Permission Boundaries limit max permissions for delegated IAM roles.
Session Policies apply temporary restrictions during STS assume‑role.
Resource‑Based Policies allow cross‑account access (S3, Lambda, SQS).
IAM Roles Anywhere allows on‑prem workloads to use IAM roles.
STS External ID prevents confused‑deputy attacks.
Service‑Linked Roles required by some AWS services.
IAM Access Analyzer detects unintended public/cross‑account access.
Policy Evaluation Logic: Explicit Deny > Allow > Default Deny.
Identity Center (SSO) centralizes workforce access.
Exam keyword: “limit delegated admin permissions” → Permission Boundaries.

🟩 IAM Security Best Practices — MEMORY TIPS

Enforce MFA for all users.
Use IAM Roles, not access keys, for apps.
Rotate access keys regularly.
Use least privilege for all policies.
Use AWS Managed Policies as starting point.
Use Customer Managed Policies for fine‑grained control.
Use Access Analyzer to detect risky policies.
Use CloudTrail to audit IAM changes.
Use Password Policies for human users.
Exam keyword: “cross‑account access without IAM user” → Resource Policy.

⭐ SET 68 — Advanced KMS

🟩 KMS Advanced Concepts — MEMORY TIPS

Key Policies are the primary permission mechanism — IAM alone is not enough.
Grants allow temporary delegated access to CMKs.
Multi‑Region Keys replicate keys across regions for global apps.
Automatic Key Rotation available for customer‑managed keys.
KMS Throttling occurs at high request rates — exam trap.
Envelope Encryption encrypts data keys, not data directly.
KMS cannot export private keys — security guarantee.
CloudTrail logs all KMS usage for auditing.
S3 Bucket Keys reduce KMS cost for SSE‑KMS.
Exam keyword: “AccessDenied using KMS key” → Check Key Policy.

🟩 KMS Use Cases — MEMORY TIPS

S3 SSE‑KMS for audit‑friendly encryption.
EBS encryption for EC2 volumes.
RDS encryption for DB storage.
Lambda environment variable encryption.
Secrets Manager uses KMS for secret encryption.
SQS SSE‑KMS for secure messaging.
CloudWatch Logs encryption.
API Gateway custom auth tokens encryption.
Kinesis SSE‑KMS for streaming data.
Exam keyword: “audit key usage + fine‑grained access” → SSE‑KMS.

⭐ SET 69 — Advanced API Gateway

🟩 API Gateway Advanced Features — MEMORY TIPS

Request/Response Mapping Templates transform payloads (REST API only).
Usage Plans + API Keys control rate limits for clients.
Custom Authorizers (Lambda) implement custom authentication logic.
JWT Authorizers for HTTP APIs (Cognito/JWT tokens).
Caching reduces backend load (REST API only).
WAF Integration protects APIs from attacks.
VPC Links connect API Gateway to private NLBs.
Mutual TLS for client certificate authentication.
Stage Variables allow environment‑specific configs.
Exam keyword: “custom authentication logic” → Lambda Authorizer.

🟩 API Gateway Performance & Security — MEMORY TIPS

HTTP API is cheaper + faster than REST API.
REST API supports advanced features (mapping, usage plans).
Throttling protects backend systems.
CORS must be configured manually.
Private APIs accessible only via VPC endpoints.
Access Logs stored in CloudWatch Logs.
Execution Logs help debug integration issues.
Binary support for images/files.
Custom Domain Names supported for both REST + HTTP APIs.
Exam keyword: “low‑cost API for microservices” → HTTP API.

⭐ SET 70 — Advanced CloudWatch Alarms

🟩 CloudWatch Alarm Deep Dive — MEMORY TIPS

Metric Alarms trigger on thresholds (CPU, memory, latency).
Composite Alarms combine multiple alarms to reduce noise.
Anomaly Detection uses ML to detect unusual metric patterns.
High‑Resolution Metrics (1‑second) for real‑time monitoring.
Alarm Actions include SNS, Auto Scaling, EC2 stop/terminate.
Insufficient Data state occurs when metrics missing.
OK / ALARM / INSUFFICIENT_DATA are the only states.
CloudWatch Logs Metric Filters convert logs → metrics.
Cross‑account dashboards supported.
Exam keyword: “reduce alert noise” → Composite Alarms.

🟩 CloudWatch Alarm Patterns — MEMORY TIPS

CPU > 80% for 5 minutes → scale out.
ALB 5xx errors → alert on backend failures.
Lambda errors > threshold → alert on function failures.
Kinesis iterator age → consumer lag.
SQS queue depth → scale consumers.
RDS free storage space → prevent DB outage.
EC2 status check failed → auto‑recover instance.
API Gateway latency → backend bottleneck.
DynamoDB throttles → increase WCU.
Exam keyword: “convert logs to alarms” → Metric Filters.

Here you go, Savi — SET 71 to SET 75, each with 10+ advanced, tech‑layman, exam‑focused points per subtitle, in the exact crisp style you prefer.

Every bullet begins with a Guided Link, exactly as required.

⭐ SET 71 — Advanced Redshift

🟩 Redshift Architecture Deep — MEMORY TIPS

Redshift uses columnar storage, meaning it reads only the columns needed → huge performance boost.
MPP (Massively Parallel Processing) distributes queries across compute nodes for speed.
Leader node handles query planning; compute nodes execute queries.
RA3 nodes separate compute & storage → scale independently → cost‑efficient.
AQUA (Advanced Query Accelerator) speeds up scans using hardware acceleration.
Result caching returns cached results instantly for repeated queries.
Concurrency Scaling adds temporary clusters during peak load.
Spectrum queries S3 external tables without loading data.
Materialized views precompute results for faster analytics.
Exam keyword: “separate compute + storage” → RA3.

🟩 Redshift Optimization Deep — MEMORY TIPS

Sort keys reduce scanned blocks → faster queries.
Distribution keys optimize joins by colocating data.
Compression encoding reduces storage + speeds up I/O.
VACUUM reclaims space after deletes/updates.
ANALYZE updates table statistics for query planner.
Short Query Acceleration prioritizes small queries.
Workload Management (WLM) controls query queues.
Spectrum offloads cold data to S3.
UNLOAD exports results to S3 for downstream processing.
Exam keyword: “optimize join performance” → Distribution Key.

⭐ SET 72 — Advanced DynamoDB

🟩 DynamoDB Performance Deep — MEMORY TIPS

Partition key design determines performance — avoid hot keys.
Adaptive capacity automatically redistributes throughput across partitions.
On‑Demand mode auto‑scales without provisioning RCUs/WCUs.
DAX provides microsecond caching for read‑heavy workloads.
Streams capture item changes for Lambda processing.
Conditional writes prevent overwriting data accidentally.
BatchWriteItem improves write throughput.
Query is more efficient than Scan — exam trap.
LSIs allow sorting within same partition key.
GSIs allow querying on alternate keys.
Exam keyword: “avoid hot partitions” → good partition key design.

🟩 DynamoDB Advanced Patterns — MEMORY TIPS

Single‑table design stores multiple entity types in one table.
Sparse indexes index only items with specific attributes.
Write sharding distributes writes across multiple partition keys.
Time‑series data stored using composite keys (PK + SK).
Global Tables provide multi‑region active‑active replication.
TTL auto‑expires items for cost savings.
Transactions provide ACID guarantees.
DynamoDB Accelerator (DAX) reduces read latency.
Export to S3 for analytics with Athena.
Exam keyword: “multi‑region NoSQL with active‑active writes” → Global Tables.

⭐ SET 73 — Advanced VPC Routing

🟩 VPC Routing Deep — MEMORY TIPS

Route tables determine where traffic goes inside a VPC.
Longest prefix match wins — exam trap.
Blackhole routes occur when target (IGW/NAT/TGW) is deleted.
Local route always exists for VPC CIDR.
IGW required for public internet access.
NAT Gateway required for private → internet egress.
VPC Peering does NOT support transitive routing.
Transit Gateway supports transitive routing across VPCs.
PrivateLink bypasses routing — uses ENIs directly.
Exam keyword: “transitive routing between VPCs” → Transit Gateway.

🟩 Hybrid Routing Deep — MEMORY TIPS

VPN uses IPSec tunnels over internet.
Direct Connect provides private, consistent connectivity.
DX + VPN = HA hybrid architecture.
DX Gateway connects DX to multiple VPCs across regions.
Transit Gateway centralizes hybrid routing.
BGP used for dynamic routing with DX/VPN.
Route propagation auto‑adds routes from VPN/DX.
Failover from DX → VPN when DX down.
Private VIF connects DX → single VPC.
Exam keyword: “DX to multiple VPCs” → DX Gateway.

⭐ SET 74 — Advanced CloudFront Security

🟩 CloudFront Security Deep — MEMORY TIPS

Origin Access Control (OAC) locks S3 buckets to CloudFront only.
WAF integration blocks SQLi, XSS, bots at edge.
Geo‑restriction blocks countries/regions.
Signed URLs restrict access to single objects.
Signed Cookies restrict access to multiple objects.
Field‑level encryption protects sensitive form fields.
TLS termination at edge improves security + performance.
Shield Advanced protects against DDoS attacks.
Lambda@Edge adds custom security logic (JWT validation, header checks).
Exam keyword: “secure global content delivery” → CloudFront.

🟩 CloudFront Zero‑Trust Patterns — MEMORY TIPS

Enforce HTTPS‑only using viewer protocol policies.
Use OAC to block direct S3 access.
Use signed URLs for premium content.
Use signed cookies for multi‑file access.
Use WAF for L7 protection.
Use bot control to block scrapers.
Use header whitelisting to prevent spoofing.
Use Lambda@Edge for token validation.
Use geo‑blocking for compliance.
Exam keyword: “zero‑trust CDN architecture” → CloudFront + OAC + WAF.

⭐ SET 75 — Advanced Serverless Patterns

🟩 Serverless Integration Patterns — MEMORY TIPS

S3 → Lambda → DynamoDB for file processing pipelines.
API Gateway → Lambda → RDS Proxy for secure DB access.
EventBridge → Lambda → SQS for async workflows.
SNS → SQS fan‑out for multi‑consumer systems.
Kinesis → Lambda for real‑time streaming.
Step Functions → Lambda for orchestrated workflows.
SQS → Lambda for queue‑based scaling.
DynamoDB Streams → Lambda for change‑data‑capture.
CloudWatch Events → Lambda for scheduled tasks.
Exam keyword: “event‑driven microservices” → EventBridge + Lambda.

🟩 Serverless Anti‑Patterns — MEMORY TIPS

Long‑running tasks in Lambda → use Step Functions or ECS.
High‑connection DB workloads → use RDS Proxy.
Large dependencies → slow cold starts → use Lambda Layers.
Stateful logic → Lambda is stateless → use DynamoDB/S3.
High‑latency VPC calls → use VPC endpoints.
Synchronous fan‑out → use SNS/SQS instead.
Large payloads → use S3 pre‑signed URLs.
Polling loops → use EventBridge or SQS triggers.
Monolithic Lambdas → break into micro‑functions.
Exam keyword: “Lambda overwhelmed by DB connections” → RDS Proxy.

Absolutely Savi — here are SET 76 to SET 80, each with 10+ advanced, tech‑layman, exam‑focused points per subtitle, in the exact crisp style you prefer.

Every bullet begins with a Guided Link, exactly as required.

⭐ SET 76 — Advanced CloudFront

🟩 CloudFront Deep Architecture — MEMORY TIPS

Edge → Regional Edge Cache → Origin: Multi‑layer caching reduces origin load dramatically.
Regional Edge Caches store larger objects and reduce cache misses.
Origin Shield adds a centralized caching layer before origin — best for S3/ALB.
Cache Key Customization controls what variations CloudFront caches (headers, cookies, query strings).
Signed URLs protect single premium objects (e.g., video files).
Signed Cookies protect multiple objects (e.g., entire folder).
Lambda@Edge modifies requests/responses at edge (auth, redirects, rewrites).
CloudFront Functions handle ultra‑fast header manipulation (micro‑second).
OAC (Origin Access Control) replaces OAI for secure S3 access.
Exam keyword: “reduce origin load + global performance” → Origin Shield + TTL tuning.

🟩 CloudFront Advanced Routing — MEMORY TIPS

Path‑based routing: /api/* → API Gateway, /static/* → S3.
Header‑based routing: A/B testing, device‑based routing.
Geo‑routing: Serve different content per region.
Origin Groups: Primary + failover origin for HA.
Custom error pages: Serve friendly fallback content.
Protocol policies: Redirect HTTP → HTTPS globally.
Compression: Brotli/GZIP reduces payload size.
HTTP/3 + QUIC improves mobile performance.
Field‑level encryption protects sensitive form fields.
Exam keyword: “multi‑origin global architecture” → CloudFront.

⭐ SET 77 — Advanced Redshift

🟩 Redshift Deep Performance — MEMORY TIPS

Columnar storage reduces I/O by scanning only needed columns.
Sort Keys optimize range queries (e.g., date‑based).
Distribution Keys colocate related data for faster joins.
Compression Encoding reduces storage + speeds up scans.
Materialized Views precompute results for repeated queries.
Concurrency Scaling adds temporary clusters during peak load.
Spectrum queries S3 external tables without loading.
RA3 nodes separate compute & storage → cost‑efficient scaling.
AQUA accelerates queries using hardware acceleration.
Exam keyword: “optimize join performance” → Distribution Key.

🟩 Redshift Data Lake Integration — MEMORY TIPS

Spectrum allows Redshift to query S3 directly.
Uses Glue Catalog for table metadata.
Ideal for cold data stored in S3.
Supports Parquet/ORC for efficient scanning.
Combine Redshift tables + S3 external tables in one query.
UNLOAD exports results to S3 for downstream analytics.
COPY loads data from S3 into Redshift fast.
Lake Formation controls permissions for S3 data.
IAM roles required for S3 access.
Exam keyword: “query S3 without loading” → Spectrum.

⭐ SET 78 — Advanced API Gateway

🟩 API Gateway Deep Features — MEMORY TIPS

Mapping Templates transform request/response payloads (REST only).
Usage Plans + API Keys enforce rate limits per client.
Custom Authorizers (Lambda) implement custom authentication logic.
JWT Authorizers validate tokens for HTTP APIs.
Caching reduces backend load (REST only).
Mutual TLS enforces client certificate authentication.
VPC Links connect API Gateway to private NLBs.
WAF Integration protects APIs from attacks.
Stage Variables allow environment‑specific configs.
Exam keyword: “custom authentication logic” → Lambda Authorizer.

🟩 API Gateway Integration Patterns — MEMORY TIPS

Lambda Proxy Integration passes full request to Lambda.
HTTP Integration forwards to external HTTP endpoints.
VPC Link Integration connects to private NLBs.
Mock Integration returns static responses (testing).
Direct Service Integrations call AWS services without Lambda.
WebSocket APIs support real‑time bidirectional communication.
Private APIs accessible only via VPC endpoints.
Binary support for images/files.
Custom Domain Names unify API URLs.
Exam keyword: “call AWS services without Lambda” → Direct Integrations.

⭐ SET 79 — IAM Federation (SSO, Identity Center, External Identities)

🟩 IAM Federation Deep — MEMORY TIPS

Federation allows external identities (AD, Google, Okta) to access AWS.
SAML 2.0 used for enterprise SSO.
OIDC used for modern identity providers.
Identity Center (AWS SSO) centralizes workforce access.
Permission Sets define what federated users can access.
STS AssumeRoleWithSAML issues temporary credentials.
External ID prevents confused‑deputy attacks.
IAM Roles Anywhere allows on‑prem servers to assume IAM roles.
Cognito handles user pools + identity pools for app users.
Exam keyword: “enterprise SSO into AWS” → SAML Federation.

🟩 Identity Center (SSO) Deep — MEMORY TIPS

Centralized login portal for all AWS accounts.
Integrates with AD, Okta, Azure AD.
Permission Sets map to IAM roles in accounts.
Supports SCIM for automatic user provisioning.
MFA enforced centrally.
Reduces need for IAM users.
Works with AWS Organizations.
Provides audit logs for access.
Supports CLI SSO login.
Exam keyword: “centralized workforce access” → Identity Center.

⭐ SET 80 — Advanced Serverless Architectures

🟩 Serverless Architecture Deep — MEMORY TIPS

Event‑driven design using EventBridge, SNS, SQS.
Micro‑functions instead of monolithic Lambdas.
API Gateway for synchronous APIs.
SQS for asynchronous processing.
Step Functions for orchestration.
DynamoDB for low‑latency NoSQL storage.
S3 for static hosting + file storage.
CloudFront for global distribution.
RDS Proxy for Lambda → RDS connection pooling.
Exam keyword: “event‑driven microservices” → EventBridge + Lambda.

🟩 Serverless Anti‑Patterns Deep — MEMORY TIPS

Long‑running tasks in Lambda → use Step Functions or ECS.
High DB connection usage → use RDS Proxy.
Large Lambda packages → slow cold starts → use Layers.
Stateful logic → Lambda is stateless → use DynamoDB/S3.
Polling loops → use EventBridge or SQS triggers.
Synchronous fan‑out → use SNS + SQS.
Large payloads → use S3 pre‑signed URLs.
Lambda in VPC without endpoints → slow cold starts.
Monolithic Lambdas → break into micro‑functions.
Exam keyword: “Lambda overwhelmed by DB connections” → RDS Proxy.

Absolutely Savi — here are SET 81 to SET 85, each with 10+ advanced, tech‑layman, exam‑focused points per subtitle, in the exact crisp style you prefer.

Every bullet begins with a Guided Link, exactly as required.

⭐ SET 81 — Advanced VPC Security

🟩 VPC Security Deep Patterns — MEMORY TIPS

Security Groups = Stateful — return traffic automatically allowed, even if no explicit rule.
NACLs = Stateless — must allow inbound + outbound explicitly; exam trap.
SG‑to‑SG referencing allows dynamic trust without IPs (e.g., ALB SG → EC2 SG).
NACL rule order matters — lowest rule number wins; default NACL allows all.
Ephemeral ports must be allowed in NACLs for return traffic (1024–65535).
Flow Logs capture ACCEPT/REJECT traffic for troubleshooting.
Network Firewall provides L3/L4/L7 deep packet inspection at scale.
Gateway Load Balancer deploys 3rd‑party firewalls using GENEVE tunneling.
PrivateLink bypasses routing entirely — uses ENIs for private service access.
Exam keyword: “subnet‑level stateless filtering” → NACL.

🟩 Zero‑Trust VPC Architecture — MEMORY TIPS

No implicit trust between subnets — enforce SG rules everywhere.
PrivateLink for private access to AWS services (no internet).
VPC Endpoints eliminate NAT Gateway cost + improve security.
Restrict outbound traffic using SG egress rules.
Use Network Firewall for egress domain filtering.
Use IAM + SCPs to prevent creation of public resources.
Use S3 Block Public Access for all buckets.
Use VPC Flow Logs to detect unusual traffic patterns.
Use WAF + CloudFront for public‑facing apps.
Exam keyword: “private access to AWS APIs” → Interface Endpoint.

⭐ SET 82 — Advanced Kinesis

🟩 Kinesis Scaling Deep — MEMORY TIPS

Shards = throughput units — 1 MB/s write, 2 MB/s read.
Scaling = add shards; splitting increases capacity, merging reduces cost.
Hot partitions occur when partition key not distributed — fix by randomizing keys.
Enhanced Fan‑Out gives each consumer 2 MB/s dedicated throughput.
On‑Demand Streams auto‑scale without shard management.
Retention up to 1 year for replay.
Lambda consumers scale with shard count (1 Lambda per shard).
Checkpointing prevents reprocessing; stored in DynamoDB.
KMS encryption may throttle at high throughput.
Exam keyword: “ordered real‑time streaming” → Kinesis Streams.

🟩 Kinesis Firehose Deep — MEMORY TIPS

Fully managed — no shards, no scaling management.
Delivers to S3, Redshift, OpenSearch, HTTP endpoints.
Buffering (size/time) controls delivery frequency.
Lambda transforms allow JSON → Parquet/ORC conversion.
Dynamic partitioning organizes S3 data by keys (e.g., date/user).
Compression reduces S3 cost (GZIP, Snappy).
Near‑real‑time, not real‑time (1–60 sec delay).
No replay — once delivered, cannot reprocess.
Automatic scaling based on incoming throughput.
Exam keyword: “deliver streaming data to S3 automatically” → Firehose.

⭐ SET 83 — Advanced Glue

🟩 Glue ETL Deep — MEMORY TIPS

Glue uses Apache Spark under the hood for distributed ETL.
DynamicFrames handle semi‑structured data better than DataFrames.
Job Bookmarks prevent reprocessing of already‑processed data.
Glue Studio provides visual ETL design.
Glue Workflows orchestrate multiple ETL jobs.
Glue Triggers schedule or event‑trigger jobs.
Glue 4.0 supports latest Spark + Python versions.
Glue can convert CSV → Parquet for analytics optimization.
Glue Workers define compute power (G.1X, G.2X, G.4X).
Exam keyword: “serverless Spark ETL” → Glue.

🟩 Glue Catalog & Lake Formation Deep — MEMORY TIPS

Glue Catalog stores table schemas for S3 data.
Used by Athena, Redshift Spectrum, EMR.
Crawlers auto‑detect schema + partitions.
Partition projection reduces crawler cost.
Lake Formation provides fine‑grained permissions (table/column/row).
LF‑Tags allow tag‑based access control.
Cross‑account sharing supported.
Data filters restrict access to subsets of data.
Catalog is regional — exam trap.
Exam keyword: “centralized data lake permissions” → Lake Formation.

⭐ SET 84 — Advanced CloudWatch

🟩 CloudWatch Metrics Deep — MEMORY TIPS

High‑resolution metrics (1‑second) for real‑time monitoring.
Metric Math combines multiple metrics (e.g., CPU + network).
Custom metrics require CloudWatch Agent or API.
Memory/disk metrics require CloudWatch Agent (not default).
Cross‑account dashboards supported.
Metric Filters convert logs → metrics.
Retention up to 15 months.
Anomaly Detection uses ML to detect unusual patterns.
Composite Alarms reduce alert noise.
Exam keyword: “detect unusual metric patterns” → Anomaly Detection.

🟩 CloudWatch Logs Deep — MEMORY TIPS

Stores logs from EC2, Lambda, API Gateway, VPC Flow Logs.
Log Insights provides SQL‑like queries.
Subscription Filters stream logs to Lambda/Kinesis/Firehose.
Encryption via KMS.
Export to S3 for long‑term retention.
Cross‑account log sharing supported.
Retention policies reduce cost.
CloudWatch Agent collects OS‑level metrics + logs.
Log groups organize logs by service.
Exam keyword: “query logs quickly” → Logs Insights.

⭐ SET 85 — Multi‑Region Serverless

🟩 Multi‑Region Serverless Patterns — MEMORY TIPS

Active‑Active: Both regions serve traffic; lowest latency routing.
Active‑Passive: Primary region active; secondary for DR.
DynamoDB Global Tables provide multi‑region active‑active writes.
S3 CRR replicates objects asynchronously across regions.
Lambda@Edge runs code globally at CloudFront edge locations.
API Gateway + CloudFront provide global API acceleration.
Aurora Global Database replicates <1 sec cross‑region.
EventBridge global routing via cross‑region event buses.
KMS Multi‑Region Keys simplify encryption across regions.
Exam keyword: “multi‑region active‑active NoSQL” → DynamoDB Global Tables.

🟩 Multi‑Region Failover Patterns — MEMORY TIPS

Route 53 Failover Routing switches traffic between regions.
Health checks determine when to fail over.
CloudFront continues serving cached content even if origin down.
S3 Multi‑Region Access Points route to nearest healthy bucket.
Lambda@Edge can reroute traffic dynamically.
Aurora Global promotes secondary region quickly.
DynamoDB Global Tables auto‑failover between regions.
EventBridge can route events cross‑region.
Multi‑Region KMS keys ensure encryption continuity.
Exam keyword: “global failover with DNS” → Route 53 Failover.

Absolutely Savi — here are SET 86 to SET 90, each with 10+ advanced, tech‑layman, exam‑focused points per subtitle, in the exact crisp style you prefer.

Every bullet begins with a Guided Link, exactly as required.

⭐ SET 86 — Advanced ALB / NLB

🟩 ALB Advanced Patterns — MEMORY TIPS

ALB supports Layer 7 routing (path, host, header, query‑string).
Target groups can be Lambda, IPs, EC2, ECS tasks.
Sticky sessions supported via cookies.
WebSockets supported for real‑time apps.
HTTP/2 supported for better performance.
WAF integration for L7 protection.
ALB Ingress Controller integrates with EKS for Kubernetes routing.
Authentication via Cognito or OIDC providers.
Cross‑zone load balancing enabled by default.
Exam keyword: “path‑based routing” → ALB.

🟩 NLB Advanced Patterns — MEMORY TIPS

NLB operates at Layer 4 — ultra‑low latency.
Supports TCP, UDP, TLS.
Static IPs per AZ — great for whitelisting.
Zonal isolation — each AZ has its own node.
TLS termination supported (unlike Classic LB).
Preserves client IP — important for security logs.
High throughput — millions of requests per second.
Best for gaming, IoT, financial trading.
PrivateLink uses NLB under the hood.
Exam keyword: “static IP + ultra‑fast” → NLB.

⭐ SET 87 — Advanced S3 Replication

🟩 S3 Replication Deep — MEMORY TIPS

CRR (Cross‑Region Replication) replicates objects to another region.
SRR (Same‑Region Replication) replicates within same region for compliance.
Replication requires versioning enabled on both buckets.
IAM role required for replication permissions.
Replication Time Control (RTC) guarantees <15‑minute replication SLA.
Delete markers can be replicated optionally.
Existing objects require Batch Replication.
KMS keys must allow cross‑region decrypt/encrypt.
S3 Object Ownership affects replication behavior.
Exam keyword: “guaranteed replication SLA” → RTC.

🟩 S3 Multi‑Region Access Points — MEMORY TIPS

Provide a single global endpoint for multi‑region buckets.
Automatically routes to nearest healthy region.
Built‑in latency‑based routing.
Great for global apps needing low latency.
Works with CRR for data sync.
Supports failover automatically.
Reduces complexity vs Route 53 + S3.
Integrates with CloudFront for global caching.
IAM policies apply at MRAP level.
Exam keyword: “global S3 endpoint” → MRAP.

⭐ SET 88 — Advanced Step Functions

🟩 Step Functions Deep Patterns — MEMORY TIPS

Parallel states run multiple branches at once.
Map state processes arrays (like a loop).
Wait state adds delays for retries/backoff.
Choice state implements branching logic.
Retry policies handle transient failures.
Catch blocks route errors to fallback logic.
Service Integrations call AWS APIs without Lambda.
Express workflows for high‑throughput, short‑lived tasks.
Standard workflows for long‑running tasks (up to 1 year).
Exam keyword: “orchestrate multiple AWS services” → Step Functions.

🟩 Step Functions Error Handling — MEMORY TIPS

Retry block supports exponential backoff.
Catch block handles specific error types.
Fallback states allow graceful degradation.
Lambda errors automatically retried for async flows.
Service API errors handled via retry policies.
Timeouts can be set per state.
Execution history visible in console for debugging.
CloudWatch Logs capture execution details.
Dead‑letter queues for failed async tasks.
Exam keyword: “automatic retries + fallback logic” → Step Functions.

⭐ SET 89 — Advanced EventBridge

🟩 EventBridge Deep Routing — MEMORY TIPS

Event buses: default, custom, partner.
Event patterns match events by fields (source, detail‑type).
Targets include Lambda, SQS, SNS, Step Functions, Kinesis.
Cross‑account routing supported.
Schema Registry auto‑discovers event structure.
Replay events using EventBridge Archive.
EventBridge Pipes connect sources → filters → enrichers → targets.
Filtering reduces unnecessary invocations.
SaaS integrations (Datadog, Zendesk, Auth0).
Exam keyword: “event routing + filtering” → EventBridge.

🟩 EventBridge Pipes Deep — MEMORY TIPS

Pipes connect source → filter → enrich → target.
Sources include SQS, Kinesis, DynamoDB Streams.
Filters reduce noise before processing.
Enrichers call Lambda or Step Functions.
Targets include SQS, Lambda, EventBridge bus.
Great for ETL‑like streaming pipelines.
Reduces need for custom Lambda glue code.
Supports batching for SQS/Kinesis.
IAM roles required for each stage.
Exam keyword: “connect event sources without Lambda glue” → Pipes.

⭐ SET 90 — Advanced Data Lake Patterns

🟩 Data Lake Architecture Deep — MEMORY TIPS

S3 is the storage layer (cheap, durable, scalable).
Glue Catalog stores metadata (tables, partitions).
Lake Formation manages fine‑grained permissions.
Athena queries S3 using SQL.
Redshift Spectrum queries S3 external tables.
EMR runs Spark/Hive on S3 data.
Kinesis/Firehose ingest streaming data into S3.
Parquet/ORC formats reduce cost + improve performance.
Partitioning improves query speed (e.g., date/hour).
Exam keyword: “central metadata + S3 storage” → Glue Catalog.

🟩 Data Lake Governance Deep — MEMORY TIPS

Lake Formation provides table/column/row‑level permissions.
LF‑Tags enable tag‑based access control.
Data filters restrict access to subsets of data.
Cross‑account sharing supported.
S3 Access Points simplify multi‑team access.
Object Lock provides immutability for compliance.
CloudTrail logs all access events.
S3 Inventory tracks objects for governance.
Encryption via SSE‑KMS for compliance.
Exam keyword: “fine‑grained data lake permissions” → Lake Formation.

Amazon MSK

Amazon MSK cannot be deployed in public subnets. Not in the current VPC, not in a new VPC — never.

This single fact invalidates A and B completely.

MSK brokers must live in private subnets because they require:

ENIs in private IP space
No direct public IPs
No internet-facing interfaces

This is an AWS‑enforced constraint, not a best practice.

AWS provides one supported architecture for public MSK ingestion:

✔ Network Load Balancer (NLB) with TLS passthrough

Brokers stay in private subnets
NLB is internet‑facing
NLB forwards TCP traffic to MSK brokers
MSK handles TLS encryption end‑to‑end
Zero need to rebuild the cluster
Fully supported by AWS MSK documentation

⭐ SET 91 — Advanced Lambda Event Models

🟩 Lambda Event Models Deep — MEMORY TIPS

Synchronous invocation (API Gateway, ALB): Caller waits for response; failures returned immediately.
Asynchronous invocation (S3, EventBridge, SNS): Lambda queues event internally and retries twice.
Event Source Mapping (SQS, Kinesis, DynamoDB Streams): Lambda polls source and processes batches.
Batch size controls how many messages per invocation (SQS/Kinesis).
Batch window adds delay to accumulate more messages for efficiency.
Partial batch failure supported for SQS — only failed messages retried.
Kinesis/DynamoDB Streams retry until data expires (24h–7d).
Dead‑Letter Queues capture failed async events.
Lambda Destinations route success/failure to SQS/SNS/EventBridge.
Exam keyword: “Lambda invoked automatically from queue/stream” → Event Source Mapping.

🟩 Lambda Event Ordering — MEMORY TIPS

Kinesis preserves ordering within a shard.
DynamoDB Streams preserve ordering within a partition key.
SQS FIFO preserves ordering within a MessageGroupId.
SQS Standard does NOT guarantee ordering — exam trap.
Parallelization factor increases concurrency per shard.
Batch failure can break ordering — use small batch sizes.
Idempotent processing required for all event models.
Retry behavior differs by source (Kinesis = infinite retries).
Async events may arrive out of order.
Exam keyword: “strict ordering required” → Kinesis or SQS FIFO.

⭐ SET 92 — Advanced API Gateway Security

🟩 API Gateway Security Deep — MEMORY TIPS

IAM Auth for internal APIs (SigV4 signing).
Cognito User Pools for user authentication (JWT tokens).
Lambda Authorizers for custom authentication logic.
JWT Authorizers for HTTP APIs (fast + simple).
WAF Integration blocks SQLi, XSS, bots.
Resource Policies restrict access by IP, VPC, or account.
Mutual TLS enforces client certificate authentication.
Private APIs accessible only via VPC endpoints.
TLS 1.2 enforcement for compliance.
Exam keyword: “custom auth logic at API layer” → Lambda Authorizer.

🟩 API Gateway Threat Protection — MEMORY TIPS

Rate limiting via usage plans prevents abuse.
Throttling protects backend systems.
Request validation blocks malformed payloads.
CORS must be explicitly configured — exam trap.
API Keys identify clients (REST only).
Access Logs capture request metadata.
Execution Logs help debug integration issues.
WAF Bot Control blocks scrapers.
IP whitelisting via resource policies.
Exam keyword: “block malicious traffic before Lambda” → WAF + Resource Policy.

⭐ SET 93 — Advanced DynamoDB Scaling

🟩 DynamoDB Scaling Deep — MEMORY TIPS

Adaptive capacity automatically shifts throughput to hot partitions.
On‑Demand mode auto‑scales instantly — best for unpredictable workloads.
Provisioned mode supports auto‑scaling based on utilization.
Write sharding distributes writes across multiple partition keys.
GSIs scale independently from base table.
LSIs share partition key — limited to 5 per table.
Batch operations improve throughput (BatchGet/BatchWrite).
DAX reduces read latency to microseconds.
Streams enable real‑time change processing.
Exam keyword: “unpredictable traffic pattern” → On‑Demand.

🟩 DynamoDB Hot Partition Avoidance — MEMORY TIPS

Evenly distribute partition keys — avoid “user123” as single hot key.
Use random suffixes (e.g., order#1, order#2).
Use time‑bucketed keys for time‑series data.
Use write sharding for high‑write workloads.
Use GSI to spread load across partitions.
Avoid monotonically increasing keys (timestamps).
Use composite keys (PK + SK) for better distribution.
Monitor ConsumedCapacity to detect hotspots.
Use adaptive capacity to auto‑rebalance.
Exam keyword: “hot partition fix” → randomize partition keys.

⭐ SET 94 — Advanced S3 Performance

🟩 S3 Performance Deep — MEMORY TIPS

S3 automatically scales — no need for random prefixes anymore.
Multipart upload improves performance for large files.
S3 Select retrieves only needed columns/rows → faster + cheaper.
Transfer Acceleration speeds up global uploads via CloudFront edge.
Byte‑range GETs allow parallel downloads.
Intelligent‑Tiering optimizes cost automatically.
S3 Bucket Keys reduce KMS cost for SSE‑KMS.
Compression (GZIP/Parquet) reduces size + improves speed.
S3 Inventory helps track object metadata at scale.
Exam keyword: “faster global uploads” → Transfer Acceleration.

🟩 S3 High‑Performance Architectures — MEMORY TIPS

Use parallel uploads for multi‑GB files.
Use multipart upload for resilience + speed.
Use S3 Event Notifications for real‑time processing.
Use S3 + CloudFront for global distribution.
Use S3 Access Points for multi‑team access.
Use S3 Batch Operations for large‑scale object updates.
Use S3 Object Lambda for on‑the‑fly transformations.
Use CRR for multi‑region performance.
Use MRAP for global low‑latency access.
Exam keyword: “global S3 endpoint” → Multi‑Region Access Points.

⭐ SET 95 — Advanced Multi‑Region Networking

🟩 Multi‑Region Networking Deep — MEMORY TIPS

Transit Gateway Peering connects TGWs across regions.
DX Gateway connects Direct Connect to multiple VPCs across regions.
Global Accelerator accelerates TCP/UDP traffic globally.
Route 53 Latency Routing directs users to nearest region.
PrivateLink works cross‑region for service access.
VPC Peering supports cross‑region but no transitive routing.
CloudFront accelerates dynamic + static content globally.
S3 Multi‑Region Access Points provide global S3 endpoint.
KMS Multi‑Region Keys simplify encryption across regions.
Exam keyword: “global low‑latency routing” → Global Accelerator.

🟩 Multi‑Region Failover Deep — MEMORY TIPS

Route 53 Failover Routing switches traffic between regions.
Health checks determine failover conditions.
CloudFront continues serving cached content even if origin down.
Aurora Global Database promotes secondary region quickly.
DynamoDB Global Tables auto‑failover between regions.
S3 CRR ensures data availability across regions.
EventBridge routes events cross‑region.
Multi‑Region KMS keys ensure encryption continuity.
Lambda@Edge reroutes traffic dynamically.
Exam keyword: “DNS‑based failover” → Route 53 Failover.

Absolutely Savi — here are SET 96 to SET 100, each with 10+ advanced, tech‑layman, exam‑focused points per subtitle, in the exact crisp style you prefer.

Every bullet begins with a Guided Link, exactly as required.

⭐ SET 96 — Advanced CloudFront Edge Logic

🟩 CloudFront Edge Logic Deep — MEMORY TIPS

Lambda@Edge runs at CloudFront edge locations — ideal for auth, redirects, header manipulation.
CloudFront Functions run in microseconds — best for lightweight logic (header rewrites, bot filtering).
Viewer Request event: modify request before cache lookup.
Origin Request event: modify request before sending to origin.
Origin Response event: modify origin response before caching.
Viewer Response event: modify response before sending to user.
JWT validation at edge reduces load on origin.
A/B testing using header injection at edge.
SEO redirects (301/302) handled globally at edge.
Exam keyword: “modify request before reaching origin” → Lambda@Edge.

🟩 CloudFront Edge Security — MEMORY TIPS

HSTS headers enforced at edge for HTTPS‑only.
CSP headers injected to prevent XSS.
Bot filtering using CloudFront Functions.
IP allow/deny lists enforced at edge.
Signed URLs/Cookies validated at edge.
Token‑based auth validated before origin.
Header sanitization removes sensitive headers.
Geo‑blocking enforced at edge.
Rate limiting via WAF + edge logic.
Exam keyword: “security logic at global edge” → Lambda@Edge.

⭐ SET 97 — Advanced RDS / Aurora Failover

🟩 RDS Failover Deep — MEMORY TIPS

Multi‑AZ uses synchronous replication — automatic failover within minutes.
Failover promotes standby instance to primary.
DNS endpoint stays the same — app reconnects automatically.
Read Replicas are NOT used for failover — exam trap.
Cross‑region read replicas used for DR, not HA.
RDS Proxy reduces connection storms during failover.
Failover triggers: AZ outage, primary crash, manual failover.
Storage auto‑repair ensures durability.
Enhanced Monitoring helps detect failover causes.
Exam keyword: “HA but not scaling” → Multi‑AZ.

🟩 Aurora Failover Deep — MEMORY TIPS

Aurora stores 6 copies across 3 AZs — extremely durable.
Failover is fast (<30 seconds) because compute nodes detach/reattach to shared storage.
Reader Endpoint load‑balances read replicas.
Cluster Endpoint always points to writer.
Aurora Global Database replicates <1 sec cross‑region.
Global failover promotes secondary region quickly.
Backtrack rewinds DB without restore.
Parallel Query speeds up analytics.
Serverless v2 scales instantly.
Exam keyword: “fastest failover in AWS databases” → Aurora.

⭐ SET 98 — Advanced Kinesis Analytics

🟩 Kinesis Data Analytics Deep — MEMORY TIPS

Real‑time SQL queries on streaming data.
Supports SQL and Apache Flink applications.
Windowed aggregations (tumbling, sliding, session windows).
Flink supports complex event processing (CEP).
Integrates with Kinesis Streams, Firehose, MSK.
Outputs to S3, Redshift, OpenSearch, Lambda.
Autoscaling based on throughput.
Checkpointing ensures fault tolerance.
Schema discovery for streaming data.
Exam keyword: “real‑time analytics on streaming data” → Kinesis Data Analytics.

🟩 Kinesis Analytics Use Cases — MEMORY TIPS

Real‑time dashboards (metrics, IoT).
Fraud detection using CEP.
Log enrichment pipelines.
Real‑time anomaly detection.
Clickstream analytics.
Real‑time ETL before S3 ingestion.
IoT sensor aggregation.
Social media sentiment analysis.
Gaming event processing.
Exam keyword: “real‑time transformations before S3” → Kinesis Analytics.

⭐ SET 99 — Advanced IAM Governance

🟩 IAM Governance Deep — MEMORY TIPS

Permission Boundaries restrict delegated admin permissions.
SCPs restrict max permissions across accounts.
Session Policies apply temporary restrictions during STS assume‑role.
Access Analyzer detects public/cross‑account access.
IAM Access Advisor shows unused permissions.
IAM Credential Reports audit user access keys.
Identity Center (SSO) centralizes workforce access.
Service‑Linked Roles required by many AWS services.
IAM Roles Anywhere extends IAM to on‑prem servers.
Exam keyword: “limit delegated admin power” → Permission Boundaries.

🟩 IAM Policy Design Deep — MEMORY TIPS

Use least privilege always.
Prefer resource‑level permissions over broad actions.
Use conditions (aws:SourceIp, aws:PrincipalOrgID).
Use managed policies as baseline, then refine.
Avoid inline policies for long‑term governance.
Use tags for attribute‑based access control (ABAC).
Use role chaining carefully — session duration limits apply.
Use MFA conditions for sensitive actions.
Use policy validation tools to detect errors.
Exam keyword: “restrict access by organization” → aws:PrincipalOrgID.

⭐ SET 100 — Advanced Serverless Observability

🟩 Serverless Observability Deep — MEMORY TIPS

CloudWatch Logs capture Lambda logs automatically.
CloudWatch Metrics track invocations, errors, duration, throttles.
X‑Ray traces Lambda → DynamoDB → API Gateway flows.
ServiceLens visualizes end‑to‑end serverless apps.
Lambda Insights provides CPU, memory, network metrics.
Structured logging (JSON) improves searchability.
Log retention policies reduce cost.
Metric filters convert logs → metrics for alarms.
Dashboards visualize serverless performance.
Exam keyword: “trace serverless end‑to‑end” → X‑Ray + ServiceLens.

🟩 Serverless Failure Analysis — MEMORY TIPS

DLQs capture failed async events.
Lambda Destinations route success/failure events.
X‑Ray traces show bottlenecks.
CloudWatch Alarms detect error spikes.
SQS redrive moves DLQ messages back to main queue.
Structured logs help identify root cause.
Cold start metrics visible via Lambda Insights.
Timeout errors fixed by increasing timeout or optimizing code.
Throttles fixed by increasing concurrency limits.
Exam keyword: “capture failed async events” → DLQ or Destinations.

VPC Lattice service network

Amazon VPC Lattice is designed for cross-account and cross-VPC service-to-service communication with built-in service discovery, HTTPS support, and fine-grained access control.
It minimizes administrative effort by eliminating the need for complex peering, PrivateLink setups, or custom registries.
Provides a native service registry and secure communication over HTTPS, making it the most efficient solution.

Absolutely Savi — here are SET 101 to SET 105, each with 10+ advanced, tech‑layman, exam‑focused points per subtitle, in the exact crisp style you prefer.

Every bullet begins with a Guided Link, exactly as required.

⭐ SET 101 — Advanced SQS Patterns

🟩 SQS Advanced Messaging Patterns — MEMORY TIPS

Decoupling Pattern: SQS absorbs traffic spikes so consumers don’t crash.
Fan‑out Durable Pattern: SNS → multiple SQS queues → multiple consumers.
Idempotent Consumers: Required because SQS may deliver duplicates.
Visibility Timeout Tuning: Must exceed processing time to avoid double‑processing.
Long Polling (20s): Reduces empty responses + cost; exam favourite.
FIFO Ordering: Use MessageGroupId to maintain strict ordering.
DLQ Isolation: Failed messages go to DLQ without blocking main queue.
Batch Processing: Up to 10 messages per batch → cheaper + faster.
SQS + Lambda: Lambda polls automatically; batch size controls concurrency.
Exam keyword: “buffer spikes + prevent overload” → SQS.

🟩 SQS High‑Throughput Patterns — MEMORY TIPS

Horizontal scaling of consumers increases throughput.
Batch window allows accumulating messages for efficiency.
Parallel consumers process messages faster.
FIFO high‑throughput mode supports 3,000 msg/s with batching.
Message attributes help route messages to correct processors.
SQS Extended Client stores large payloads in S3.
SQS + Kinesis hybrid for real‑time + durable buffering.
CloudWatch alarms on queue depth trigger scaling.
Dead‑letter redrive moves DLQ messages back to main queue.
Exam keyword: “large payloads in SQS” → Extended Client + S3.

⭐ SET 102 — Advanced SNS Patterns

🟩 SNS Advanced Fan‑Out Patterns — MEMORY TIPS

Fan‑out: One message → many subscribers (SQS, Lambda, HTTP).
Durable fan‑out: SNS → SQS ensures no message loss.
Message Filtering: Subscribers receive only relevant messages.
FIFO SNS: Ordered + deduped pub/sub pipelines.
Cross‑account publishing: Topic policies allow external accounts.
Retry logic: HTTP endpoints retried with exponential backoff.
Mobile push: SNS integrates with APNS/FCM.
Encryption: SSE‑KMS for at‑rest encryption.
DLQ for Lambda subscribers captures failures.
Exam keyword: “broadcast to multiple systems” → SNS.

🟩 SNS Event Routing Patterns — MEMORY TIPS

Topic chaining: SNS → SNS → SQS for multi‑layer routing.
Fan‑out to microservices: Each service gets its own SQS queue.
Priority routing: Use multiple topics for priority levels.
Geo‑routing: Use message attributes to route by region.
Multi‑tenant routing: Use attributes to isolate tenants.
Audit logging: SNS → SQS → S3 for audit trails.
Dead‑letter topics: Capture failed deliveries.
SNS + EventBridge: SNS triggers EventBridge rules.
SNS + Lambda for real‑time transformations.
Exam keyword: “filter events before delivery” → SNS Message Filtering.

⭐ SET 103 — Advanced Glue Streaming

🟩 Glue Streaming Deep — MEMORY TIPS

Glue Streaming uses Spark Structured Streaming under the hood.
Supports Kinesis, Kafka, MSK, DynamoDB Streams.
Micro‑batching processes data in small intervals.
Checkpointing ensures fault tolerance.
Schema inference auto‑detects structure of streaming data.
Glue Catalog stores streaming table metadata.
ETL transformations (joins, filters, enrichments) applied in real‑time.
Output to S3 in Parquet/ORC for analytics.
Autoscaling adjusts compute based on throughput.
Exam keyword: “real‑time ETL on streaming data” → Glue Streaming.

🟩 Glue Streaming Use Cases — MEMORY TIPS

Real‑time log enrichment.
IoT sensor data processing.
Clickstream analytics.
Fraud detection pipelines.
Real‑time ETL before S3 ingestion.
Social media sentiment analysis.
Real‑time data quality checks.
Streaming joins with reference data.
Real‑time partitioning into S3.
Exam keyword: “real‑time ETL before S3” → Glue Streaming.

⭐ SET 104 — Advanced Redshift Workload Management

🟩 Redshift WLM Deep — MEMORY TIPS

WLM (Workload Management) controls query queues.
Short Query Acceleration (SQA) prioritizes small queries.
Concurrency Scaling adds temporary clusters for peak load.
Query Priorities assign importance to workloads.
Query Monitoring Rules detect long‑running queries.
Automatic WLM uses ML to optimize queues.
Materialized views reduce load on WLM.
Spectrum offloads cold data queries to S3.
Result caching reduces repeated query load.
Exam keyword: “handle mixed workloads efficiently” → WLM.

🟩 Redshift Performance Governance — MEMORY TIPS

Use sort keys for range queries.
Use distribution keys for join optimization.
Use compression encoding to reduce I/O.
Use VACUUM to reclaim space.
Use ANALYZE to update statistics.
Use Spectrum for S3 external tables.
Use RA3 for compute/storage separation.
Use AQUA for hardware‑accelerated scans.
Use materialized views for repeated queries.
Exam keyword: “optimize join performance” → Distribution Key.

⭐ SET 105 — Advanced CloudFront Security Automation

🟩 CloudFront Security Automation — MEMORY TIPS

WAF rules auto‑block SQLi, XSS, bots.
Bot Control blocks scrapers + automated attacks.
Rate‑based rules throttle abusive IPs.
Geo‑blocking restricts access by country.
Lambda@Edge enforces custom auth logic.
Header sanitization removes sensitive headers.
Signed URLs/Cookies protect premium content.
OAC blocks direct S3 access.
Shield Advanced protects against DDoS.
Exam keyword: “automated global security at edge” → CloudFront + WAF.

🟩 CloudFront Threat Detection — MEMORY TIPS

Real‑time logs detect anomalies.
Athena queries analyze CloudFront logs.
GuardDuty detects suspicious traffic patterns.
WAF logging identifies blocked requests.
IP reputation lists block known bad actors.
Lambda@Edge blocks malicious user agents.
CloudWatch alarms detect traffic spikes.
Origin Shield protects origin from attack floods.
Custom error pages hide backend details.
Exam keyword: “detect & block threats at edge” → WAF + Lambda@Edge.

Absolutely Savi — here are SET 106 to SET 110, each with 10+ advanced, tech‑layman, exam‑focused points per subtitle, in the exact crisp style you prefer.

Every bullet begins with a Guided Link, exactly as required.

⭐ SET 106 — Advanced S3 Governance

🟩 S3 Governance Deep — MEMORY TIPS

S3 Block Public Access overrides bucket policies — strongest protection.
Object Ownership (Bucket Owner Enforced) removes ACLs entirely — exam favourite.
S3 Access Points simplify multi‑team access with per‑team policies.
Access Point Policies allow fine‑grained control per application.
S3 Object Lock enforces immutability (WORM) for compliance.
Retention Modes: Governance vs Compliance mode — compliance cannot be bypassed.
S3 Inventory provides daily/weekly object metadata reports.
S3 Replication + Ownership Transfer ensures destination bucket owns replicated objects.
S3 Access Analyzer detects unintended public access.
Exam keyword: “disable ACLs + enforce ownership” → Bucket Owner Enforced.

🟩 S3 Governance Automation — MEMORY TIPS

Lifecycle Policies automate tiering + deletion.
Replication Rules enforce cross‑region compliance.
EventBridge triggers governance workflows (tagging, scanning).
Macie scans for sensitive data (PII).
Config Rules detect non‑compliant buckets.
CloudTrail logs all S3 API actions.
KMS Key Policies enforce encryption governance.
S3 Batch Operations apply governance at scale.
Tag Policies enforce consistent tagging across accounts.
Exam keyword: “automate S3 compliance checks” → Config + Macie.

⭐ SET 107 — Advanced EKS Security

🟩 EKS Security Deep — MEMORY TIPS

IRSA (IAM Roles for Service Accounts) gives pod‑level IAM permissions — exam gold.
Security Groups for Pods allow ENI‑level firewalling per pod.
Network Policies restrict pod‑to‑pod communication (zero‑trust).
Private Cluster hides API server from public internet.
Secrets Encryption via KMS envelope encryption.
Audit Logs capture API server activity.
Pod Security Standards enforce restricted/privileged modes.
EKS Managed Node Groups ensure secure AMIs + patching.
Runtime security via Falco or AWS Partner tools.
Exam keyword: “pod‑level IAM permissions” → IRSA.

🟩 EKS Zero‑Trust Patterns — MEMORY TIPS

No pod‑to‑pod trust without Network Policies.
Ingress Controller enforces L7 rules.
mTLS between microservices via service mesh (App Mesh/Istio).
Restrict egress using SGs + NACLs.
Use PrivateLink for AWS API access.
Use OIDC provider for IRSA.
Use KMS for secrets encryption.
Use CloudTrail for cluster API auditing.
Use GuardDuty EKS Protection for anomaly detection.
Exam keyword: “zero‑trust Kubernetes” → Network Policies + IRSA.

⭐ SET 108 — Advanced ECS Autoscaling

🟩 ECS Autoscaling Deep — MEMORY TIPS

Service Auto Scaling scales tasks based on CPU/memory/ALB request count.
Cluster Auto Scaling (CAS) scales EC2 capacity automatically.
Target Tracking Policies maintain desired utilization.
Step Scaling reacts to thresholds (e.g., CPU > 80%).
Scheduled Scaling handles predictable traffic patterns.
Fargate tasks scale instantly without EC2 management.
Dynamic Port Mapping allows many tasks per host.
Capacity Providers manage Spot + On‑Demand mix.
Managed Scaling optimizes cluster capacity.
Exam keyword: “scale ECS tasks automatically” → Service Auto Scaling.

🟩 ECS Capacity Providers — MEMORY TIPS

Define On‑Demand and Spot capacity pools.
Managed Scaling adjusts EC2 capacity automatically.
Managed Termination Protection prevents Spot interruptions mid‑task.
Weighting controls how much traffic goes to each provider.
Base + Weight model ensures minimum On‑Demand capacity.
Works with Auto Scaling Groups.
Supports Fargate + Fargate Spot.
Great for cost‑optimized clusters.
Reduces manual EC2 scaling.
Exam keyword: “mix Spot + On‑Demand automatically” → Capacity Providers.

⭐ SET 109 — Advanced API Gateway Observability

🟩 API Gateway Observability Deep — MEMORY TIPS

Access Logs capture request metadata (latency, IP, status).
Execution Logs show integration details (Lambda errors, mapping failures).
X‑Ray Tracing shows end‑to‑end request flow.
Detailed Metrics include 4xx, 5xx, latency, integration latency.
Custom Metrics track business KPIs.
CloudWatch Dashboards visualize API performance.
WAF Logs show blocked requests.
Usage Plans track per‑client usage.
API Keys identify clients for monitoring.
Exam keyword: “trace API → Lambda → DB” → X‑Ray.

🟩 API Gateway Failure Analysis — MEMORY TIPS

4xx errors = client issues (bad request, unauthorized).
5xx errors = backend issues (Lambda crash, timeout).
Integration latency identifies slow backend.
Mapping template errors cause 500s.
Throttling returns 429 errors.
WAF blocks return 403.
CORS misconfig causes browser failures.
DLQs capture failed async Lambda events.
CloudWatch alarms detect spikes in errors.
Exam keyword: “debug API Gateway 500 errors” → Check integration logs.

⭐ SET 110 — Advanced EventBridge Architectures

🟩 EventBridge Architecture Deep — MEMORY TIPS

Event buses isolate event domains (default, custom, partner).
Event patterns match events by fields (source, detail‑type).
Targets include Lambda, SQS, SNS, Step Functions, Kinesis.
Cross‑account routing supported via resource policies.
Schema Registry auto‑discovers event structure.
Event Replay via EventBridge Archives.
Pipes connect source → filter → enrich → target.
Filtering reduces unnecessary invocations.
SaaS integrations (Datadog, Zendesk, Auth0).
Exam keyword: “event routing + filtering” → EventBridge.

🟩 EventBridge Multi‑Service Patterns — MEMORY TIPS

Choreography pattern: Services react to events without central orchestrator.
Fan‑out pattern: One event triggers multiple services.
Event enrichment: Pipes call Lambda to add metadata.
Event filtering: Only relevant services receive events.
Dead‑letter buses capture failed events.
Cross‑region routing for global architectures.
Event versioning via Schema Registry.
Event replay for debugging or reprocessing.
EventBridge + Step Functions = hybrid orchestration + choreography.
Exam keyword: “decouple microservices with events” → EventBridge.

Comprehend

Comprehend is used to analyse text — find entities, sentiment, key phrases, PII, topics, and more.

🧠 What Comprehend is used for

Each item starts with a Guided Link so you can dive deeper if you want.

Entity Extraction — finds names, places, dates, products, ingredients, etc.
Sentiment Analysis — tells if text is positive, negative, neutral, or mixed.
PII Detection — detects personal data like phone numbers, emails, addresses.
Key Phrase Extraction — identifies the main ideas in text.
Language Detection — detects which language the text is written in.
Topic Modelling — groups documents by themes.
Custom Classification — classify text into your own categories.
Custom Entity Recognition — detect domain‑specific entities (e.g., medical terms, ingredients).

Absolutely Savi — here are SET 111 to SET 115, each with 10+ advanced, tech‑layman, exam‑focused points per subtitle, in the exact crisp style you prefer.

Every bullet begins with a Guided Link, exactly as required.

⭐ SET 111 — Advanced Lambda Networking

🟩 Lambda Networking Deep — MEMORY TIPS

Lambda in a VPC attaches an ENI to your subnet — enables private DB/VPC access.
Cold starts slower for VPC Lambdas due to ENI creation (improved but still relevant).
Subnet choice matters — use private subnets for DB access, public only if needed.
Security Groups apply to Lambda ENIs just like EC2.
VPC Endpoints eliminate NAT Gateway cost for AWS API calls.
Interface Endpoints required for DynamoDB, SSM, Secrets Manager, KMS.
Gateway Endpoints required for S3/DynamoDB private access.
NAT Gateway needed only if Lambda must reach the internet.
DNS resolution must be enabled for VPC endpoints to work.
Exam keyword: “Lambda needs private DB access” → Put Lambda in VPC + SG rules.

🟩 Lambda Networking Optimization — MEMORY TIPS

Use VPC endpoints to avoid NAT Gateway bottlenecks.
Use smaller subnets to reduce ENI exhaustion.
Use Provisioned Concurrency to reduce VPC cold starts.
Use shared ENIs for faster scaling (new Lambda networking model).
Use RDS Proxy to reduce DB connection storms.
Use SG referencing for secure Lambda → DB access.
Use multi‑AZ subnets for HA.
Use CloudWatch metrics to detect ENI creation delays.
Use private DNS for internal service discovery.
Exam keyword: “reduce VPC cold start latency” → Provisioned Concurrency.

⭐ SET 112 — Advanced DynamoDB Security

🟩 DynamoDB Security Deep — MEMORY TIPS

IAM policies control all access — no resource‑level ACLs.
Fine‑grained access control via IAM conditions on partition keys.
Encryption at rest enabled by default (KMS).
KMS CMKs allow audit logging + fine‑grained key control.
VPC Endpoints allow private DynamoDB access.
DAX uses IAM auth + SGs for security.
Streams require IAM permissions for Lambda consumers.
Backup & Restore fully encrypted.
Point‑in‑Time Recovery (PITR) protects against accidental deletes.
Exam keyword: “row‑level access control” → IAM Condition Keys.

🟩 DynamoDB Zero‑Trust Patterns — MEMORY TIPS

Use IAM conditions to restrict access by tenant ID.
Use VPC endpoints to block public DynamoDB access.
Use KMS key policies to restrict encryption access.
Use CloudTrail to audit all DynamoDB API calls.
Use DynamoDB Streams for anomaly detection pipelines.
Use TTL to auto‑expire sensitive data.
Use encryption context for KMS‑based row‑level security.
Use least privilege IAM roles for Lambda/ECS.
Use GuardDuty to detect suspicious DynamoDB activity.
Exam keyword: “tenant‑isolated DynamoDB access” → IAM Condition Keys.

⭐ SET 113 — Advanced CloudFront Multi‑Region

🟩 CloudFront Multi‑Region Deep — MEMORY TIPS

CloudFront caches content globally at edge locations.
Regional Edge Caches reduce cache misses for large objects.
Origin Shield centralizes caching before origin — best for multi‑region origins.
Multi‑origin routing: /api/* → region A, /static/* → region B.
Failover origins provide multi‑region HA.
Lambda@Edge rewrites requests to nearest region.
Geo‑routing serves region‑specific content.
Signed URLs/Cookies secure multi‑region premium content.
OAC protects S3 origins in all regions.
Exam keyword: “global multi‑region content delivery” → CloudFront + Origin Shield.

🟩 CloudFront Multi‑Region Failover — MEMORY TIPS

Origin Groups: primary region + failover region.
Health checks determine failover.
CloudFront continues serving cached content even if origin down.
Lambda@Edge can dynamically reroute traffic.
S3 Multi‑Region Access Points provide global S3 failover.
Route 53 Latency Routing pairs well with CloudFront.
Shield Advanced protects multi‑region origins from DDoS.
WAF blocks malicious traffic globally.
Custom error pages hide backend failures.
Exam keyword: “global failover with caching” → CloudFront Origin Groups.

⭐ SET 114 — Advanced S3 Analytics

🟩 S3 Analytics Deep — MEMORY TIPS

S3 Storage Class Analysis identifies objects for tiering (IA/Glacier).
S3 Inventory provides daily/weekly metadata reports.
S3 Access Logs track request patterns.
Athena queries S3 logs + inventory directly.
CloudWatch Metrics track bucket size + request counts.
S3 Select queries partial objects for analytics.
S3 Object Lambda transforms data on the fly.
S3 Batch Operations apply analytics‑driven actions at scale.
Macie scans for PII in S3 data.
Exam keyword: “identify objects for lifecycle tiering” → Storage Class Analysis.

🟩 S3 Data Lake Analytics — MEMORY TIPS

Athena queries S3 using SQL — serverless.
Glue Catalog stores table metadata.
Parquet/ORC formats reduce cost + improve speed.
Partitioning improves query performance (date/hour).
Redshift Spectrum queries S3 external tables.
EMR runs Spark/Hive on S3 data.
Kinesis/Firehose ingest streaming data into S3.
Lake Formation enforces fine‑grained permissions.
S3 Select reduces data scanned.
Exam keyword: “query S3 without loading” → Athena + Spectrum.

⭐ SET 115 — Advanced Serverless Cost Optimization

🟩 Serverless Cost Optimization Deep — MEMORY TIPS

Lambda memory tuning: more memory = more CPU = faster execution = lower cost.
Provisioned Concurrency only for latency‑critical APIs.
SQS batching reduces Lambda invocations.
Kinesis batch size reduces cost for stream processing.
API Gateway HTTP API is cheaper than REST API.
DynamoDB On‑Demand for unpredictable workloads.
DynamoDB TTL auto‑deletes unused data.
S3 Intelligent‑Tiering auto‑optimizes storage cost.
CloudFront caching reduces origin cost.
Exam keyword: “reduce Lambda cost” → Increase memory for faster execution.

🟩 Serverless Architecture Cost Patterns — MEMORY TIPS

Use EventBridge instead of polling loops.
Use SNS + SQS for fan‑out instead of multiple Lambdas.
Use S3 pre‑signed URLs for large uploads instead of API Gateway.
Use DynamoDB Streams instead of periodic scans.
Use CloudWatch Logs retention policies to reduce log cost.
Use Athena instead of EMR for ad‑hoc queries.
Use S3 Glacier for long‑term storage.
Use Lambda Layers to reduce package size.
Use RDS Proxy to reduce DB connection cost.
Exam keyword: “avoid polling + reduce invocations” → EventBridge.

Absolutely Savi — here are SET 116 to SET 120, each with 10+ advanced, tech‑layman, exam‑focused points per subtitle, in the exact crisp style you prefer.

Every bullet begins with a Guided Link, exactly as required.

⭐ SET 116 — Advanced VPC Flow Logs

🟩 VPC Flow Logs Deep — MEMORY TIPS

Flow Logs capture ACCEPT and REJECT traffic at VPC, subnet, or ENI level.
Logs include source/destination IP, ports, protocol, action, bytes.
Stored in CloudWatch Logs or S3 for long‑term analysis.
REJECT entries help diagnose NACL/security group issues.
Flow Logs do NOT capture: DNS traffic, Windows license traffic, metadata calls.
Traffic Mirroring is for packet capture; Flow Logs are metadata only.
Use Athena to query Flow Logs stored in S3.
Use VPC Lattice + Flow Logs for service‑to‑service visibility.
Use GuardDuty to detect anomalies from Flow Logs.
Exam keyword: “diagnose SG/NACL issues” → VPC Flow Logs.

🟩 VPC Flow Logs Optimization — MEMORY TIPS

Use Hive‑style partitioning in S3 for faster Athena queries.
Use Parquet conversion for cheaper analytics.
Use S3 Lifecycle to move logs to Glacier.
Use Athena Views for reusable queries.
Use CloudWatch Metric Filters to detect suspicious IPs.
Use Kinesis Firehose to stream logs to SIEM tools.
Use Flow Log aggregation to reduce log volume.
Use VPC Flow Logs at ENI level for fine‑grained debugging.
Use S3 Access Points for multi‑team analytics.
Exam keyword: “query Flow Logs efficiently” → Athena + Parquet.

⭐ SET 117 — Advanced CloudTrail Governance

🟩 CloudTrail Governance Deep — MEMORY TIPS

Organization Trails apply to all accounts automatically.
Multi‑Region Trails ensure global API visibility.
CloudTrail Insights detect unusual API spikes.
Log File Validation ensures tamper detection.
S3 Object Lock makes CloudTrail logs immutable.
Dedicated Log Archive Account recommended (Control Tower pattern).
KMS encryption protects logs at rest.
EventBridge rules trigger alerts on sensitive actions.
CloudTrail Lake allows SQL queries on audit logs.
Exam keyword: “immutable audit logs” → S3 Object Lock + CloudTrail.

🟩 CloudTrail Compliance Patterns — MEMORY TIPS

PCI/HIPAA/SOX require full audit logging.
CloudTrail Lake supports compliance queries.
Config Rules detect missing trails.
GuardDuty detects suspicious API calls.
Access Analyzer detects public resources.
S3 Bucket Policies restrict log access.
SNS alerts for IAM changes.
CloudWatch alarms for root user activity.
Cross‑account log sharing for central governance.
Exam keyword: “audit IAM changes” → CloudTrail + SNS.

⭐ SET 118 — Advanced Kinesis Firehose

🟩 Firehose Deep Architecture — MEMORY TIPS

Fully managed — no shards, no scaling management.
Delivers to S3, Redshift, OpenSearch, HTTP endpoints.
Buffer size/time controls delivery frequency.
Lambda transforms allow JSON → Parquet/ORC conversion.
Dynamic partitioning organizes S3 data by keys (e.g., date/user).
Compression reduces S3 cost (GZIP, Snappy).
Near‑real‑time, not real‑time (1–60 sec delay).
Retry logic handles temporary delivery failures.
No replay — once delivered, cannot reprocess.
Exam keyword: “deliver streaming data to S3 automatically” → Firehose.

🟩 Firehose Optimization Patterns — MEMORY TIPS

Use Parquet for analytics efficiency.
Use Hive partitioning for Athena queries.
Use S3 prefixing for time‑based partitioning.
Use Lambda transform for schema normalization.
Use VPC delivery for private Redshift/OpenSearch access.
Use CloudWatch metrics to tune buffer size.
Use KMS encryption for compliance.
Use Firehose error logs for debugging.
Use S3 Lifecycle to tier old data.
Exam keyword: “optimize S3 analytics pipeline” → Parquet + partitioning.

⭐ SET 119 — Advanced Glue Catalog Security

🟩 Glue Catalog Security Deep — MEMORY TIPS

Glue Catalog stores metadata, not data — exam trap.
Lake Formation controls table/column/row‑level permissions.
LF‑Tags enable tag‑based access control.
Cross‑account sharing supported via LF grants.
KMS encryption protects metadata at rest.
Schema versioning tracks changes over time.
Audit logs captured via CloudTrail.
Partition projection reduces crawler access needs.
IAM roles required for Glue jobs + crawlers.
Exam keyword: “fine‑grained data lake permissions” → Lake Formation.

🟩 Glue Catalog Governance Patterns — MEMORY TIPS

Use LF‑Tags to classify sensitive data.
Use data filters for row‑level access.
Use S3 Access Points for multi‑team access.
Use S3 Object Lock for immutable data.
Use Athena + LF for secure SQL queries.
Use Redshift Spectrum with LF permissions.
Use EMR with LF integration.
Use Macie to detect PII in S3.
Use Config Rules to detect unprotected buckets.
Exam keyword: “centralized governance for S3 data lake” → Lake Formation.

⭐ SET 120 — Advanced Multi‑Account Networking

🟩 Multi‑Account Networking Deep — MEMORY TIPS

Transit Gateway connects VPCs across accounts centrally.
TGW RAM Sharing allows cross‑account attachments.
VPC Peering works cross‑account but no transitive routing.
PrivateLink exposes services privately across accounts.
DX Gateway connects on‑prem to multiple accounts.
Route 53 Resolver Endpoints enable cross‑account DNS.
Firewall Manager enforces org‑wide SG/NACL/WAF rules.
Service Control Policies restrict network creation actions.
Centralized egress VPC reduces NAT cost.
Exam keyword: “central hub for multi‑account routing” → Transit Gateway.

🟩 Multi‑Account Zero‑Trust Patterns — MEMORY TIPS

No implicit trust between accounts — enforce SCPs.
PrivateLink for service‑to‑service access.
Cross‑account IAM roles with external ID.
Centralized logging account for CloudTrail + VPC Flow Logs.
Centralized security account for GuardDuty + Security Hub.
Centralized DNS via Route 53 Resolver.
Network Firewall for org‑wide egress filtering.
Config Aggregators for compliance across accounts.
Tag Policies enforce consistent tagging.
Exam keyword: “zero‑trust multi‑account architecture” → PrivateLink + SCPs.

Here you go Savi — ultra‑sharp, exam‑focused tips for ALL the topics in your attached questions.
Each section gives you what to look for in the exam, how AWS wants you to think, and the keyword triggers that instantly reveal the correct answer.

Every bullet begins with a Guided Link, exactly as required.

⭐ EXAM TIPS FOR ALL TOPICS IN YOUR QUESTIONS

1️⃣ Amazon MSK – Public Access + Encryption

🟩 MSK Public Access Patterns — EXAM TIPS

MSK is normally deployed in private subnets — exam trick.
To expose MSK publicly, you must place brokers in public subnets.
Mutual TLS (mTLS) is required for secure client authentication.
MSK supports TLS in transit by default.
Avoid ALB/NLB for Kafka — Kafka uses custom TCP ports, not HTTP.
No need for a new VPC — reuse existing VPC for operational efficiency.
Public subnets must have IGW route.
Security groups must allow broker ports (9092, 9094).
Never use PrivateLink for public access — exam trap.
Keyword: “public access + encrypted” → MSK in public subnets + mTLS.

2️⃣ Aurora PostgreSQL – Scaling Reads/Writes + Minimizing Downtime

🟩 Aurora Scaling Patterns — EXAM TIPS

Add Aurora Replicas to scale reads.
Use RDS Proxy to handle connection storms.
Multi‑AZ improves availability, not read scaling.
ZDR (Zero Downtime Restart) is for maintenance, not scaling.
ElastiCache helps reads but not writes — exam trap.
Aurora auto‑failover promotes replicas.
Use Global Database for cross‑region scaling.
Use Performance Insights to detect bottlenecks.
Use serverless v2 for auto‑scaling compute.
Keyword: “read/write surge + minimal downtime” → More replicas + RDS Proxy.

3️⃣ LDAP Authentication Without SAML

🟩 LDAP Federation Patterns — EXAM TIPS

LDAP cannot integrate directly with AWS IAM or IAM Identity Center.
When SAML is missing → build a custom identity broker.
Broker authenticates LDAP → calls STS → returns temporary creds.
Use AssumeRole or GetFederationToken.
Never sync LDAP passwords to IAM — exam trap.
IAM policies do not authenticate users.
Identity Center requires AD or SAML, not plain LDAP.
Broker must run on‑prem or in AWS.
Use HTTPS for secure token exchange.
Keyword: “LDAP without SAML” → Custom identity broker + STS.

4️⃣ Oracle → Aurora PostgreSQL Migration + Change Tracking

🟩 DMS + SCT Migration Patterns — EXAM TIPS

Use SCT for schema conversion (Oracle → PostgreSQL).
Use DMS full load + CDC for ongoing changes.
VPN/Direct Connect supports DMS replication.
Snowball/DataSync do not support CDC — exam trap.
Aurora PostgreSQL supports DMS as a target.
DMS requires replication instance in same VPC.
Use LOB mode for large objects.
Use task logging for troubleshooting.
Use validation to ensure data consistency.
Keyword: “track modifications” → DMS CDC.

5️⃣ RDS Read Replica for Offloading Scripts

🟩 RDS Read Scaling Patterns — EXAM TIPS

Multi‑AZ = HA, not read scaling — exam trap.
Read replicas offload read‑heavy workloads.
Replicas are asynchronous — eventual consistency.
Use replicas for reporting, analytics, scripts.
ElastiCache helps caching, not fresh reads.
Replica can be promoted during failover.
Use read endpoints for load balancing.
Replicas cost less than scaling instance class.
Use Performance Insights to detect read bottlenecks.
Keyword: “script slowing primary” → Read Replica.

6️⃣ EC2 Recovery – Single Instance, Legacy App

🟩 EC2 Recovery Patterns — EXAM TIPS

Use CloudWatch EC2 Recovery for impaired instances.
Recovery keeps same instance ID, IP, EBS.
Multi‑AZ does not exist for EC2 — exam trap.
Termination protection prevents deletion, not failure.
RAID improves storage, not instance recovery.
Use status checks for automatic recovery.
Use Auto Recovery for hardware issues.
Use EBS snapshots for backup.
Use Elastic IP for static addressing.
Keyword: “single instance + improve recovery time” → EC2 Recovery.

7️⃣ KMS Key Deletion Protection + Alerts

🟩 KMS Deletion Protection Patterns — EXAM TIPS

Use EventBridge to detect DeleteKey API calls.
Use SSM Automation runbook to cancel deletion.
Send alerts via SNS.
CloudTrail logs deletion attempts but cannot stop them.
Config cannot block deletion — exam trap.
Lambda adds unnecessary complexity.
Use key policy to restrict deletion permissions.
Use CloudTrail Lake for audit queries.
Use KMS key rotation for compliance.
Keyword: “prevent deletion + alert” → EventBridge + SSM Automation + SNS.

8️⃣ Cross‑Account Microservices – HTTPS + Service Discovery

🟩 VPC Lattice Patterns — EXAM TIPS

VPC Lattice provides cross‑account service‑to‑service communication.
Built‑in service registry.
Supports HTTPS natively.
No need for VPC peering or PrivateLink.
No need for custom DNS.
No need for transit gateway.
Works with Lambda, EKS, ECS, EC2.
Provides authN/authZ per service.
Simplest operational model.
Keyword: “cross‑account + service discovery + HTTPS” → VPC Lattice.

9️⃣ S3 Multi‑Region Replication + Global Access

🟩 S3 Multi‑Region Patterns — EXAM TIPS

Use bidirectional replication for multi‑region uploads.
Use Multi‑Region Access Points for global routing.
MRAP reduces latency for uploads + downloads.
One‑way replication fails for multi‑region uploads — exam trap.
Snowball/DataSync not needed.
MRAP requires only one ARN change in the app.
Replication requires versioning.
Replication supports ownership transfer.
Use S3 Transfer Acceleration for global uploads.
Keyword: “global streaming + minimal app changes” → MRAP + bidirectional replication.

🔟 Scheduled Tasks Migration – Minimal Code Change

🟩 EventBridge Scheduler + Fargate Patterns — EXAM TIPS

Package tasks into containers.
Use EventBridge Scheduler for cron‑like schedules.
Use Fargate for tasks lasting 1–20 minutes.
Lambda max runtime = 15 minutes — exam trap.
Step Functions adds unnecessary complexity.
AWS Batch is for large batch jobs, not scheduled tasks.
Fargate removes server management.
Scheduler supports future events.
Supports retry policies.
Keyword: “scheduled tasks 1–20 min + minimal changes” → EventBridge Scheduler + Fargate.

1️⃣1️⃣ Private App Access Only from Office + Internet Updates

🟩 Internal ALB + Private Subnets Patterns — EXAM TIPS

Use private subnets for app servers.
Use internal ALB for corporate‑only access.
Use Site‑to‑Site VPN for office connectivity.
Use NAT Gateway in public subnet for outbound updates.
Public ALB violates requirement — exam trap.
NAT must be in public subnet, not private.
Security group must allow office CIDR only.
No need for WAF or firewall.
No need for public subnets for app.
Keyword: “office‑only access + internet updates” → Private subnets + internal ALB + NAT.

1️⃣2️⃣ Gaming App – Low Latency + Snapshot + Duplication

🟩 ElastiCache Redis Patterns — EXAM TIPS

Redis = microsecond latency.
Redis supports snapshots.
Redis supports replication.
Redis reduces load on RDS.
Aurora replicas improve reads but not latency.
DynamoDB requires app rewrite — exam trap.
Memcached lacks persistence.
Redis supports pub/sub for game events.
Redis supports cluster mode for scaling.
Keyword: “very low latency + snapshot” → ElastiCache Redis.

AWS Recycle Bin allows you to set retention rules for:

AMIs
Snapshots

When someone deletes an AMI:

It does NOT get permanently deleted
It goes into the Recycle Bin
You can restore it instantly
No scripts, no cross‑account copies, no manual work

⭐ Is ECS on Fargate with EFS serverless? → YES

Here’s the clean, exam‑cram reasoning:

1️⃣ Fargate = serverless compute for containers

With AWS Fargate:

You don’t manage EC2 instances
You don’t manage clusters or nodes
You don’t patch servers
You pay per vCPU + memory per second

This is the definition of serverless container compute.

⭐ 2️⃣ EFS = serverless storage

Amazon EFS is also serverless:

No provisioning
No capacity planning
Auto‑scales
Fully managed
Pay‑as‑you‑go

So combining Fargate + EFS is a fully serverless architecture.

⭐ 3️⃣ ECS control plane is also serverless

Amazon ECS itself has a serverless control plane:

No cluster management
No control plane cost
No master nodes

So the entire stack remains serverless.

DynamoDB defaults to eventually consistent reads, which may return old data for a short time. The question explicitly says:

Queries are not fetching the most recent data
Users are NOT complaining about speed
Response time is acceptable

This is the classic exam clue that the architect should switch to strong consistency.

Strongly consistent reads guarantee:

Always the latest committed write
No stale reads
Minimal performance impact (since users already find performance acceptable)

⭐ Why the other options are wrong

A. Read replicas — DynamoDB does not have read replicas (Aurora does).
B. GSI — GSIs help with query patterns, not consistency.
D. Eventually consistent reads — This is the cause of the problem, not the solution.

⭐ Exam‑cram memory hook

Stale reads in DynamoDB + performance OK → switch to strong consistency.

Existing identity provider (IdP) (e.g., Okta, Azure AD/Entra ID, Google Workspace, AD FS)

The question gives you three strong clues:

10 AWS accounts under AWS Organizations
Thousands of employees
Must authenticate using an existing IdP (e.g., Okta, Azure AD/Entra ID, Google Workspace, AD FS)

This is the exact scenario AWS designed IAM Identity Center for.

IAM Identity Center provides:

Centralized login for all AWS accounts
Integration with external IdPs via SAML or SCIM
Group‑based permission sets
No IAM users needed
Scales to thousands of users
Least operational overhead

This is the AWS‑recommended and exam‑expected answer.

Volume type

io1 max IOPS → 64,000 IOPS
io2 max IOPS → 64,000 IOPS (more durable)
gp3 max IOPS → 16,000 IOPS

gp2 max IOPS → 3,000 IOPS

ECS = you manage servers (EC2). Cheaper but more work. Fargate = AWS manages servers. Easier but costs more.

Amazon SQS to queue events allows for effective scaling and load balancing of events before they are processed by AWS Lambda. Amazon SQS can handle a large number of messages, and the Lambda function can be triggered based on the events in the queue, allowing for better management of burst traffic and retries, which is a scalable solution

FSx for ONTAP uses NetApp SnapMirror to replicate data to a secondary FSx ONTAP or on‑prem system.

⭐ What the scenario means (in simple terms)

The company has:

200 DNS zones (many domains/subdomains)
1 million DNS queries per day
They want high availability (DNS should never go down)
They want less work (no more managing DNS servers)

So they want a DNS service that is:

Highly available
Fully managed
Scales automatically
Requires no server maintenance

This is exactly what Amazon Route 53 is designed for.

A business needs to grant 1,500 users access to AWS resources without creating separate identities, as access to on-premises resources is managed via Active Directory groups.

Use SAML 2.0 Federation
This lets users sign in to AWS using their existing Active Directory username and password — no new AWS accounts needed.
Keep identity management in Active Directory All users stay in AD. You don’t create IAM users in AWS.
All users stay in AD. You don’t create IAM users in AWS.
Create IAM Roles in AWS Each role represents a permission set (e.g., Admin, Developer, Read‑Only).
Each role represents a permission set (e.g., Admin, Developer, Read‑Only).
Map AD Groups → IAM Roles If a user is in an AD group, they automatically get the matching AWS role when they log in.
If a user is in an AD group, they automatically get the matching AWS role when they log in.
AWS trusts your Identity Provider (IdP) AD FS, Azure AD, Ping, Okta, etc. send a
AD FS, Azure AD, Ping, Okta, etc. send a SAML assertion to AWS proving the user’s identity.
Scales easily for thousands of users No need to manage 1,500 IAM users — just manage AD groups.
No need to manage 1,500 IAM users — just manage AD groups.

Temporary Cluster vs Long‑Term Cluster (Simple Table)

Type	Temporary Cluster	Long‑Term Cluster
Purpose	Short‑lived compute for jobs	Always‑on analytics or storage
Lifetime	Minutes to hours	Weeks to years
Cost Model	Pay only when running	Continuous cost (24/7)
Data Storage	External (S3, DynamoDB)	Internal (HDFS, local disks, cluster storage)
Statefulness	Stateless	Stateful
Scaling	Spin up → run job → terminate	Scale in/out but cluster persists
Best For	Batch jobs, ETL, Spark, MapReduce	BI dashboards, warehouses, persistent workloads
Examples	EMR transient cluster, Glue jobs, ephemeral Redshift RA3 compute	Redshift provisioned, EMR long‑running, FSx ONTAP clusters
Ops Overhead	Very low	Higher (patching, monitoring, tuning)
Data Durability	S3 provides durability	Cluster storage must be maintained
Cost Efficiency	Extremely high for intermittent workloads	High only if cluster is used constantly

⭐ Simple Explanation

Temporary Cluster

A cluster that exists only to run a job. After the job finishes → cluster is terminated. Data lives in S3, not the cluster.

Think: EMR cluster that runs Spark for 20 minutes and shuts down.

Long‑Term Cluster

A cluster that stays running all the time. Used for continuous analytics, dashboards, or workloads that need persistent storage.

Think: Redshift cluster used by analysts every day.

AWS Storage Gateway

AWS Storage Gateway – File Gateway and its backend storage is Amazon S3.

So people often call it:

S3 File Gateway
File Gateway for S3
S3-backed File Gateway
NFS and SMB file shares
Backed by Amazon S3 buckets
With local caching for performance
Automatic upload of files to S3

⭐ AWS DataSync — Key Exam Tips

1. Purpose‑built for automated data transfer

DataSync is designed specifically to move data between S3, EFS, FSx, NFS, SMB, and on‑prem storage with zero manual scripting.

2. Transfers only changed data

DataSync automatically detects:

Modified files
New files
Deleted files (optional)

This makes it perfect for incremental updates.

3. Minimal operational overhead

No cron jobs, no rsync scripts, no custom Lambda logic.
Just configure a task → schedule → done.

4. High‑performance, parallelized transfer

DataSync uses a purpose‑built protocol that is:

Faster than VPN copy
Faster than rsync
Optimized for WAN and Direct Connect

5. Ideal for recurring sync jobs

Weekly, daily, hourly — DataSync handles it automatically.

6. Secure and managed

Encryption in transit
IAM‑controlled access
Automatic verification of transferred data

7. Perfect match for “replace only if updated”

Because DataSync compares metadata and checksums, it only moves changed files, reducing cost and time.

🔹 Core idea: When to choose AWS Local Zones

Keyword trigger:
“Ultra‑low latency” + “need to run services near users” + “compliance/location constraints” → AWS Local Zones.
What Local Zones do:
- Extend your VPC into specific metro areas.
- Let you run compute, storage, databases closer to users.
- Still fully part of your AWS Region (managed by AWS).
Latency:
- Typically single‑digit milliseconds to end users in that metro area.
Compliance angle:
- You can choose where workloads run (specific city/metro), helping with data residency / locality.

🔹 Why CloudFront / Edge Location is NOT correct here

CloudFront = content delivery, not compute hosting.
Edge locations:
- Cache content (static + dynamic) close to users.
- Do not host your main application services (EC2, RDS, etc.).
So:
- Good for faster content delivery,
- Not for “must host the application in a specific location for compliance.”

Exam phrase to remember:

“Extend VPC to run services near users” → Local Zones, not CloudFront.

🔹 Quick comparison: Local Zone vs CloudFront

Local Zone:
- Run EC2, EBS, some managed services near users.
- Part of your VPC.
- Used for latency‑sensitive applications + compliance.
CloudFront (Edge):
- Cache content from an origin (S3, ALB, EC2, etc.).
- No general‑purpose compute (beyond Lambda@Edge for small functions).
- Used for content acceleration, not full app hosting.

The two best options to prevent your MySQL database on Amazon RDS from becoming a bottleneck are:

Using Amazon RDS Read Replicas: Read replicas allow you to offload read traffic from your primary database instance. Since most web applications involve a significant amount of read operations, directing these reads to read replicas frees up the primary instance to handle writes and other critical tasks, thus reducing the load and preventing it from becoming a bottleneck.
Placing Amazon ElastiCache in front of a MySQL database on RDS: ElastiCache acts as a caching layer. By caching frequently accessed data, you can significantly reduce the number of queries that hit the database. This reduces the load on the database and improves performance, preventing it from becoming a bottleneck.

IPV6

A. Egress-Only Internet Gateway

An Egress-Only Internet Gateway (EIGW) allows outbound IPv6 traffic from instances in a private subnet to the internet while blocking unsolicited inbound traffic. This ensures secure outbound communication without requiring a public IPv6 address. It is a fully managed service by AWS, scales automatically, and does not incur additional costs beyond standard data transfer charges.
Egress-Only Internet Gateway is specifically designed for IPv6 traffic in a VPC. It allows instances in a private subnet to initiate outbound traffic to the internet (egress) while preventing unsolicited inbound traffic from the internet.
It scales automatically and does not incur additional costs beyond the standard data transfer fees.
It is the only service in the list that supports IPv6 traffic to the internet for private subnets.
An Egress-Only Internet Gateway is the only option that provides IPv6 connectivity to the internet for instances in a private subnet without incurring additional costs. It’s specifically designed for outbound IPv6 traffic. This aligns perfectly with the question’s requirements.

Sunday, 7 June 2026

AWS Tips

⭐ Design Secure Access to AWS Resources

🔹 Root User Security

The root user has full, unrestricted access to the AWS account. Should be used only for initial setup tasks, such as: Creating the first IAM admin user Setting up billing Enabling MFA After initial setup: Lock it away Enable MFA immediately Never use it for daily operations

🔹 IAM Users (Daily Operational Identities)

Represent individual people or applications needing AWS access. Used for day‑to‑day operations, not administrative bootstrap tasks. Each user should have: Unique credentials Permissions based on job role MFA enabled

🔹 Key IAM Security Best Practices

1. Principle of Least Privilege

Grant only the permissions required for the task. Avoid broad permissions like AdministratorAccess unless absolutely necessary.

2. Multi‑Factor Authentication (MFA)

Mandatory for: Root user All IAM users Adds a second authentication factor (authenticator app, hardware key). Protects against compromised passwords.

3. Strong Password Policies

Enforce: Minimum length Complexity (uppercase, lowercase, numbers, symbols) Regular rotation Prevents weak password vulnerabilities.

4. Regular Credential Rotation

Rotate IAM access keys frequently. Never embed access keys in code. Use IAM roles for EC2, Lambda, ECS, etc.

5. Monitor Activity

Use AWS CloudTrail to log all API calls. Detect suspicious or unauthorized activity. Enable CloudTrail in all regions.

⭐ Designing a Flexible Authorization Model (IAM Users, Groups, Roles, Policies)

🔹 IAM Users

Represent individual identities. Can have policies attached directly, but: Hard to manage at scale Not recommended for large teams

🔹 IAM Groups

Collections of IAM users. Simplify permission management: Attach policies to groups Users inherit group permissions Best practice for teams with similar job functions.

🔹 IAM Roles

Roles provide temporary credentials via AWS STS. Used by:

1. AWS Services

EC2, Lambda, ECS tasks, etc. Preferred method for applications to access AWS resources. Eliminates need for embedded credentials.

2. Federated Users

Users from corporate directories (AD, Okta, Azure AD). Access AWS without creating IAM users. Improves security and centralizes identity management.

3. Cross‑Account IAM Users

Users in Account A can access resources in Account B. Achieved by: Creating a role in the resource account Adding a trust policy Allowing the principal to assume the role

🔹 IAM Policies

Policies define permissions in JSON format.

Policy Components

Actions — what actions are allowed (e.g., s3:GetObject) Resources — which resources the actions apply to Effect — Allow or Deny

Types of IAM Policies

1. AWS Managed Policies

Predefined by AWS Good starting point Updated automatically by AWS

2. Customer Managed Policies

Created and managed by you Recommended for specific business requirements Reusable and version‑controlled

3. Inline Policies

Embedded directly in a user, group, or role Deleted when the entity is deleted Not reusable Use only for one‑off, tightly‑scoped permissions

⭐ Example Scenario (Fully Detailed)

⭐ S3 IMMUTABILITY — ULTRA‑CRISP EXAM TIPS

S3 Retrieval Time Table

S3 Storage Lens can3detect incomplete multipart uploads

🟩 1. Compliance Mode = “NO ONE can delete — not even root”

🟩 2. Governance Mode = “Protected, but override allowed”

🟩 3. Glacier Vault Lock = WORM for Glacier Vaults ONLY

🟩 4. MFA Delete = NOT compliance, NOT WORM

🟩 5. Versioning = Recover from accidental deletes/overwrites

⭐ SET 2 — S3 SECURITY & ACCESS CONTROL

🟩 Block Public Access — MEMORY TIPS

When to Use Block Public Access (Exam Triggers)

🟩 CloudTrail Data Events — MEMORY TIPS

🟩 CloudTrail — MEMORY TIPS

🟩 CloudTrail Insights — MEMORY TIPS

🟩 S3 Access Logs — MEMORY TIPS

🟩 S3 Replication — MEMORY TIPS

🟩 Default Encryption — MEMORY TIPS

🟩 Pre‑Signed URLs — MEMORY TIPS

⭐ SUPER‑FAST MASTER TABLE (MEMORIZE THIS)

⭐ SET 3 — S3 LIFECYCLE, TIERING, SELECT, ATHENA, EVENTS, PERFORMANCE

🟩 Intelligent‑Tiering — MEMORY TIPS

🟩 S3 Select — MEMORY TIPS

🟩 Athena — MEMORY TIPS

🟩 S3 Event Notifications — MEMORY TIPS

🟩 S3 Performance Optimization — MEMORY TIPS

⭐ SUPER‑FAST MASTER TABLE (SET 3)

⭐ SET 4 — S3 ENCRYPTION, KMS, ACCESS POINTS, MRAP, STORAGE CLASSES

🟩 SSE‑S3 — MEMORY TIPS

🟩 SSE‑KMS — MEMORY TIPS

🟩 Client‑Side Encryption — MEMORY TIPS

🟩 KMS Key Policies — MEMORY TIPS

🟩 S3 Access Points — MEMORY TIPS

🟩 Multi‑Region Access Points (MRAP) — MEMORY TIPS

🟩 S3 Standard‑IA — MEMORY TIPS

🟩 One Zone‑IA — MEMORY TIPS

🟩 Glacier Instant Retrieval — MEMORY TIPS

🟩 Glacier Flexible Retrieval — MEMORY TIPS

The root user has full, unrestricted access to the AWS account.

Should be used only for initial setup tasks, such as:

Creating the first IAM admin user

Setting up billing

Enabling MFA

After initial setup:

Lock it away

Enable MFA immediately

Never use it for daily operations

Represent individual people or applications needing AWS access.

Used for day‑to‑day operations, not administrative bootstrap tasks.

Each user should have:

Unique credentials

Permissions based on job role

MFA enabled

Grant only the permissions required for the task.

Avoid broad permissions like AdministratorAccess unless absolutely necessary.

Mandatory for:

Root user

All IAM users

Adds a second authentication factor (authenticator app, hardware key).

Protects against compromised passwords.

Enforce:

Minimum length

Complexity (uppercase, lowercase, numbers, symbols)

Regular rotation

Prevents weak password vulnerabilities.

Rotate IAM access keys frequently.

Never embed access keys in code.

Use IAM roles for EC2, Lambda, ECS, etc.

Use AWS CloudTrail to log all API calls.

Detect suspicious or unauthorized activity.

Enable CloudTrail in all regions.

Represent individual identities.

Can have policies attached directly, but:

Hard to manage at scale

Not recommended for large teams

Collections of IAM users.

Simplify permission management:

Attach policies to groups

Users inherit group permissions

Best practice for teams with similar job functions.

Roles provide temporary credentials via AWS STS.
Used by:

EC2, Lambda, ECS tasks, etc.

Preferred method for applications to access AWS resources.

Eliminates need for embedded credentials.

Users from corporate directories (AD, Okta, Azure AD).

Access AWS without creating IAM users.

Improves security and centralizes identity management.

Users in Account A can access resources in Account B.

Achieved by:

Creating a role in the resource account

Adding a trust policy

Allowing the principal to assume the role

Actions — what actions are allowed (e.g., `s3:GetObject`)

Resources — which resources the actions apply to

Effect — Allow or Deny

Predefined by AWS

Good starting point

Updated automatically by AWS

Created and managed by you

Recommended for specific business requirements

Reusable and version‑controlled

Embedded directly in a user, group, or role

Deleted when the entity is deleted

Not reusable

Use only for one‑off, tightly‑scoped permissions