Commonly Confused Services on SAA-C03

Deciding signal

ALB operates at Layer 7 and routes based on HTTP rules: path, host header, query string, or source IP. It is the right answer when the scenario involves routing web traffic to different target groups by URL pattern or when content-based decisions are required. NLB operates at Layer 4 and handles high-volume TCP and UDP traffic with ultra-low latency and static IP support — right when the protocol is not HTTP or when extreme throughput is the constraint. GWLB is not a general-purpose load balancer: it routes traffic transparently through third-party virtual appliances such as firewalls and intrusion detection systems. When a scenario describes inserting security appliances inline before traffic reaches the application, GWLB is the answer.

Deciding signal

EBS is a block device that attaches to a single EC2 instance (or multiple with Multi-Attach on io1/io2). It behaves like a local disk. EFS is a managed NFS file system that multiple EC2 instances or containers can mount simultaneously — the right answer when the scenario involves shared storage across multiple compute resources. S3 is object storage accessed over HTTP, suited for large unstructured files, backups, and static assets — not mountable as a file system in standard architectures. The key question is who needs access: one instance (EBS), multiple instances concurrently (EFS), or applications via API (S3).

Deciding signal

SQS holds messages until a consumer retrieves them. It suits worker-style patterns where processing durability matters and one consumer handles each message. SNS pushes a message simultaneously to all its subscribers — Lambda, SQS queues, HTTP endpoints, email — making it the right answer for fanout to multiple systems. EventBridge routes events based on rules that match event content: source, detail-type, or specific fields. It is the right answer when the scenario involves multiple downstream consumers with different filtering criteria, or when events from AWS services or SaaS need routing without custom code. The deciding factor is routing intelligence: SQS has none, SNS fans out equally to all subscribers, EventBridge filters by content.

Deciding signal

Kinesis Data Streams is a real-time data stream where your application code reads records, controls retention (1–365 days), and can replay data. It requires you to build or manage consumers. Kinesis Data Firehose is a fully managed delivery service: it receives data and delivers it automatically to S3, Redshift, OpenSearch, or Splunk with optional transformation — no consumer code required. When the scenario involves custom processing logic, real-time analytics, or the need to replay data, Data Streams. When the scenario describes loading streaming data into a destination with minimal operational overhead, Firehose.

Deciding signal

RDS supports six engines: MySQL, PostgreSQL, Oracle, SQL Server, MariaDB, and Aurora. When the scenario specifies Oracle or SQL Server licensing requirements, RDS is required. Aurora is AWS-proprietary storage that is up to 5× faster than standard MySQL and 3× faster than standard PostgreSQL, with storage that automatically grows up to 128 TB. Aurora also offers Aurora Serverless for variable or unpredictable workloads with automatic capacity scaling. The exam typically signals Aurora when the scenario involves high availability, read scalability across up to 15 read replicas, or workloads described as "high-performance MySQL/PostgreSQL-compatible." If a specific non-Aurora engine is named or licensing is mentioned, use RDS.

Deciding signal

Redis supports persistence, Multi-AZ replication, pub/sub messaging, sorted sets, geospatial indexes, and Lua scripting. It is the right answer for session storage requiring failover, leaderboards, real-time analytics, or any use case that requires data to survive a node restart. Memcached is simpler: multi-threaded, horizontally scalable with no persistence, no replication, and no complex data structures. When the question mentions session state, pub/sub, or sorted data, Redis. When the question describes simple key-value caching with a large number of nodes and no persistence requirement, Memcached.

Deciding signal

Gateway Endpoints are free, use route table entries, and work only for Amazon S3 and Amazon DynamoDB. No ENI is created; traffic is routed at the network layer. Interface Endpoints use AWS PrivateLink, create Elastic Network Interfaces in your VPC with private IPs, and support most other AWS services (SQS, SNS, Secrets Manager, SSM, and many more). Interface Endpoints have an hourly cost. When the scenario asks for private access to S3 or DynamoDB from within a VPC, Gateway Endpoint. For any other AWS service, Interface Endpoint. If the scenario mentions "private DNS" or "ENI with private IP," that signals an Interface Endpoint.

Deciding signal

CloudFront caches content at edge locations. Its latency benefit depends on cache hits and applies to cacheable assets: images, static files, API responses that can be cached. Dynamic content unique per request cannot be cached, so CloudFront provides no latency benefit for it beyond the first request. Global Accelerator routes all traffic over the AWS backbone network using anycast IP addresses, regardless of cacheability. It reduces latency for dynamic, stateful, non-cacheable workloads — gaming, VoIP, IoT, or APIs where every request is unique. The deciding question is cacheability.

Deciding signal

Multi-AZ creates a synchronous standby replica in a different Availability Zone for automatic failover. It is strictly for availability — the standby cannot serve read traffic in standard RDS. Read Replicas are asynchronous copies that can serve SELECT queries, reducing read load on the primary. They are a read-scaling mechanism, not a failover mechanism — promoting a read replica to primary is a manual operation. When the scenario describes "reduce read load" or "offload reporting queries," Read Replicas. When the scenario describes "automatic failover" or "survive an AZ failure," Multi-AZ.

Deciding signal

IAM roles attach to identities — EC2 instances, Lambda functions, users — and define what those identities can do. To access a resource in another account using a role, the calling principal must assume the role first. Resource-based policies (S3 bucket policies, SQS queue policies, Lambda resource policies) attach to the resource itself and define who can access it. They can grant cross-account access directly without requiring the caller to assume a role, which removes one step. On SAA-C03, resource-based policies are specifically the answer when the scenario describes granting another account access to a resource with "minimal operational overhead" or "without role assumption."