Data and analytics is the quiet weight on the AWS Certified Solutions Architect – Professional (SAP-C02) exam. There’s no domain named “Analytics” in the blueprint — but analytics services show up throughout Design Solutions for Organizational Complexity (26%), Design for New Solutions (29%), and Accelerate Workload Migration and Modernization (20%). A question about ingesting clickstream data at scale, or letting one business unit query another’s data lake without copying it, is an analytics question wearing an architecture costume.
The difficulty isn’t that these services are complex individually. It’s that AWS offers many overlapping ways to move, store, and query data, and SAP-C02 questions are built precisely on the overlaps. Kinesis Data Streams and Amazon Data Firehose both ingest streams. Athena and Redshift Spectrum both query S3 with SQL. Glue and EMR both run Spark. All of those pairs are “correct” in a loose sense — the exam wants the one that fits this set of constraints.
This guide walks the analytics stack the way a practitioner reasons about it — layer by layer, with the decision cues that separate the right answer from the plausible one.
The Layered Mental Model
Nearly every AWS analytics architecture decomposes into five layers. Placing a question’s requirement into the right layer usually eliminates half the answer options before you’ve read them properly.
| Layer | Question it answers | Core services |
|---|---|---|
| Ingest | How does data arrive? | Kinesis Data Streams, Amazon Data Firehose, MSK, DMS, DataSync, Snow Family |
| Store | Where does it land? | S3 (data lake), Redshift (warehouse), DynamoDB, OpenSearch |
| Process | How is it transformed? | Glue, EMR, Lambda, Managed Service for Apache Flink |
| Consume | How is it queried? | Athena, Redshift, QuickSight, OpenSearch Dashboards |
| Govern | Who can see what? | Lake Formation, IAM, KMS, Glue Data Catalog |
Two structural facts carry a lot of exam weight. First, S3 is the center of gravity — the modern AWS data lake is S3 plus the Glue Data Catalog, with everything else reading from or writing to it. When a question describes a “single source of truth” across teams, S3 with a shared catalog is almost always the backbone. Second, the Glue Data Catalog is the shared metadata layer. Athena, Redshift Spectrum, EMR, and Glue ETL all read the same catalog. That’s what allows a table defined once to be queried by several engines — a recurring theme in questions about breaking down data silos.
Ingest: Kinesis Data Streams vs. Firehose vs. MSK
The ingest layer produces more wrong answers than any other, because three services genuinely overlap.
Kinesis Data Streams is a durable, replayable stream. You provision shards (or use on-demand mode, which scales automatically); each shard gives you 1 MB/s or 1,000 records/s in, and 2 MB/s out. Records persist for 24 hours by default, configurable up to 365 days, and multiple consumers can read the same data independently. Enhanced fan-out gives each consumer its own dedicated 2 MB/s per shard rather than sharing the standard throughput.
Amazon Data Firehose (formerly Kinesis Data Firehose) is a fully managed delivery service. No shards, no scaling decisions, no consumer code. It buffers by size or time and delivers to S3, Redshift, OpenSearch, and third-party endpoints, with optional inline transformation via Lambda and conversion to Parquet or ORC. The trade-off: it is near-real-time, not real-time (buffering introduces seconds to minutes of latency), and it is not replayable — data lands at the destination and the pipeline retains nothing.
Amazon MSK is managed Apache Kafka. You reach for it when you need the Kafka API specifically — an existing Kafka application, Kafka ecosystem tooling, longer retention, or higher throughput than Kinesis fits comfortably. MSK Serverless removes capacity planning.
The decision cues:
| Cue in the question | Answer |
|---|---|
| ”Simplest way to load streaming data into S3/Redshift/OpenSearch” | Firehose |
| ”No management overhead”, “serverless delivery” | Firehose |
| ”Sub-second latency”, “real-time processing” | Kinesis Data Streams |
| ”Multiple applications consume the same stream independently” | Kinesis Data Streams (enhanced fan-out) |
| “Replay data from an earlier point” | Kinesis Data Streams or MSK |
| ”Existing Kafka application”, “migrate Kafka to AWS” | MSK |
| ”Ordering guarantees per key” | Kinesis (partition key) or MSK (partition) |
The most common trap is reaching for Kinesis Data Streams when Firehose is sufficient. If a question describes landing streaming data in S3 with no consumer logic and emphasizes minimal operational overhead, Firehose is the answer — and picking Data Streams means you’ve also signed up for shard management and consumer code the question explicitly said it didn’t want.
For batch ingestion, the cues are cleaner: DMS for database migration and CDC replication, DataSync for ongoing file transfers over network links, and the Snow Family when the data volume over the available bandwidth would take longer than physically shipping it. The migration strategies guide covers those trade-offs in depth.
Store: S3 as the Data Lake
S3 is the default landing zone, and the exam expects fluency in the properties that make it one: eleven nines of durability, effectively unlimited scale, storage classes and lifecycle policies for cost, and decoupling of storage from compute — which is precisely why several engines can query the same data.
Two S3 design decisions come up repeatedly.
Partitioning. Lay data out with Hive-style partition keys in the prefix:
s3://my-data-lake/events/year=2026/month=07/day=16/hour=14/events.parquetA query filtering on year=2026 AND month=07 reads only that prefix. Everything else is skipped — never opened, never scanned, never billed.
File format. Convert raw JSON or CSV to Parquet or ORC. Columnar formats let engines read only the columns a query needs, and they compress far better than row formats.
These two choices together are the single biggest lever on analytics cost, and the exam knows it. Athena bills $5 per TB scanned, so a query against unpartitioned JSON that reads 1 TB costs $5; the same query against partitioned Parquet might scan 10 GB and cost five cents. Any Athena cost-optimization question is answered with partitioning plus columnar format — that’s close to a reflex worth building.
Storage class cues follow the access pattern: S3 Standard for hot data, Intelligent-Tiering when access patterns are unknown or shifting (the exam’s favorite for “unpredictable access”), Glacier Instant Retrieval for archives needing millisecond access, and Glacier Deep Archive for long-term compliance retention.
Process: Glue vs. EMR vs. Lambda
AWS Glue is serverless ETL. It runs Spark without any cluster to manage, and it includes the Glue Data Catalog (the shared metastore), crawlers that infer schema from data in S3, Glue Studio for visual jobs, and DataBrew for no-code preparation. Billing is per DPU-hour while jobs run.
Amazon EMR is managed Hadoop, Spark, Hive, Presto, HBase, and Flink. You get full control over the cluster, versions, and tuning — and full responsibility for it. EMR Serverless removes capacity management; EMR on EKS runs Spark on an existing EKS cluster.
Lambda handles lightweight, event-driven transformation: a file lands in S3, a function reshapes it. Bounded by the 15-minute timeout and memory limits.
| Cue | Answer |
|---|---|
| ”Serverless ETL”, “no infrastructure to manage” | Glue |
| ”Catalog metadata for a data lake”, “infer schema automatically” | Glue crawlers + Data Catalog |
| ”Existing Hadoop/Spark workload”, “migrate on-premises Hadoop” | EMR |
| ”Fine-grained control over Spark tuning / specific versions” | EMR |
| ”Lowest cost for large batch processing” | EMR with Spot on task nodes |
| ”Transform small files as they arrive” | Lambda |
| ”Real-time stream processing with windowing / SQL over streams” | Managed Service for Apache Flink |
An EMR cost nuance the exam likes: use On-Demand or Reserved for primary and core nodes (they hold HDFS data — losing one to Spot reclamation costs you data) and Spot for task nodes (pure compute, safely interruptible). A question describing cost reduction on a large, restartable batch job is pointing at Spot task nodes.
For orchestration: Step Functions for general workflows, Glue workflows for Glue-native pipelines, and MWAA (Managed Workflows for Apache Airflow) when the organization already has Airflow DAGs — that last one is a migration-flavored cue.
Consume: Athena vs. Redshift vs. Redshift Spectrum
This is the highest-yield distinction in the analytics stack, and the one worth getting exactly right.
Amazon Athena is serverless, interactive SQL directly on S3, built on Trino. No infrastructure, no loading step, pay per TB scanned. It’s ideal for ad-hoc exploration and infrequent queries. Its federated query feature reaches into other sources (RDS, DynamoDB, on-premises) via connectors. Because you pay per query, cost tracks usage — which is superb for sporadic access and expensive for constant querying.
Amazon Redshift is a petabyte-scale columnar data warehouse. Data is loaded and stored in an optimized internal format, giving much better performance for complex joins and repeated queries. RA3 nodes separate compute from managed storage (scale each independently); Concurrency Scaling adds transient capacity during spikes; Redshift Serverless removes cluster management; Data Sharing exposes live data to other clusters or accounts without copying it.
Redshift Spectrum lets a Redshift cluster query data in S3 without loading it, joining external S3 tables to internal warehouse tables in a single query.
| Cue | Answer |
|---|---|
| ”Ad-hoc / infrequent queries on S3” | Athena |
| ”No infrastructure, pay per query” | Athena |
| ”Complex joins, repeated BI dashboards, many concurrent users” | Redshift |
| ”Query S3 data and warehouse data in one query” | Redshift Spectrum |
| ”Share live data across accounts without copying” | Redshift Data Sharing |
| ”Unpredictable query spikes on the warehouse” | Concurrency Scaling |
| ”Query across RDS/DynamoDB/on-prem from one SQL engine” | Athena Federated Query |
| ”Log analytics, full-text search, near-real-time dashboards” | OpenSearch Service |
The economic dividing line is the useful heuristic: Athena’s per-query pricing wins for sporadic access; Redshift’s provisioned model wins for sustained, heavy querying. A team running a handful of exploratory queries a day should use Athena. A BI team with fifty analysts hitting dashboards all day should use Redshift — Athena would be both slower and, at that volume, more expensive.
QuickSight is the BI layer, with SPICE as its in-memory cache. When a question mentions dashboards for business users, QuickSight is likely in the answer; when it adds “without repeatedly hitting the warehouse,” SPICE is the mechanism.
Govern: Lake Formation and Cross-Account Access
Governance is where SAP-C02 gets genuinely professional-level, because it intersects with the multi-account organizational complexity that dominates Domain 1.
AWS Lake Formation sits on top of the Glue Data Catalog and provides fine-grained access control that plain IAM cannot express:
- Column-level — analysts see
customer_idandregion, but notssn. - Row-level — the EU team sees only rows where
region = 'EU'. - Cell-level — both dimensions combined.
- LF-Tags — tag-based access control that scales across thousands of tables without per-table policies.
- Cross-account sharing — grant another account access to a table without copying data or writing bucket policies.
That last capability is the one to internalize. The classic SAP-C02 scenario: a central data lake in one account, consumer teams in others, requirements for least privilege and no data duplication. Lake Formation cross-account sharing with LF-Tags is the intended answer, and the distractors are usually replicating data per account (violates “no duplication”) or hand-maintaining S3 bucket policies (doesn’t scale, and can’t do column-level anyway).
The decision cue is granularity. If a question needs column-, row-, or cell-level control over data lake tables, it’s Lake Formation. IAM and S3 bucket policies operate at the object and prefix level — they cannot hide a column, and no amount of policy authoring changes that. When you see “analysts must not see PII columns but need the rest of the table,” IAM alone is definitionally the wrong answer.
Encryption follows the usual pattern: SSE-KMS for S3 with customer-managed keys where audit trails and key rotation matter, and cross-account KMS key policies when consumers in other accounts need to decrypt shared data. A forgotten KMS key policy is a common cause of “access denied despite correct Lake Formation grants” — worth remembering, because the exam occasionally tests exactly that layered failure.
For the multi-account foundations underneath all of this, see the multi-account architecture guide; for the security context, the security and compliance scenarios guide is a good pairing.
Putting It Together: Three Reference Architectures
1. Real-time clickstream analytics
Web/mobile apps
└─> Kinesis Data Streams (durable, replayable, sub-second)
├─> Managed Service for Apache Flink → real-time aggregates → DynamoDB → API
└─> Amazon Data Firehose → Parquet conversion → S3 (partitioned)
└─> Glue Catalog → Athena / QuickSightWhy Data Streams first: two consumers read the same stream independently, and Firehose alone can’t fan out or replay. Firehose then handles the S3 delivery leg, where its buffering is a feature rather than a limitation.
2. Enterprise data lake with governed access
Sources (RDS via DMS, files via DataSync, streams via Firehose)
└─> S3 raw zone
└─> Glue ETL (clean, dedupe, convert to Parquet, partition)
└─> S3 curated zone
├─> Glue Data Catalog ──> Lake Formation (LF-Tags, column/row grants)
├─> Athena (ad-hoc analysts)
├─> Redshift Spectrum (join to warehouse)
└─> QuickSight (business dashboards)The raw/curated zone split is worth stating explicitly in any design answer: raw is immutable and replayable, curated is optimized and governed. Lake Formation grants sit at the catalog layer, so every engine inherits the same permissions — one grant model rather than four.
3. Hadoop modernization
On-premises Hadoop (HDFS + Spark + Hive)
└─> DataSync / Snowball → S3
├─> Hive metastore → Glue Data Catalog
└─> Spark jobs → EMR (lift-and-shift) → EMR Serverless (modernize)The architectural point the exam wants: moving from HDFS to S3 decouples storage from compute, so clusters become transient — spin up for a job, terminate after, stop paying for idle capacity. That decoupling is the modernization, and it’s what a Domain 4 question is fishing for.
Exam Strategy for Analytics Questions
A repeatable read on these questions:
- Identify the layer. Ingest, store, process, consume, or govern? Most options die here.
- Find the hard constraint. Latency, cost, operational overhead, and access granularity are the four that decide analytics answers. The question always emphasizes one.
- Apply the serverless bias. When a question stresses “minimal operational overhead” — and SAP-C02 stresses it constantly — prefer Firehose over Data Streams, Glue over EMR, Athena over Redshift, Serverless variants over provisioned. The exam consistently rewards managed services unless a requirement rules them out.
- Check for “without copying data.” That phrase is a strong tell for Lake Formation cross-account sharing, Redshift Data Sharing, Redshift Spectrum, or Athena federated query — the copy-avoiding family.
- Watch for the over-engineered distractor. Professional-level options are often technically workable but excessive. If Firehose to S3 satisfies every stated requirement, a Kinesis-plus-Lambda-plus-Step-Functions pipeline is wrong, however impressive it looks.
Under time pressure — 75 questions in 180 minutes, roughly 2.4 minutes each — that sequence matters more than depth on any one service. Long scenario questions reward reading the last paragraph first, where the actual requirement usually hides.
Practice with Realistic Scenario Questions
Analytics questions on SAP-C02 are rarely “what does Athena do?” They’re four-paragraph scenarios where two options are defensible and one is most appropriate given a constraint mentioned once, in passing. Building that discrimination takes exposure to the question style, not just service knowledge.
Sailor.sh’s AWS Certified Solutions Architect – Professional (SAP-C02) Mock Exam Bundle provides eight full-length mock exams — 600+ questions at real exam length and timing, with detailed explanations covering why each distractor fails. Working through the reasoning on a wrong answer is where the decision cues in this guide become instinct.
To go deeper on adjacent areas, the database selection guide covers the operational data stores that feed these pipelines, the serverless architecture patterns guide expands on event-driven processing, and the cost optimization guide covers the storage and compute economics referenced throughout. If you’re still planning your preparation, start with the SAP-C02 study plan. The official AWS SAP-C02 exam guide remains the authoritative source for domain weightings.
Frequently Asked Questions
How much of SAP-C02 is data and analytics?
There’s no dedicated domain, but analytics services appear across Domains 1, 2, and 4 — realistically 10–15% of questions involve them meaningfully. Enough that weak analytics knowledge costs a pass; not enough to justify studying it like a data engineering certification.
Athena or Redshift — how do I choose under exam pressure?
Query frequency decides it. Sporadic, ad-hoc queries on S3 → Athena (pay per query, nothing to manage). Sustained, complex, concurrent BI workloads → Redshift (provisioned, optimized storage). Need both S3 and warehouse data in one query → Redshift Spectrum.
When is MSK the answer over Kinesis?
When the question mentions Kafka explicitly — an existing Kafka application, Kafka APIs, or the Kafka ecosystem. Absent a Kafka signal, Kinesis is the more AWS-native answer and usually the intended one.
Do I need to know Glue job internals or Spark tuning?
No. SAP-C02 tests service selection, not implementation. Know that Glue is serverless Spark with a catalog and crawlers, and know when it beats EMR. Leave DynamicFrame APIs and Spark tuning to the data engineering certification.
What’s the difference between the Glue Data Catalog and Lake Formation?
The Glue Data Catalog stores metadata — table definitions, schemas, partitions. Lake Formation sits on top and adds fine-grained permissions (column, row, cell, LF-Tags, cross-account grants). Catalog answers what the data looks like; Lake Formation answers who may see which parts of it.
How do I cut Athena costs?
Partition the data, convert to Parquet or ORC, and compress. Athena bills $5 per TB scanned, and those three changes routinely cut scanned bytes by one to two orders of magnitude. This is close to a guaranteed exam answer whenever Athena cost is the topic.
Can I query across accounts without copying data?
Yes, several ways: Lake Formation cross-account sharing for lake tables, Redshift Data Sharing for warehouse data, Redshift Spectrum and Athena for S3 in place. The phrase “without duplicating data” in a question is a strong signal toward this family.
Conclusion
Data and analytics on SAP-C02 rewards clear thinking over memorization. The service list is long, but the decisions collapse into a handful of axes: real-time or near-real-time, serverless or managed cluster, pay-per-query or provisioned, coarse or fine-grained access.
Four cues carry most of the weight. Firehose when the requirement is delivery with no consumer logic; Data Streams when you need replay or fan-out. Glue when there’s no reason to manage a cluster; EMR when there is one. Athena for sporadic queries; Redshift for sustained ones. Lake Formation whenever access control needs to be finer than an S3 prefix.
Anchor those to the layered model — ingest, store, process, consume, govern — and the four-paragraph scenarios stop being intimidating. Read the requirement, place it in a layer, find the constraint the question actually emphasizes, and the option list usually narrows to two. At that point you’re choosing between a right answer and an over-engineered one, and the exam’s bias toward managed services will tell you which is which.