DynamoDB Advanced Patterns — Overview

DynamoDB advanced topics appear in 167 questions across DBS-C01 (129) and DAS-C01/DOP-C02. Beyond basic CRUD, the exam tests DynamoDB Streams, Global Tables, TTL, capacity modes, GSI/LSI design, single-table design, and DAX caching patterns.

DynamoDB Streams

Global Tables — Multi-Region

• Active-active: Read AND write in any region. Changes replicate to all other regions (typically <1 second).
• Conflict resolution: Last-writer-wins (based on timestamp). No custom conflict resolution.
• Consistency: Eventually consistent cross-region. Strongly consistent within a single region.
• Requirements: Streams must be enabled, same table name in all regions, On-Demand or provisioned with auto-scaling.
• Exam pattern: “Multi-region low-latency reads AND writes” → DynamoDB Global Tables. “Multi-region reads only” → Global Tables or cross-region read replicas.

Capacity Modes — Decision

• Burst capacity: DynamoDB saves unused capacity for up to 300 seconds. Short spikes use burst before throttling.
• Adaptive capacity: Redistributes throughput across partitions to handle hot partitions (automatic).
• Switch modes: Can switch between On-Demand and Provisioned once per 24 hours.

GSI vs LSI

TTL (Time to Live)

• What: Automatically delete items after a specified timestamp (epoch seconds)
• Cost: Free — no WCU consumed for TTL deletions
• Timing: Items typically deleted within 48 hours of expiration (not instant)
• Streams: TTL deletions appear in DynamoDB Streams (for audit/archival)
• Use cases: Session expiration, temporary data, log retention, GDPR data deletion
• Pattern: Set TTL → item expires → Stream captures deletion → Lambda archives to S3 (audit trail)

Single-Table Design

• Concept: Store multiple entity types in one table using composite keys (PK: USER#123, SK: ORDER#456)
• Why: Reduce table count, enable single-query access patterns that span entities (get user + orders in one query)
• GSI overloading: GSI with generic attribute names (GSI1PK, GSI1SK) used for multiple access patterns
• When NOT to: When entities have vastly different access patterns or RCU/WCU needs (hot partition risk)

Exam Tips

AWS Certification Exam Practice Questions

Question 1:

A company needs their DynamoDB table accessible for reads and writes in 3 regions (us-east-1, eu-west-1, ap-southeast-1) with single-digit millisecond latency for local users. What is the simplest solution?

1. DynamoDB Streams + Lambda to replicate items to tables in other regions
2. DynamoDB Global Tables — enable replication to all 3 regions for active-active access
3. DynamoDB with DAX in each region + cross-region read replicas
4. S3 cross-region replication with DynamoDB in each region synced manually

Question 2:

A web application stores user sessions in DynamoDB. Sessions should automatically expire after 24 hours without the application explicitly deleting them. The company also needs to know which sessions were cleaned up (for audit). Which features achieve this?

1. CloudWatch Events scheduled to scan and delete old items every hour
2. TTL attribute set to creation_time + 24 hours. DynamoDB Streams captures TTL deletions → Lambda writes to audit log.
3. DynamoDB Auto Scaling to remove old partitions
4. Glue job that scans for expired items and deletes them nightly

Question 3:

A table’s provisioned capacity is set to 1000 WCU evenly across 4 partitions (250 WCU each). One partition receives 80% of writes (hot partition) and gets throttled. The table has burst capacity available. How does DynamoDB handle this?

1. All writes to the hot partition are throttled — must redesign the key
2. Adaptive capacity automatically redistributes throughput to the hot partition, using unused capacity from other partitions
3. Burst capacity is only table-level, not partition-level
4. Auto Scaling increases total capacity until the hot partition is satisfied

Related Posts

• RDS Automated Backups vs Manual Snapshots – Key Differences
• S3 Storage Classes Explained – Standard, IA, Glacier & When to Use
• Three-Tier Web & Caching (DAX)
• RDS & Aurora Performance
• Event-Driven Serverless Architecture
• Multi-Region Active-Active

References

• DynamoDB Developer Guide
• Global Tables — AWS Docs
• DynamoDB Auto Scaling — AWS Blog

Frequently Asked Questions

On-Demand vs Provisioned — which is cheaper?

On-Demand is cheaper when traffic is unpredictable or very spiky (utilization <18% of would-be provisioned capacity). Provisioned is cheaper for steady-state traffic with predictable patterns. Rule of thumb: if your table consistently uses >18% of peak capacity, provisioned + auto-scaling is cheaper. New tables or uncertain patterns → start On-Demand, analyze, switch later.

When should I use Global Tables vs cross-region read replicas?

Global Tables: When you need writes in multiple regions (active-active). Both regions accept writes, replication is automatic. No native cross-region read replicas in DynamoDB — Global Tables is the only option for multi-region. For read-only multi-region, Global Tables still works (just write to one region, read from any). For relational databases with read-only needs, Aurora Global is the alternative.

CloudFormation Advanced — Overview

CloudFormation is the #1 DOP-C02 topic (113 questions) and appears on SOA-C03 and SAP-C02. The exam goes deep on StackSets (multi-account), drift detection, custom resources, change sets, nested stacks, and CloudFormation Guard for policy-as-code validation.

StackSets — Multi-Account Deployment

Exam pattern: “Deploy security baseline to all accounts” → StackSets with Organization auto-deployment to target OU.

Nested Stacks vs Cross-Stack References

• Nested: Updated together as one unit. Parent manages lifecycle. Can’t update child independently.
• Cross-Stack: Independent lifecycles. Can update one without touching the other. But: can’t delete exporting stack while imported.

Change Sets

• What: Preview changes before executing an update (like terraform plan)
• Shows: Resources to be added, modified, or deleted. Whether replacement is needed.
• Replacement types: None (in-place), Conditional (may replace), Always (will delete and recreate)
• Exam note: “Preview impact before deploying” → Create Change Set, review, then execute

Drift Detection

• What: Detects if actual resource configuration differs from template (someone changed manually)
• Shows: Expected vs actual values for each drifted property
• Fix options: Update template to match actual (accept drift) OR import resource to bring under CFN management
• Limitation: Not all resources support drift detection. Some properties are not checked.
• Exam pattern: “Someone manually changed a resource, now updates fail” → detect drift, resolve

Custom Resources (Lambda-backed)

• When: CFN doesn’t support a resource natively, or you need custom logic during provisioning
• How: Define AWS::CloudFormation::CustomResource → triggers Lambda function on Create/Update/Delete
• Lambda responds: Sends SUCCESS/FAILED + response data to CFN-provided signed URL
• Use cases: Populate DynamoDB table on deploy, get latest AMI ID, configure third-party service, run DB migration
• Exam trap: Lambda must respond to the signed URL. If it doesn’t (timeout/error without response), stack hangs for 1 hour.

CloudFormation Guard

• What: Policy-as-code tool that validates templates against rules BEFORE deployment
• Language: Domain-specific language (DSL) for writing rules
• Example rule: “All S3 buckets must have encryption enabled” or “No Security Group allows 0.0.0.0/0 on port 22”
• CI/CD integration: Run in CodeBuild/CodePipeline as a gate — fail deployment if rules violated
• vs Config: Guard prevents deployment (shift-left). Config detects after deployment (reactive).

Other Validation Tools

Deployment Strategies with CFN

• Stack policies: Prevent accidental updates/deletions of critical resources (e.g., deny Update on production RDS)
• Termination protection: Prevent accidental stack deletion (must explicitly disable first)
• DeletionPolicy: Retain (keep resource after stack delete), Snapshot (create snapshot), Delete (default)
• UpdateReplacePolicy: What happens when a resource needs replacement — Retain old, Snapshot old, or Delete old

Exam Tips

AWS Certification Exam Practice Questions

Question 1:

A company needs to deploy a security baseline (CloudTrail, Config, GuardDuty) to all 200 accounts in their Organization. When new accounts are created, the baseline must deploy automatically. Which approach achieves this?

1. Create individual stacks in each account using a script
2. CloudFormation StackSets with service-managed permissions, targeting the Organization root OU, with auto-deployment enabled
3. Deploy via AWS Config conformance packs to each account
4. Use Control Tower account factory blueprints

Question 2:

A CloudFormation stack update fails with “Resource X has been modified outside of CloudFormation.” The team needs to understand what changed and resolve the issue. Which steps should they take?

1. Delete the stack and recreate it from the template
2. Run drift detection to identify the differences, then either update the template to match actual state or manually revert the resource to match the template
3. Force the update with –continue-update-rollback
4. Import the resource into a new stack

Question 3:

A team needs to populate a DynamoDB table with seed data every time their CloudFormation stack is deployed. CloudFormation doesn’t natively support writing items to DynamoDB. How can this be achieved within the same stack?

1. Use a CloudFormation Init script on an EC2 instance
2. Create a Custom Resource backed by a Lambda function that writes items to DynamoDB on the Create event
3. Add a UserData script to an EC2 instance in the stack
4. Use CloudFormation macros to transform the template

Related Posts

• AWS Global vs Regional vs AZ Services – Complete Reference
• RDS Automated Backups vs Manual Snapshots – Key Differences
• EC2 Dedicated Host vs Dedicated Instance – Which to Choose
• S3 Storage Classes Explained – Standard, IA, Glacier & When to Use
• CI/CD Pipeline Architecture
• Multi-Account Architecture
• Systems Manager Operations
• IAM Security Architecture

References

• CloudFormation StackSets — AWS Docs
• CloudFormation Guard — AWS Docs
• Change Sets — AWS Docs

Frequently Asked Questions

StackSets vs Control Tower — when to use which?

StackSets: Deploy any CloudFormation template to multiple accounts/regions. Full template flexibility. Use for custom baselines, application infrastructure, or anything CFN can define. Control Tower: Deploys a prescriptive AWS landing zone with guardrails (SCPs + Config rules). Use for initial account governance setup. Many teams use both: Control Tower for governance + StackSets for custom deployments.

What is the difference between cfn-lint, cfn-nag, and Guard?

cfn-lint: Syntax/schema validation (is the template valid?). cfn-nag: Security static analysis (are there security issues?). Guard: Custom policy validation (does it meet OUR organizational rules?). Use all three in CI/CD: cfn-lint first (catch syntax), then cfn-nag (catch security), then Guard (enforce org policies). All run before deployment — shift-left validation.

RDS & Aurora Performance Architecture — Overview

Database performance is the #1 DBS-C01 topic (218 questions) and appears heavily on SAA-C03 and SAP-C02. The exam tests Read Replicas, Provisioned IOPS, Performance Insights, RDS Proxy, Aurora Serverless, and Aurora Global Database patterns.

Aurora vs RDS — Performance Differences

Read Replica Patterns

• Reader endpoint (Aurora): Load-balances across all replicas automatically. Application uses reader endpoint for reads.
• Custom endpoints: Route specific queries to specific replicas (e.g., analytics queries to larger replicas)
• Cross-region replicas: For global reads and DR. Aurora Global: <1s replication. RDS: async (minutes possible)
• Replica priority tiers: Control which replica promotes on failover (tier 0 = highest priority)
• Read/write splitting: Application sends writes to writer endpoint, reads to reader endpoint. Frameworks: ProxySQL, Spring read-replica routing.

RDS Proxy — Connection Pooling

• Problem: Lambda/serverless creates hundreds of connections. Each connection consumes DB memory. Connection storms on scale-out.
• Solution: RDS Proxy maintains persistent connection pool to DB. Lambda connects to Proxy (fast), Proxy multiplexes to DB (few connections).
• Failover: RDS Proxy detects failover and redirects connections to new primary without application reconnection (~66% faster failover).
• IAM Auth: Proxy supports IAM authentication (no password in code). Manages secrets from Secrets Manager.
• Pinning: Some session state pins connections (prepared statements, temp tables). Minimize pinning for best multiplexing.

Storage Performance

Aurora Serverless v2

• Auto-scales: ACUs (Aurora Capacity Units) scale up/down in seconds based on load
• Range: Min 0.5 ACU to max 256 ACU. Set min/max bounds.
• Mixed clusters: Combine provisioned writer + Serverless v2 readers (scale reads on demand)
• Use case: Variable workloads, dev/test, infrequent access databases that need instant scaling
• vs Provisioned: Serverless costs more per ACU-hour but saves when utilization is low/variable

Aurora Global Database

• Replication: Storage-level replication, <1 second lag (not logical replication)
• Regions: 1 primary + up to 5 secondary regions (16 read replicas per region)
• Failover: Managed cross-region failover (RTO <1 minute). Secondary promotes to primary.
• Use case: Global low-latency reads + DR across regions
• Write forwarding: Secondary region can forward writes to primary (application doesn’t need to know which is primary)

Performance Insights & Monitoring

• Performance Insights: Visual dashboard showing DB load by wait events, SQL statements, hosts, users. Identifies bottleneck queries.
• Enhanced Monitoring: OS-level metrics (CPU per process, memory, swap, I/O) at 1-second granularity. More detail than CloudWatch.
• Slow query log: Log queries exceeding a time threshold. Analyze for optimization.
• CloudWatch: Standard metrics (CPU, connections, IOPS, replica lag). Set alarms.

Exam Tips

AWS Certification Exam Practice Questions

Question 1:

An Aurora MySQL database serves a global application. Users in Europe experience 200ms read latency because the database is in us-east-1. The company needs European reads under 20ms without application changes. Which solution achieves this?

1. Create a cross-region read replica in eu-west-1
2. Configure Aurora Global Database with a secondary region in eu-west-1. European application uses the reader endpoint in eu-west-1.
3. Use ElastiCache in eu-west-1 to cache query results
4. Deploy CloudFront to cache database responses

Question 2:

A serverless application (Lambda + API Gateway) connects to an RDS PostgreSQL database. During traffic spikes, the database reaches max_connections (200) and Lambda functions fail. The database CPU is only at 30%. What is the root cause and fix?

1. Database too small — upgrade instance size for more connections
2. Connection exhaustion from Lambda — add RDS Proxy for connection pooling and multiplexing
3. Increase max_connections parameter in the parameter group
4. Add read replicas to distribute connection load

Question 3:

A DBA needs to identify which SQL queries are causing high DB load during peak hours. They need to see which queries consume the most CPU and I/O, and which wait events are occurring. Which tool provides this visibility?

1. CloudWatch CPU Utilization metric with anomaly detection
2. RDS Performance Insights — shows DB load breakdown by wait events, top SQL statements, and contributing sessions
3. Enhanced Monitoring for OS-level process details
4. AWS X-Ray tracing through the application

Related Posts

• RDS Automated Backups vs Manual Snapshots – Key Differences
• AWS EBS Volume Types – gp3, io2, st1 & sc1 Compared
• EC2 Dedicated Host vs Dedicated Instance – Which to Choose
• Three-Tier Web & Caching Architecture
• Database Migration Architecture
• Serverless API Architecture
• Disaster Recovery Architecture

References

• Amazon Aurora Overview — AWS Docs
• RDS Proxy — AWS Docs
• Performance Insights — AWS Docs

Frequently Asked Questions

When should I use Aurora vs standard RDS?

Aurora: When you need higher performance (5x MySQL), more read replicas (15 vs 5), faster failover (30s vs 120s), auto-growing storage, or global database. Standard RDS: When you need specific engine versions not yet on Aurora, lowest cost for small workloads, or Oracle/SQL Server (Aurora only supports MySQL/PostgreSQL). Aurora costs ~20% more but offers significantly better performance and availability.

RDS Proxy vs connection pooling in application (PgBouncer)?

RDS Proxy: Managed, integrates with IAM/Secrets Manager, faster failover (redirects connections seamlessly), no infrastructure to manage. Self-managed (PgBouncer): Full control, cheaper (EC2 cost only), more configuration options. Use RDS Proxy for Lambda (must-have), or when you want managed failover. Use PgBouncer when you need specific pooling configurations or cost sensitivity.

AWS EMR & Spark Architecture — Overview

EMR is the largest topic on DAS-C01 (274 questions) and appears on DEA-C01 and MLA-C01 for data processing. The exam tests cluster modes (transient vs persistent), Spark optimization, EMRFS (S3 integration), instance selection, and EMR Serverless vs managed clusters.

EMR on EC2 — Cluster Architecture

Transient vs Persistent Clusters

Exam rule: “Minimize cost for batch ETL” → transient cluster + S3 (EMRFS). “Interactive analysis” → persistent cluster.

EMRFS — S3 as Primary Storage

• What: EMR’s implementation of HDFS file system interface on top of S3
• Why: Decouple storage from compute. Cluster terminates, data persists in S3. Enables transient clusters.
• Consistent view: EMRFS provides read-after-write consistency (S3 now natively consistent)
• S3 Committer: EMRFS S3-optimized committer avoids the rename problem (faster job completion)
• vs HDFS: Use HDFS only for intermediate shuffle data or when sub-second latency needed. S3 for input/output data.

Spark Optimization

• Partitioning: Match parallelism to data size. Too few partitions = underutilized cluster. Too many = scheduling overhead.
• Memory: spark.executor.memory + spark.executor.memoryOverhead. OOM = increase memory or reduce partition size.
• Shuffle: Expensive operation (data crosses network). Reduce with: broadcast joins, coalesce, partition-wise operations.
• Dynamic Allocation: Automatically scales executors based on workload. Enable for variable job sizes.
• Instance Fleet: Mix instance types in a fleet (Spot diversification). EMR picks cheapest available. Reduces Spot interruptions.

EMR Serverless vs Glue vs EMR on EC2

Exam Tips

AWS Certification Exam Practice Questions

Question 1:

A company runs nightly Spark ETL jobs that process 2TB of data. The cluster is provisioned 24/7 but only runs jobs for 3 hours each night. How can they reduce costs by 80%+?

1. Use Reserved Instances for the cluster
2. Switch to transient cluster pattern — launch cluster before job, use EMRFS (S3) for data, terminate after job completes
3. Reduce cluster size and run jobs longer
4. Switch to EMR on EKS

Question 2:

A Spark job on EMR occasionally fails because Spot instances in the Task node fleet are reclaimed. The job must complete reliably while still using Spot for cost savings. How should this be configured?

1. Use On-Demand instances only (no Spot)
2. Use Instance Fleets with multiple instance types for Task nodes (Spot diversification), keep Core nodes On-Demand, enable Spark checkpointing
3. Increase the number of Task nodes to compensate for lost instances
4. Use EMR Serverless instead

Question 3:

An analytics team needs to run interactive Presto queries on data in S3 alongside scheduled Spark ETL jobs. They want a single cluster for both workloads. Which EMR configuration supports this?

1. Two separate transient clusters — one for Presto, one for Spark
2. Persistent cluster with YARN capacity scheduler — allocate queues for Presto (interactive) and Spark (batch) with resource limits
3. EMR Serverless for both workloads
4. Glue for Spark + Athena for queries (no EMR needed)

Related Posts

• EC2 Dedicated Host vs Dedicated Instance – Which to Choose
• S3 Storage Classes Explained – Standard, IA, Glacier & When to Use
• Glue ETL & Data Pipeline
• Data Lake & Analytics Architecture
• Kinesis vs MSK Streaming
• Cost Optimization Architecture

References

• Amazon EMR Management Guide
• Spark Best Practices on EMR — AWS Blog
• EMR Serverless Guide

Frequently Asked Questions

EMR vs Glue — when to use which?

Glue: Simpler, fully serverless, Data Catalog native, visual designer, job bookmarks. Best for ETL pipelines. EMR: Full Hadoop ecosystem (Spark, Hive, Presto, HBase, Flink), custom configurations, better for complex multi-framework workloads, interactive analysis. Use Glue for standard ETL. Use EMR when you need frameworks beyond Spark or custom cluster configuration.

When should I use EMRFS vs HDFS?

EMRFS (S3): Primary storage for input/output data. Survives cluster termination. Enables transient clusters. Use for most data. HDFS: Only for intermediate data needing lowest latency (shuffle data, temporary computation). HDFS is lost when cluster terminates. Modern best practice: EMRFS for everything, HDFS only as automatic intermediate storage.

ALB vs NLB vs GWLB — Load Balancer Decision Guide

Load balancer selection appears in 67 ANS-C01 questions plus heavily on SAA-C03 and SAP-C02. The exam tests when to use ALB vs NLB, GWLB for transparent inspection, target group types, cross-zone behavior, and advanced features like connection draining, slow start, and sticky sessions.

Detailed Comparison

Target Group Types

Advanced Features

• Connection draining (deregistration delay): When target deregisters, existing connections complete (default 300s). Set lower for faster deployments.
• Slow start: New targets gradually receive traffic (avoids overwhelming cold instance). Ramps up over configurable duration.
• Sticky sessions: ALB uses cookie (application or duration-based). NLB uses source IP hash. Breaks even distribution — avoid if possible.
• Cross-zone LB: ALB: enabled by default (distributes evenly across all targets in all AZs). NLB: disabled by default (each AZ node only routes to targets in its AZ).
• mTLS: ALB supports mutual TLS (verify client certificates). Requires trust store configuration.

When to Chain NLB → ALB

• Problem: Need static IPs (NLB) + path-based routing (ALB)
• Solution: NLB (static IPs, PrivateLink compatible) → ALB target group → application targets
• Also for: Exposing ALB-backed services via PrivateLink (PrivateLink requires NLB/GWLB)
• Alternative: ALB + Global Accelerator (provides static IPs without NLB)

Exam Tips

AWS Certification Exam Practice Questions

Question 1:

A financial services API requires: static IP addresses for client allowlisting, Layer 7 path-based routing for different API versions (/v1/* vs /v2/*), and TLS termination. No single AWS load balancer provides all three. What architecture satisfies all requirements?

1. ALB with Global Accelerator (provides static IPs + Layer 7 routing)
2. NLB (static IPs) with ALB as target (provides Layer 7 routing + TLS termination)
3. NLB with TLS listener and path-based routing
4. GWLB with ALB targets

Question 2:

A gaming company’s servers handle millions of concurrent TCP connections on a custom protocol (not HTTP). They need the load balancer to preserve the client’s source IP address so game servers can identify players. Which load balancer type preserves source IP natively for TCP?

1. ALB with X-Forwarded-For header
2. NLB — preserves source IP natively for TCP targets (no proxy protocol or header needed)
3. GWLB with GENEVE encapsulation
4. Classic Load Balancer with proxy protocol

Question 3:

After deploying new instances into an ALB target group, the new instances are immediately overwhelmed with traffic and fail health checks. Existing instances are fine. How can the new instances be gradually introduced?

1. Increase the health check interval to give instances more time
2. Enable slow start mode on the target group — new targets receive gradually increasing traffic over a configurable duration
3. Deploy one instance at a time with manual monitoring
4. Reduce the connection timeout on the ALB

Question 4:

A company has 4 instances: 3 in AZ-A, 1 in AZ-B. With NLB’s default cross-zone disabled, the single instance in AZ-B is overwhelmed (receiving 50% of traffic) while AZ-A instances are underutilized. How should this be resolved?

1. Add more instances to AZ-B to handle 50% of traffic
2. Enable cross-zone load balancing on the NLB — traffic distributes evenly across all 4 targets regardless of AZ
3. Remove AZ-B from the NLB to stop routing there
4. Switch to ALB which has cross-zone enabled by default

Question 5:

A company wants to expose an internal ALB-backed microservice to partner accounts via PrivateLink. However, PrivateLink VPC Endpoint Services only support NLB or GWLB as the load balancer. How can they expose the ALB service via PrivateLink?

1. PrivateLink now supports ALB directly
2. Create an NLB with the ALB as a target (ALB-type target group), then create a VPC Endpoint Service pointing to the NLB
3. Replace ALB with NLB for the microservice
4. Use VPC Peering instead of PrivateLink

Related Posts

• AWS Global vs Regional vs AZ Services – Complete Reference
• AWS EBS Volume Types – gp3, io2, st1 & sc1 Compared
• Three-Tier Web Architecture
• Network Firewall & GWLB
• Global Traffic Management
• Auto Scaling & Performance

References

• Application Load Balancer Guide
• Network Load Balancer Guide
• Gateway Load Balancer Guide
• NLB with ALB Target — AWS Blog

Frequently Asked Questions

ALB vs NLB — how do I choose?

ALB: When you need HTTP-aware features — path/host routing, header inspection, Lambda targets, WebSocket, Cognito auth, redirects. NLB: When you need TCP/UDP (non-HTTP), static IPs, ultra-low latency, source IP preservation, PrivateLink, or millions of connections. Rule of thumb: HTTP/HTTPS application → ALB. Everything else → NLB.

Why is NLB cross-zone disabled by default?

Two reasons: (1) Cost — cross-zone NLB incurs data transfer charges between AZs. ALB cross-zone is free. (2) Latency — without cross-zone, traffic stays in the same AZ (lower latency). For most applications, enable cross-zone for even distribution. Disable when cost-sensitive or when you want AZ-local routing (each AZ is independent).

Route 53 Resolver & Hybrid DNS — Overview

Hybrid DNS is a key ANS-C01 topic (85 questions) that tests Resolver endpoints (inbound/outbound), conditional forwarding, DNSSEC, split-horizon DNS, and private hosted zone associations. Understanding DNS resolution flow between on-premises and AWS is critical.

Resolver Endpoints

• Inbound endpoint: Creates ENIs in your VPC with IP addresses. On-prem DNS forwards to these IPs. Requires DX/VPN connectivity.
• Outbound endpoint: Creates ENIs that forward DNS queries to on-prem DNS servers. Uses forwarding rules to determine which domains go where.
• Multi-AZ: Always deploy endpoints in 2+ AZs for availability (min 2 ENIs per endpoint).

Forwarding Rules

• Conditional forwarding: “If query matches *.corp.internal → forward to 10.0.1.53 (on-prem DNS)”
• System rules: Auto-created for VPC CIDR reverse DNS and private hosted zones
• Recursive: Default behavior — Route 53 Resolver recursively resolves public domains
• Rule sharing: Share forwarding rules via RAM to other accounts (centralized DNS management)
• Rule priority: Most specific domain match wins (corp.internal beats .internal beats .)

Private Hosted Zones

• What: DNS zone accessible only from associated VPCs (not public internet)
• Cross-account: Associate private hosted zone with VPCs in other accounts (via CLI/API authorization)
• Split-horizon: Same domain name (example.com) resolves differently: public hosted zone → internet users, private hosted zone → VPC users. Private takes precedence inside VPC.
• Overlap: If multiple private hosted zones match, most specific wins (a.b.example.com > b.example.com)

DNSSEC

• What: Cryptographic signing of DNS records to prevent spoofing/tampering
• Route 53 supports: DNSSEC signing for public hosted zones (KMS-backed signing key)
• Validation: Route 53 Resolver validates DNSSEC signatures on responses (enable per VPC)
• Chain of trust: Root → TLD → domain. All must have DNSSEC for full validation.
• Exam note: “Prevent DNS spoofing” → DNSSEC signing + validation. “DNS poisoning protection” → DNSSEC.

Route 53 Resolver DNS Firewall

• What: Filter DNS queries from your VPC (block queries to malicious domains)
• Rules: ALLOW, BLOCK, or ALERT on domain lists (managed or custom)
• Managed lists: AWS provides threat intelligence domain lists (malware, botnet C2)
• Use case: Prevent DNS-based data exfiltration, block known malicious domains, compliance
• Priority: DNS Firewall → Forwarding Rules → Resolver. Firewall evaluates first.

Exam Tips

AWS Certification Exam Practice Questions

Question 1:

A company has on-premises Active Directory DNS resolving corp.internal. EC2 instances in AWS need to resolve hostnames in corp.internal (e.g., ldap.corp.internal). The VPCs are connected to on-premises via Direct Connect. Which configuration enables this?

1. Create a Route 53 private hosted zone named corp.internal with manual records
2. Create a Route 53 Resolver outbound endpoint + forwarding rule for corp.internal pointing to on-premises DNS server IPs
3. Configure EC2 instances to use on-premises DNS servers directly (change DHCP options)
4. Create an inbound resolver endpoint for on-premises to query

Question 2:

On-premises servers need to resolve private hostnames in AWS (e.g., mydb.internal.aws which points to an RDS instance in a private hosted zone). Which configuration allows on-premises DNS to resolve these AWS-hosted names?

1. Make the private hosted zone public
2. Create a Route 53 Resolver inbound endpoint in the VPC. Configure on-premises DNS to forward *.internal.aws queries to the inbound endpoint IPs.
3. Create a public hosted zone with the same records
4. Add the records to on-premises DNS manually

Question 3:

A company wants the domain api.example.com to resolve to a public ALB IP for internet users, but to a private ALB IP for users inside the VPC (avoiding internet round-trip). How should this be configured?

1. Create two A records in the public hosted zone with geolocation routing
2. Create a public hosted zone with public ALB record + a private hosted zone (same name) with private ALB record associated with the VPC
3. Use CloudFront to route differently based on source
4. Configure the ALB to return different IPs based on source IP

Related Posts

• AWS Global vs Regional vs AZ Services – Complete Reference
• Route 53 Routing Policies – Simple, Weighted, Latency, Failover & Geolocation
• Route 53 Alias vs CNAME – Differences & When to Use Each
• Global Traffic Management (Route 53 Routing Policies)
• Direct Connect Deep Dive
• Hybrid Cloud Networking
• VPC Advanced Networking

References

• Route 53 Resolver — AWS Docs
• Multi-Account DNS with Resolver — AWS Blog
• DNS Firewall — AWS Docs

Frequently Asked Questions

Inbound vs Outbound endpoint — which do I need?

Inbound: When on-premises needs to resolve AWS domains (on-prem → AWS). On-prem DNS forwards to inbound endpoint IPs. Outbound: When AWS instances need to resolve on-premises domains (AWS → on-prem). Forwarding rules send matching queries to on-prem DNS. Most hybrid environments need BOTH: inbound for on-prem→AWS resolution, outbound for AWS→on-prem resolution.

What is split-horizon DNS?

Same domain name resolves to different IPs depending on where the query originates. Public hosted zone serves internet users (public IPs). Private hosted zone serves VPC users (private IPs). VPC Resolver checks private zones first — if a match exists, it returns the private answer without querying the public zone. Common for internal vs external access to the same service.

AWS Network Performance Architecture — Overview

Network performance is the #1 topic on ANS-C01/C02 (160+ questions) and appears on SAP-C02 for HPC and high-throughput scenarios. The exam tests Enhanced Networking (ENA/EFA), placement groups, jumbo frames, bandwidth allocation, and network optimization patterns.

Enhanced Networking — ENA vs EFA

Placement Groups

Jumbo Frames (MTU 9001)

• What: Larger Ethernet frames (9001 bytes vs standard 1500 bytes). Less overhead per byte transferred → higher throughput.
• Supported: Within VPC, across VPC peering (same region), over Direct Connect, between instances in same placement group
• NOT supported: Over the internet, over VPN, over TGW (TGW reduces to 8500 MTU), across inter-region peering
• Path MTU Discovery: ICMP “Fragmentation Needed” messages. If blocked by NACL/SG, causes packet drops (exam trap!)
• Configuration: Set on OS level (Linux: ip link set dev eth0 mtu 9001). Both sender AND receiver must support.

Instance Bandwidth

• Determined by instance type: t3.micro = 5 Gbps burst, c5.18xlarge = 25 Gbps, c5n.18xlarge = 100 Gbps
• Single-flow limit: Single TCP connection maxes at ~5-10 Gbps (use multi-flow/parallel connections for full bandwidth)
• Baseline vs burst: Smaller instances have baseline + burst (like EBS bandwidth). Larger instances have consistent bandwidth.
• “n” instances: c5n, m5n, r5n = network-optimized variants with higher bandwidth (100 Gbps)
• Cross-AZ: ~$0.01/GB data transfer charge. Same performance as intra-AZ but costs money.

Network Optimization Patterns

Exam Tips

AWS Certification Exam Practice Questions

Question 1:

A company runs an HPC simulation that requires ultra-low latency communication between 100 compute instances using MPI. The instances need to communicate at the highest possible bandwidth with OS-bypass for inter-node traffic. Which configuration provides this?

1. ENA-enabled instances in a spread placement group with jumbo frames
2. EFA-enabled instances in a cluster placement group with jumbo frames (MTU 9001)
3. ENA-enabled instances with enhanced networking across 3 AZs
4. Standard networking with NLB distributing traffic between instances

Question 2:

Instances in a VPC communicate with jumbo frames (MTU 9001). After adding a Transit Gateway to route traffic between VPCs, large packet transfers start failing with fragmentation. What is the cause and fix?

1. TGW doesn’t support jumbo frames — reduce MTU to 1500 on all instances
2. TGW supports 8500 byte MTU (not 9001). Enable Path MTU Discovery and ensure NACLs allow ICMP type 3 code 4
3. Enable jumbo frame support on the TGW attachment
4. Increase the TGW bandwidth allocation

Question 3:

A company’s c5.xlarge instances are achieving only 5 Gbps throughput when transferring large files between instances, despite the instance type supporting 10 Gbps. The transfer uses a single TCP connection. How can they achieve full 10 Gbps?

1. Enable enhanced networking (ENA) on the instances
2. Use multiple parallel TCP connections (multi-flow) to aggregate bandwidth beyond the single-flow limit
3. Move instances to a cluster placement group
4. Increase instance type to c5.2xlarge

Question 4:

A distributed Kafka cluster on EC2 needs rack-awareness for partition replicas (replicas should be on different physical racks for fault tolerance). The cluster has 30 brokers across 3 AZs. Which placement strategy provides rack isolation information to Kafka?

1. Cluster placement group (all on same rack)
2. Spread placement group (max 7 per AZ — insufficient for 10 per AZ)
3. Partition placement group — Kafka maps partitions to placement partitions for rack-awareness
4. No placement group — use AZ as rack identifier

Question 5:

A company’s application transfers data between instances in the same VPC and also to instances in a peered VPC in another region. They want to use jumbo frames (MTU 9001) for maximum throughput. Where will jumbo frames work?

1. Both intra-VPC and inter-region peering support MTU 9001
2. Only intra-VPC supports MTU 9001. Inter-region peering is limited to MTU 1500.
3. Neither supports jumbo frames without special configuration
4. Both work but require enabling jumbo frames on the peering connection

Related Posts

• AWS EBS Volume Types – gp3, io2, st1 & sc1 Compared
• Hybrid Cloud Networking
• VPC Connectivity Decision Guide
• Auto Scaling & Performance
• Container Platform Architecture

References

• Enhanced Networking on EC2 — AWS Docs
• Elastic Fabric Adapter (EFA) — AWS Docs
• Placement Groups — AWS Docs
• Network MTU — AWS Docs

Frequently Asked Questions

ENA vs EFA — when do I need EFA?

ENA is sufficient for 99% of workloads (web, databases, containers, general compute). It provides up to 200 Gbps with low latency. EFA adds OS-bypass (kernel bypass) specifically for tightly-coupled parallel computing: MPI-based HPC simulations, distributed ML training (NCCL). If your workload doesn’t use MPI or NCCL, you don’t need EFA. EFA instances also have ENA for standard traffic.

Why does jumbo frame performance matter?

Standard frames carry 1500 bytes per packet with ~40 bytes header overhead (2.6%). Jumbo frames carry 9001 bytes with the same ~40 bytes overhead (0.4%). For large data transfers, jumbo frames: reduce CPU interrupt rate (fewer packets per GB), reduce header overhead (more payload per packet), and increase throughput. Most impactful for bulk data transfer, database replication, and storage traffic.

AWS Glue ETL & Data Pipeline Architecture — Overview

AWS Glue is the core ETL service tested on DEA-C01 (34 questions) and MLA-C01 (36 questions). The exam tests Glue jobs (Spark/Python), Glue Data Catalog (metadata), crawlers (schema discovery), data quality, and orchestration patterns for data engineering pipelines.

Glue Components

Job Bookmarks — Incremental Processing

• Problem: Daily ETL job should only process NEW data (not re-process everything)
• Solution: Job bookmarks track what was already processed (S3 paths, JDBC timestamps)
• How: Enable bookmark on job. Glue remembers last processed file/row. Next run starts from where it left off.
• Exam note: “Process only new files in S3” → Enable Glue job bookmarks

Glue Connections & VPC

• JDBC sources: Glue jobs connect to RDS/Redshift via JDBC connections (require VPC, subnet, SG configuration)
• ENI: Glue creates ENIs in your VPC subnet to access private data sources
• NAT Gateway: If Glue job needs internet access (e.g., API call) from private subnet, requires NAT Gateway
• S3 endpoint: Always add VPC Gateway Endpoint for S3 (Glue reads/writes S3 heavily — avoid NAT charges)

Orchestration Patterns

Performance Optimization

• Partitioning: Partition output by date/region/category. Athena/Redshift Spectrum prunes partitions for faster queries.
• File format: Convert CSV/JSON → Parquet/ORC (columnar, compressed, 10-100x faster queries)
• File size: Avoid small files (coalesce to 128MB-1GB per file). Small files kill query performance.
• Auto-scaling: Glue 4.0 auto-scales DPUs based on workload (no over-provisioning)
• Pushdown predicates: Filter data at source (pushdown to JDBC, S3 Select) — less data to process

Exam Tips

AWS Certification Exam Practice Questions

Question 1:

A company receives daily CSV files in S3. They need to transform them to Parquet format, partition by date, and make them queryable by Athena. The pipeline should only process new files each day. Which solution achieves this?

1. Lambda triggered by S3 event → convert each file individually
2. Glue ETL job with bookmarks enabled, scheduled daily. Reads new CSVs, transforms to Parquet, writes partitioned output. Crawler updates Catalog.
3. Athena CTAS query to convert CSV to Parquet
4. EMR Spark cluster running 24/7 processing files as they arrive

Question 2:

A data team needs a central metadata repository that Athena, Redshift Spectrum, and EMR can all query against. They want schema discovered automatically from S3 data. Which combination provides this?

1. Custom Hive metastore on EC2 with manual schema creation
2. Glue Data Catalog populated by Glue Crawlers — automatically discovered schemas accessible by Athena, Redshift Spectrum, and EMR
3. S3 bucket tags as metadata with Lambda reading them
4. DynamoDB table storing schema information

Question 3:

A Glue ETL job needs to read from an RDS PostgreSQL database in a private subnet. The job also writes output to S3. The job fails with connection timeout errors to both RDS and S3. What is the most likely configuration issue?

1. Glue job doesn’t have IAM permissions to access RDS
2. Glue connection not configured with VPC, subnet, and security group. Also missing S3 VPC Gateway Endpoint.
3. RDS instance is encrypted and Glue can’t decrypt
4. Glue job DPU count is too low for the data volume

Question 4:

A data pipeline produces Parquet files in S3 that are later queried by Athena. Queries are slow because the pipeline creates thousands of small files (1-5 MB each). How should the pipeline be optimized?

1. Switch from Parquet to CSV for faster reading
2. Configure the Glue job to coalesce output files to 128MB-1GB using repartition/coalesce, and partition output by date for pruning
3. Increase Athena query timeout to allow more time
4. Add more Glue DPUs to write faster

Question 5:

A data team needs to validate that incoming data meets quality rules (no null values in required fields, dates in correct format, values within expected ranges) before loading into the data warehouse. If rules fail, the pipeline should stop and alert the team. Which Glue feature provides this?

1. Glue Crawler with classification rules
2. Glue Data Quality with DQDL rules configured to halt the job on failure and send SNS notification
3. Custom Lambda function that samples and validates data before Glue runs
4. Athena query that checks constraints after loading

Related Posts

• Data Lake & Analytics Architecture
• Kinesis vs MSK Streaming
• RAG Advanced Patterns (Vector DB)
• Event-Driven Serverless Architecture
• EMR & Spark Architecture

References

• AWS Glue Developer Guide
• Glue Data Quality — AWS Docs
• Serverless Data Pipeline with Glue — AWS Blog

Frequently Asked Questions

Glue ETL vs EMR — when to use which?

Glue: Serverless, auto-scaling, pay per DPU-hour. Best for scheduled ETL jobs, data catalog integration, and teams wanting managed Spark without cluster management. EMR: Full Hadoop/Spark ecosystem, persistent or transient clusters, custom configurations (Hive, Presto, HBase). Best for complex big data workloads needing fine-tuned Spark configs, long-running clusters, or non-Spark frameworks.

What is the Glue Data Catalog used for?

Central metadata repository storing table definitions (schema, location, format, partitions). Shared across AWS analytics services: Athena queries tables from the Catalog, Redshift Spectrum references external tables, EMR uses it as Hive metastore, Lake Formation controls access to Catalog tables. It’s the “phone book” for your data lake — services look up where data lives and what format it’s in.