AWS Certified Data Engineer — Associate (DEA-C01)
A documentation-first study guide. AWS writes the exam from its own documentation, so reading the docs is the highest-leverage thing you can do. This guide is a curated index into the canonical references, FAQs, and a selection of whitepapers — organised around the four exam domains, not around services.
Maps to the published AWS Certified Data Engineer — Associate (DEA-C01) exam guide. Domain weights and task statements are quoted from that PDF.
About the exam
Current exam code: DEA-C01 (released March 2024, exam guide version 1.0). No C02 announcement as of July 2026.
Format: 65 questions (50 scored + 15 unscored) · 130 minutes · $150 USD · scaled score 100–1000, pass at 720.
The four domains:
- Domain 1 — Data Ingestion and Transformation — 34%
- Domain 2 — Data Store Management — 26%
- Domain 3 — Data Operations and Support — 22%
- Domain 4 — Data Security and Governance — 18%
Primary official sources (bookmark these):
- Official DEA-C01 certification page
- DEA-C01 Exam Guide (PDF)
- Official sample questions (PDF)
- AWS Skill Builder exam prep resources — search for the free "Exam Prep Plan: AWS Certified Data Engineer – Associate"
Whitepapers worth reviewing:
- AWS Well-Architected Framework — foundational thinking for all AWS exams.
- Data Analytics Lens — the Well-Architected lens closest to this exam's job role.
- Storage Best Practices for Data and Analytics Applications — data lake layout, partitioning, and format guidance on S3.
- Streaming Data Solutions on AWS — Kinesis, MSK, and Flink patterns for Domain 1.
Priority tiers: The published domain weights (34/26/22/18) tell you how the exam is balanced across the four domains, but they don't tell you that within each domain a handful of services account for most of the questions. Every section in this guide carries a tier badge based on triangulating the AWS exam guide, the experience reports of recent test takers, and the patterns that appear in the practice-exam community:
- ★★★ Core Heavily tested. Multiple questions will lean on this. Spend hours, not minutes — if you don't know it well, you fail.
- ★★ Important Reliably tested, usually one or two questions. Read every linked page in the section, do the FAQ, understand the comparison points. A few hours per topic.
- ★ Light Known to appear, but typically as one distinguishing question or as wrong-answer distractors. Skim the docs, learn the one-line distinction, move on. Twenty minutes to an hour.
For an 8–12 week prep cycle the rough split that the data supports is about 60% of your time on Core topics, 30% on Important, and 10% on Light. The biggest single concentration of questions across the whole exam is the cluster around AWS Glue + Amazon Athena + Amazon Redshift + Amazon S3 + Kinesis + Lake Formation + Step Functions — know those cold and you have the foundation of a pass. This exam is also unusually fond of "cheapest option" and "least operational overhead" phrasing: when two answers both work, the serverless or more managed one usually wins.
How to use this guide:
- Each section opens with a one-paragraph summary explaining what to focus on, then has up to three link sections: Core docs (user/developer guides — the canonical reference), FAQ (exam writers love edge cases from FAQs — do not skip), and Deeper reading (whitepapers, blog posts, re:Post articles).
- If a link 404s, AWS has reorganised the docs. Search the page title to find the new location — the content almost always still exists.
- The What's New feed is worth a weekly scan in the last month before your exam; the exam lags new features by ~12 months but recent launches are a good prompt to revisit older chapters.
Part I — Domain 1: Data Ingestion and Transformation (34%)
The largest domain by weight — expect around 17 of the 50 scored questions here. It covers getting data into AWS (streaming and batch), transforming it at scale with Glue, EMR, and Lambda, orchestrating pipelines, and the programming concepts that hold pipelines together.
Chapter 1 — Streaming ingestion
Maps to Task Statement 1.1 — Perform data ingestion
Knowledge of:
- Throughput and latency characteristics for AWS services that ingest data
- Data ingestion patterns (for example, frequency and data history)
- Streaming data ingestion
- Batch data ingestion (for example, scheduled ingestion, event-driven ingestion)
- Replayability of data ingestion pipelines
- Stateful and stateless data transactions
Skills in:
- Reading data from streaming sources (for example, Amazon Kinesis, Amazon Managed Streaming for Apache Kafka [Amazon MSK], Amazon DynamoDB Streams, AWS Database Migration Service [AWS DMS], AWS Glue, Amazon Redshift)
- Reading data from batch sources (for example, Amazon S3, AWS Glue, Amazon EMR, AWS DMS, Amazon Redshift, AWS Lambda, Amazon AppFlow)
- Implementing appropriate configuration options for batch ingestion
- Consuming data APIs
- Setting up schedulers by using Amazon EventBridge, Apache Airflow, or time-based schedules for jobs and crawlers
- Setting up event triggers (for example, Amazon S3 Event Notifications, EventBridge)
- Calling a Lambda function from Amazon Kinesis
- Creating allowlists for IP addresses to allow connections to data sources
- Implementing throttling and overcoming rate limits (for example, DynamoDB, Amazon RDS, Kinesis)
- Managing fan-in and fan-out for streaming data distribution
1.1 Amazon Kinesis Data Streams ★★★ Core
The default answer for real-time streaming ingestion with custom consumers and replay. Know shard capacity (1 MB/s or 1,000 records/s in, 2 MB/s out per shard), provisioned vs on-demand mode, retention (24 hours default, up to 365 days), enhanced fan-out for multiple consumers, KPL/KCL, and the causes of ProvisionedThroughputExceeded (hot partition keys, too few shards). Expect 4-6 questions involving Kinesis, often as "which ingestion service" comparisons against Firehose and MSK.
Core docs
- What is Amazon Kinesis Data Streams? — real-time streaming at scale
- Kinesis Data Streams terminology and concepts — streams, shards, records, partition keys
- Developing producers using the Kinesis Producer Library — batching and aggregation for throughput
- Developing consumers using the Kinesis Client Library — checkpointing, lease tables, shard rebalancing
- Enhanced fan-out consumers — dedicated 2 MB/s per consumer per shard
- Using Lambda with Kinesis — event source mapping, batch size, parallelization factor
- Handling duplicate records — at-least-once delivery, idempotent consumers
FAQ
Deeper reading
- Streaming Data Solutions on AWS — end-to-end streaming architectures
1.2 Amazon Kinesis Data Firehose ★★★ Core
Renamed Amazon Data Firehose in 2024 — the exam may use either name. It is the zero-administration delivery service: near-real-time (buffered, not real-time), fully managed scaling, delivery to S3, Redshift, OpenSearch, Splunk, and HTTP endpoints. Know buffering hints (size and interval), inline Lambda transformation, record format conversion to Parquet/ORC, and dynamic partitioning for S3 prefixes. Firehose vs Data Streams is one of the most common discriminator questions on the exam: Firehose when you just need data delivered, Data Streams when you need custom consumers, sub-second latency, or replay. Expect 3-5 questions.
Core docs
- What is Amazon Data Firehose? — managed delivery streams overview
- Understand data delivery — buffering hints, delivery frequency per destination
- Transform source data with AWS Lambda — inline record transformation and failure handling
- Convert input record format — JSON to Parquet/ORC using the Glue Data Catalog schema
- Dynamic partitioning — partition S3 output by keys in the data
FAQ
1.3 Amazon MSK ★★ Important
Managed Apache Kafka. The exam tests it as the answer when a question specifies Kafka compatibility, existing Kafka producers/consumers, or very high throughput with topic-based semantics. Know MSK provisioned vs MSK Serverless, MSK Connect for source/sink connectors, and IAM access control vs SASL/SCRAM vs mTLS authentication. Expect 1-2 questions, usually as a comparison with Kinesis.
Core docs
- What is Amazon MSK? — managed Kafka clusters
- MSK Serverless — capacity-free Kafka, pay per throughput
- MSK Connect — managed Kafka Connect for connectors
- IAM access control for MSK — authenticate and authorise clients with IAM
FAQ
1.4 Amazon Managed Service for Apache Flink ★ Light
Formerly Kinesis Data Analytics. The answer when a question needs stateful stream processing — windowed aggregations, streaming joins, anomaly detection on in-flight data — with results written back to another stream or sink. Know the one-line distinction: Firehose delivers, Flink computes. Usually one question.
Core docs
- What is Amazon Managed Service for Apache Flink? — managed Flink applications
- How it works — application lifecycle, checkpoints, parallelism
FAQ
Chapter 2 — Batch ingestion and data movement
Maps to Task Statement 1.1 — Perform data ingestion
Knowledge of:
- Throughput and latency characteristics for AWS services that ingest data
- Data ingestion patterns (for example, frequency and data history)
- Streaming data ingestion
- Batch data ingestion (for example, scheduled ingestion, event-driven ingestion)
- Replayability of data ingestion pipelines
- Stateful and stateless data transactions
Skills in:
- Reading data from streaming sources (for example, Amazon Kinesis, Amazon Managed Streaming for Apache Kafka [Amazon MSK], Amazon DynamoDB Streams, AWS Database Migration Service [AWS DMS], AWS Glue, Amazon Redshift)
- Reading data from batch sources (for example, Amazon S3, AWS Glue, Amazon EMR, AWS DMS, Amazon Redshift, AWS Lambda, Amazon AppFlow)
- Implementing appropriate configuration options for batch ingestion
- Consuming data APIs
- Setting up schedulers by using Amazon EventBridge, Apache Airflow, or time-based schedules for jobs and crawlers
- Setting up event triggers (for example, Amazon S3 Event Notifications, EventBridge)
- Calling a Lambda function from Amazon Kinesis
- Creating allowlists for IP addresses to allow connections to data sources
- Implementing throttling and overcoming rate limits (for example, DynamoDB, Amazon RDS, Kinesis)
- Managing fan-in and fan-out for streaming data distribution
2.1 AWS DMS ★★ Important
Database Migration Service is the exam's answer for replicating relational data into the analytics stack. Know the three task types (full load, full load plus CDC, CDC only), S3 as a target for landing data in a lake, and that ongoing replication (CDC) is how you keep a warehouse or lake in sync with an OLTP source. DMS Schema Conversion and the standalone AWS SCT handle heterogeneous engine conversions. Expect 2-3 questions.
Core docs
- What is AWS DMS? — managed database migration and replication
- Ongoing replication with change data capture (CDC) — continuous sync from source transaction logs
- Using Amazon S3 as a target — land CSV or Parquet files in a data lake
- DMS Schema Conversion — convert schemas between database engines
FAQ
2.2 Amazon AppFlow ★ Light
The no-code answer for ingesting SaaS data — Salesforce, SAP, Google Analytics, ServiceNow — into S3 or Redshift. Know that flows run on a schedule, in response to events, or on demand, and that field mapping, filtering, and validation happen in the flow itself. Usually one question where the giveaway word is a SaaS product name.
Core docs
- What is Amazon AppFlow? — managed SaaS integration flows
- Flow triggers — on demand, scheduled, and event-driven runs
2.3 AWS DataSync, Transfer Family, and the Snow Family ★ Light
Learn the one-line distinctions: DataSync for automated online transfer from NFS/SMB/HDFS/on-premises object storage into S3, EFS, or FSx; Transfer Family for managed SFTP/FTPS/FTP endpoints backed by S3 (partners push files to you); Snow Family for offline bulk transfer when bandwidth makes online transfer impractical. Each is typically a single discriminator question or a distractor.
Core docs
- What is AWS DataSync? — accelerated online data transfer
- What is AWS Transfer Family? — managed SFTP/FTPS/FTP into S3 or EFS
- What is AWS Snowball Edge? — offline petabyte-scale transfer devices
FAQ
Chapter 3 — Transforming and processing data
Maps to Task Statement 1.2 — Transform and process data
Knowledge of:
- Creation of ETL pipelines based on business requirements
- Volume, velocity, and variety of data (for example, structured data, unstructured data)
- Cloud computing and distributed computing
- How to use Apache Spark to process data
- Intermediate data staging locations
Skills in:
- Optimizing container usage for performance needs (for example, Amazon Elastic Kubernetes Service [Amazon EKS], Amazon Elastic Container Service [Amazon ECS])
- Connecting to different data sources (for example, Java Database Connectivity [JDBC], Open Database Connectivity [ODBC])
- Integrating data from multiple sources
- Optimizing costs while processing data
- Implementing data transformation services based on requirements (for example, Amazon EMR, AWS Glue, Lambda, Amazon Redshift)
- Transforming data between formats (for example, from .csv to Apache Parquet)
- Troubleshooting and debugging common transformation failures and performance issues
- Creating data APIs to make data available to other systems by using AWS services
3.1 AWS Glue ETL ★★★ Core
Glue is the single most tested service on the DEA-C01 — the serverless Spark ETL engine plus the Data Catalog (covered in Chapter 9). Know job types (Spark, Spark streaming, Python shell), worker types and DPUs, job bookmarks for incremental processing, Glue Studio visual authoring, connections for JDBC sources, Flex execution for cost savings, and common failure modes (out-of-memory means more or larger workers, or fixing skew). Counting the catalog, crawlers, and DataBrew, expect 8-12 questions that involve Glue somewhere.
Core docs
- What is AWS Glue? — serverless data integration overview
- AWS Glue concepts and components — catalog, crawlers, jobs, triggers, workflows
- Tracking processed data using job bookmarks — incremental ETL without reprocessing
- Streaming ETL jobs in AWS Glue — consume Kinesis and Kafka in Spark structured streaming
- What is AWS Glue Studio? — visual job authoring
- Data format options for ETL inputs and outputs — Parquet, ORC, Avro, JSON, CSV support
FAQ
Deeper reading
- Monitoring jobs with the Apache Spark web UI — diagnose stages, skew, and spills
3.2 AWS Glue DataBrew ★★ Important
Visual, no-code data preparation with 250+ built-in transformations. The exam's answer whenever a question says analysts (not engineers) need to clean or normalise data without writing code. Know recipes (reusable transformation steps), profile jobs (statistics and anomaly detection), and data quality rules. Expect 1-3 questions — DataBrew also reappears in Domain 3 for profiling and quality.
Core docs
- What is AWS Glue DataBrew? — visual data preparation
- Creating and using recipes — reusable, versioned transformation steps
- Creating and working with jobs — recipe jobs vs profile jobs
3.3 Amazon EMR ★★ Important
Managed big-data frameworks (Spark, Hive, Presto/Trino, HBase, Flink) when you need cluster-level control that Glue doesn't give you, or when migrating an existing Hadoop/Spark estate. Know cluster composition (primary, core, task nodes), transient vs long-running clusters, Spot Instances for task nodes only (core nodes hold HDFS), instance fleets vs instance groups, managed scaling, EMRFS for S3, and the serverless options (EMR Serverless, EMR on EKS). Glue vs EMR is a classic discriminator: Glue for serverless ETL simplicity, EMR for framework flexibility, custom configuration, or cost at very large scale. Expect 2-4 questions.
Core docs
- What is Amazon EMR? — managed Hadoop/Spark ecosystem
- Overview of Amazon EMR — cluster lifecycle, node types
- Instance fleets and instance groups — capacity strategies, Spot diversification
- Using EMR managed scaling — automatic cluster resizing
- EMR File System (EMRFS) — S3 as the persistent data layer
- What is Amazon EMR Serverless? — run Spark and Hive without managing clusters
FAQ
3.4 AWS Lambda in data pipelines ★★★ Core
Lambda is the glue code of every pipeline on this exam: event-driven transformation on S3 puts, Firehose record transformation, Kinesis/DynamoDB Streams/SQS consumers via event source mappings, and lightweight scheduled jobs. Know the hard limits that decide questions — 15-minute timeout, memory up to 10 GB (CPU scales with it), 512 MB to 10 GB ephemeral /tmp storage, EFS mounts for larger shared state — plus concurrency controls and batching behaviour. If a transformation is big or long-running, the answer is Glue or EMR, not Lambda. Expect 3-5 questions.
Core docs
- What is AWS Lambda? — service overview and core concepts
- Lambda concurrency — reserved vs unreserved, throttling behaviour
- Using Lambda with Kinesis — batch size, parallelization factor, error handling
- Using Lambda with SQS — batch processing, partial batch responses
- Using Lambda with DynamoDB Streams — event source mapping for change capture
- Configuring file system access — mount EFS for larger working storage
- Amazon S3 event notifications — trigger functions on object creation
FAQ
3.5 Data formats and compression ★★★ Core
Format questions appear all over the exam. Memorise the profile of each: Parquet and ORC are columnar, splittable, compressed — the default answer for analytics on S3 because Athena and Redshift Spectrum scan (and bill) fewer bytes; Avro is row-based with embedded schema, good for record-oriented streaming and schema evolution; CSV/JSON are human-readable but slow and expensive to scan. Know compression trade-offs: Snappy is fast with moderate ratio (default in Parquet), gzip compresses more but is not splittable as a standalone stream, bzip2 is splittable. "Convert to Parquet and partition" is the single most repeated correct answer on this exam.
Core docs
- Athena supported SerDes and data formats — how each format is read
- Parquet SerDe — columnar format details for Athena
- Athena compression support — codec support and splittability
- Firehose record format conversion — convert JSON to Parquet/ORC on delivery
- Redshift COPY data format parameters — loading CSV, JSON, Avro, Parquet, ORC
Chapter 4 — Orchestrating data pipelines
Maps to Task Statement 1.3 — Orchestrate data pipelines
Knowledge of:
- How to integrate various AWS services to create ETL pipelines
- Event-driven architecture
- How to configure AWS services for data pipelines based on schedules or dependencies
- Serverless workflows
Skills in:
- Using orchestration services to build workflows for data ETL pipelines (for example, Lambda, EventBridge, Amazon Managed Workflows for Apache Airflow [Amazon MWAA], AWS Step Functions, AWS Glue workflows)
- Building data pipelines for performance, availability, scalability, resiliency, and fault tolerance
- Implementing and maintaining serverless workflows
- Using notification services to send alerts (for example, Amazon Simple Notification Service [Amazon SNS], Amazon Simple Queue Service [Amazon SQS])
4.1 AWS Step Functions ★★★ Core
The serverless orchestration answer. Know Standard vs Express workflows (long-running with exactly-once semantics vs high-volume short-duration), state types (Task, Choice, Parallel, Map, Wait), error handling with Retry and Catch, direct SDK integrations with Glue, EMR, Athena, and Redshift Data API, and the Distributed Map state for massively parallel processing of S3 objects. Step Functions vs MWAA is a reliable question: Step Functions for serverless AWS-native workflows, MWAA when the team already lives in Airflow. Expect 2-4 questions.
Core docs
- What is AWS Step Functions? — visual workflow orchestration
- Standard vs Express workflows — duration, pricing, execution semantics
- State types — Task, Choice, Parallel, Map, Wait, Pass
- Error handling — Retry with backoff, Catch for fallback paths
- Service integrations — call Glue, EMR, Athena, Lambda directly
- Map state — iterate over items, inline and distributed modes
FAQ
4.2 Amazon MWAA ★★ Important
Managed Workflows for Apache Airflow. The answer when a question mentions existing Airflow DAGs, Python-defined workflows, or open-source orchestration portability. Know that DAGs, plugins, and requirements files live in an S3 bucket, environments come in small/medium/large classes with autoscaling workers, and that MWAA runs inside your VPC. Common troubleshooting question: a DAG doesn't appear — check the S3 path and requirements.txt dependency errors in CloudWatch. Expect 1-3 questions.
Core docs
- What is Amazon MWAA? — managed Airflow environments
- Networking on Amazon MWAA — VPC modes, private vs public webserver access
- Environment class — sizing and worker autoscaling
FAQ
4.3 Amazon EventBridge ★★ Important
The event router and scheduler of the pipeline world. Know rules with event patterns (react to S3 object created, Glue job state change, Redshift events), scheduled rules with cron and rate expressions, and EventBridge Scheduler for one-off and recurring invocations. EventBridge is how "event-driven ingestion" and "scheduled ingestion" get implemented in most correct answers. Expect 2-3 questions.
Core docs
- What is Amazon EventBridge? — serverless event bus
- Events and event patterns — JSON matching for routing
- Rules — match events, route to targets
- Scheduled rules — cron and rate expressions
- What is Amazon EventBridge Scheduler? — scalable task scheduling with flexible time windows
FAQ
4.4 AWS Glue workflows and triggers ★★ Important
Glue's built-in orchestration: workflows chain crawlers and jobs with shared run properties, and triggers start them on a schedule, on demand, or when preceding jobs complete (conditional triggers). The exam likes Glue workflows as the "least additional infrastructure" answer when everything in the pipeline is already Glue. Expect 1-2 questions.
Core docs
- Overview of workflows in AWS Glue — orchestrate crawlers and jobs together
- Starting jobs and crawlers using triggers — scheduled, conditional, and on-demand triggers
- Scheduling an AWS Glue crawler — keep the catalog in sync on a schedule
4.5 Amazon SNS and Amazon SQS in pipelines ★★ Important
In DEA-C01 these appear as pipeline plumbing: SNS for alerting on job failure (EventBridge rule to SNS topic to email) and fan-out, SQS for buffering and decoupling ingestion stages, dead-letter queues for failed events, and FIFO queues when ordering matters. Know visibility timeout and long polling at a definition level. Expect 1-2 questions.
Core docs
- What is Amazon SNS? — pub/sub messaging and alerting
- Fanout to SQS queues — one event to many consumers
- What is Amazon SQS? — managed message queuing
- Standard vs FIFO queues — at-least-once vs exactly-once, ordering
- Dead-letter queues — capture failed messages for inspection
FAQ
Chapter 5 — Programming concepts for data engineers
Maps to Task Statement 1.4 — Apply programming concepts
Knowledge of:
- Continuous integration and continuous delivery (CI/CD) (implementation, testing, and deployment of data pipelines)
- SQL queries (for data source queries and data transformations)
- Infrastructure as code (IaC) for repeatable deployments (for example, AWS Cloud Development Kit [AWS CDK], AWS CloudFormation)
- Distributed computing
- Data structures and algorithms (for example, graph data structures and tree data structures)
- SQL query optimization
Skills in:
- Optimizing code to reduce runtime for data ingestion and transformation
- Configuring Lambda functions to meet concurrency and performance needs
- Performing SQL queries to transform data (for example, Amazon Redshift stored procedures)
- Structuring SQL queries to meet data pipeline requirements
- Using Git commands to perform actions such as creating, updating, cloning, and branching repositories
- Using the AWS Serverless Application Model (AWS SAM) to package and deploy serverless data pipelines (for example, Lambda functions, Step Functions, DynamoDB tables)
- Using and mounting storage volumes from within Lambda functions
5.1 Infrastructure as code: CloudFormation, CDK, and SAM ★★ Important
Pipelines are deployed as code on this exam. Know the roles: CloudFormation is the declarative template engine underneath everything; CDK defines infrastructure in TypeScript/Python and synthesises to CloudFormation; SAM is the shorthand for serverless stacks (Lambda, Step Functions, DynamoDB) with sam build and sam deploy. Expect 1-2 questions, usually "how do we make this deployment repeatable across environments".
Core docs
- What is AWS CloudFormation? — declarative infrastructure templates
- Template anatomy — Resources, Parameters, Outputs, Mappings
- What is the AWS CDK? — infrastructure in real programming languages
- What is AWS SAM? — serverless-focused CloudFormation extension
- sam deploy — package and deploy serverless pipelines
FAQ
5.2 CI/CD and Git for data pipelines ★ Light
Know the developer-tools suite at a component level: CodeCommit (Git hosting — closed to new AWS customers since 2024 but still named in the exam guide), CodeBuild (run tests and package artifacts), CodeDeploy (deploy), CodePipeline (orchestrate all of it). Be comfortable with basic Git operations — clone, branch, commit, merge — at the vocabulary level. Usually one question about promoting pipeline code through environments.
Core docs
- What is AWS CodePipeline? — CI/CD orchestration
- What is AWS CodeBuild? — managed build and test service
- What is AWS CodeCommit? — managed Git repositories
- Practicing Continuous Integration and Continuous Delivery on AWS — CI/CD concepts whitepaper
5.3 SQL in data pipelines ★★ Important
The exam assumes working SQL: joins, aggregation with GROUP BY, window functions for rolling averages, CTEs, and pivoting. Know Redshift stored procedures for encapsulating transformation logic inside the warehouse, and the basics of query optimization — filter early, select only needed columns, use partition/sort keys so the engine can prune. You won't write SQL on the exam, but several questions describe a query and ask why it is slow or expensive. Expect 2-3 questions.
Core docs
- Creating stored procedures in Amazon Redshift — PL/pgSQL procedures for in-warehouse transforms
- Tuning query performance in Amazon Redshift — query plans, EXPLAIN, common issues
- Athena SQL reference — DDL and DML supported by Athena
Part II — Domain 2: Data Store Management (26%)
Around 13 of the 50 scored questions. Choosing the right store for the access pattern, cataloging what you have, managing the data lifecycle for cost, and designing schemas that survive change. Redshift and S3 dominate this domain.
Chapter 6 — The data warehouse: Amazon Redshift
Maps to Task Statement 2.1 — Choose a data store
Knowledge of:
- Storage platforms and their characteristics
- Storage services and configurations for specific performance demands
- Data storage formats (for example, .csv, .txt, Parquet)
- How to align data storage with data migration requirements
- How to determine the appropriate storage solution for specific access patterns
- How to manage locks to prevent access to data (for example, Amazon Redshift, Amazon RDS)
Skills in:
- Implementing the appropriate storage services for specific cost and performance requirements (for example, Amazon Redshift, Amazon EMR, AWS Lake Formation, Amazon RDS, DynamoDB, Amazon Kinesis Data Streams, Amazon MSK)
- Configuring the appropriate storage services for specific access patterns and requirements (for example, Amazon Redshift, Amazon EMR, Lake Formation, Amazon RDS, DynamoDB)
- Applying storage services to appropriate use cases (for example, Amazon S3)
- Integrating migration tools into data processing systems (for example, AWS Transfer Family)
- Implementing data migration or remote access methods (for example, Amazon Redshift federated queries, Amazon Redshift materialized views, Amazon Redshift Spectrum)
6.1 Amazon Redshift fundamentals ★★★ Core
Redshift is the second most tested service after Glue. Know the architecture (leader node compiles queries, compute nodes execute; RA3 nodes separate compute from managed storage), Redshift Serverless (pay per RPU-second — the "least management" answer), distribution styles (KEY for join columns, ALL for small dimension tables, EVEN as fallback, AUTO default), sort keys for range-restricted scans, COPY for parallel loads from S3 (many files, roughly equal size), UNLOAD to write back to S3, VACUUM and ANALYZE maintenance, and workload management with concurrency scaling. Expect 6-9 questions across the exam.
Core docs
- What is Amazon Redshift? — cluster management overview
- Data warehouse system architecture — leader node, compute nodes, slices
- Amazon Redshift Serverless — RPU-based, no cluster management
- Distribution styles — KEY, ALL, EVEN, AUTO
- Sort keys — compound vs interleaved, zone maps
- COPY — parallel bulk loading from S3
- UNLOAD — export query results to S3, including Parquet
- Vacuuming tables — reclaim space, re-sort rows
- Workload management — queues, priorities, auto WLM
- Concurrency scaling — burst capacity for read spikes
FAQ
6.2 Redshift Spectrum, federated queries, materialized views, and data sharing ★★★ Core
The "query data where it lives" features are heavily tested. Spectrum queries S3 data through external tables in the Glue Data Catalog without loading it; federated queries reach into RDS/Aurora PostgreSQL and MySQL live; materialized views precompute expensive joins and aggregations (with incremental refresh, and auto-refresh for streaming ingestion from Kinesis/MSK); data sharing gives other Redshift warehouses live read access without copying — the exam's answer for cross-team and cross-account warehouse access. Expect 3-4 questions.
Core docs
- Querying external data using Amazon Redshift Spectrum — external schemas and tables over S3
- Querying data with federated queries — live queries against RDS and Aurora
- Materialized views — precomputed results, incremental refresh
- Streaming ingestion into materialized views — consume Kinesis and MSK directly
- Data sharing in Amazon Redshift — live, no-copy sharing across warehouses and accounts
Chapter 7 — The data lake: S3 and Lake Formation
Maps to Task Statement 2.1 — Choose a data store
Knowledge of:
- Storage platforms and their characteristics
- Storage services and configurations for specific performance demands
- Data storage formats (for example, .csv, .txt, Parquet)
- How to align data storage with data migration requirements
- How to determine the appropriate storage solution for specific access patterns
- How to manage locks to prevent access to data (for example, Amazon Redshift, Amazon RDS)
Skills in:
- Implementing the appropriate storage services for specific cost and performance requirements (for example, Amazon Redshift, Amazon EMR, AWS Lake Formation, Amazon RDS, DynamoDB, Amazon Kinesis Data Streams, Amazon MSK)
- Configuring the appropriate storage services for specific access patterns and requirements (for example, Amazon Redshift, Amazon EMR, Lake Formation, Amazon RDS, DynamoDB)
- Applying storage services to appropriate use cases (for example, Amazon S3)
- Integrating migration tools into data processing systems (for example, AWS Transfer Family)
- Implementing data migration or remote access methods (for example, Amazon Redshift federated queries, Amazon Redshift materialized views, Amazon Redshift Spectrum)
7.1 Amazon S3 as the data lake ★★★ Core
S3 is the substrate of every architecture on this exam. Know storage classes cold (Standard, Intelligent-Tiering for unknown access patterns, Standard-IA and One Zone-IA, the three Glacier classes), request performance (3,500 writes and 5,500 reads per second per prefix — parallelise across prefixes), Hive-style partition layout (key=value folders that Athena and Glue understand), multipart upload for large objects, and event notifications to Lambda/SQS/EventBridge for event-driven pipelines. Expect 4-6 questions, mostly embedded in cost and performance scenarios.
Core docs
- What is Amazon S3? — object storage fundamentals
- Storage classes — Standard, Intelligent-Tiering, IA, Glacier tiers
- Best practices design patterns: optimizing performance — per-prefix request rates, parallelisation
- Multipart upload — required above 5 GB, recommended above 100 MB
- Amazon S3 event notifications — trigger pipelines on object changes
- Managing access with S3 Access Points — per-application access policies
FAQ
Deeper reading
- Storage Best Practices for Data and Analytics Applications — lake zones, partitioning, and format strategy
7.2 AWS Lake Formation ★★★ Core
Lake Formation layers governance over S3 and the Glue Data Catalog: register S3 locations, then grant database, table, column, row, and cell-level permissions that Athena, Redshift Spectrum, EMR, and Glue all enforce. Know LF-tags (tag-based access control that scales better than named-resource grants) and cross-account sharing. Whenever a question asks for fine-grained (column or row) access control on a data lake, or one place to manage permissions for many analytics services, Lake Formation is the answer. Expect 3-5 questions across Domains 2 and 4.
Core docs
- What is AWS Lake Formation? — governed data lake overview
- Lake Formation tag-based access control — LF-tags for scalable permissions
- Data filtering and cell-level security — row and cell filters on tables
FAQ
Chapter 8 — Operational data stores
Maps to Task Statement 2.1 — Choose a data store
Knowledge of:
- Storage platforms and their characteristics
- Storage services and configurations for specific performance demands
- Data storage formats (for example, .csv, .txt, Parquet)
- How to align data storage with data migration requirements
- How to determine the appropriate storage solution for specific access patterns
- How to manage locks to prevent access to data (for example, Amazon Redshift, Amazon RDS)
Skills in:
- Implementing the appropriate storage services for specific cost and performance requirements (for example, Amazon Redshift, Amazon EMR, AWS Lake Formation, Amazon RDS, DynamoDB, Amazon Kinesis Data Streams, Amazon MSK)
- Configuring the appropriate storage services for specific access patterns and requirements (for example, Amazon Redshift, Amazon EMR, Lake Formation, Amazon RDS, DynamoDB)
- Applying storage services to appropriate use cases (for example, Amazon S3)
- Integrating migration tools into data processing systems (for example, AWS Transfer Family)
- Implementing data migration or remote access methods (for example, Amazon Redshift federated queries, Amazon Redshift materialized views, Amazon Redshift Spectrum)
8.1 Amazon DynamoDB ★★ Important
DynamoDB appears as the low-latency key-value store in pipelines and as a change-capture source. Know partition and sort keys, hot-partition symptoms and remedies (better key distribution, write sharding), provisioned vs on-demand capacity, DynamoDB Streams feeding Lambda for CDC, TTL for automatic expiry, and export to S3 for analytics without consuming read capacity. If a question needs SQL analytics on DynamoDB data, the pattern is export (or stream) to S3 and query with Athena. Expect 2-4 questions.
Core docs
- What is Amazon DynamoDB? — managed NoSQL key-value store
- Partitions and data distribution — key design drives throughput
- Read/write capacity modes — provisioned vs on-demand
- DynamoDB Streams — item-level change capture
- Time to Live (TTL) — free automatic item expiry
- Exporting table data to Amazon S3 — full and incremental exports for analytics
FAQ
8.2 Amazon RDS and Aurora ★★ Important
Relational engines appear as pipeline sources and as the wrong answer for analytics at scale. Know read replicas for offloading extract queries, Multi-AZ for availability, row-level locking behaviour as a contrast with Redshift's table-level model, and Aurora zero-ETL integration with Redshift — the managed alternative to building a DMS/CDC pipeline for near-real-time warehouse sync. Expect 1-3 questions.
Core docs
- What is Amazon RDS? — managed relational databases
- Working with read replicas — offload reads and extracts
- What is Amazon Aurora? — MySQL/PostgreSQL-compatible, decoupled storage
- Aurora zero-ETL integrations with Amazon Redshift — near-real-time replication to the warehouse
FAQ
8.3 Purpose-built databases ★ Light
Learn one line each, mostly to eliminate distractors: DocumentDB for MongoDB-compatible JSON documents; Neptune for graph data (relationships, recommendation, fraud rings — the answer when the exam guide's "graph data structures" shows up as a use case); Keyspaces for Apache Cassandra workloads; MemoryDB for a durable Redis-compatible in-memory store. Expect 1-2 questions total.
Core docs
- What is Amazon DocumentDB? — MongoDB-compatible document database
- What is Amazon Neptune? — managed graph database
- What is Amazon Keyspaces? — serverless Cassandra-compatible database
- What is Amazon MemoryDB? — durable in-memory database
Chapter 9 — Data cataloging
Maps to Task Statement 2.2 — Understand data cataloging systems
Knowledge of:
- How to create a data catalog
- Data classification based on requirements
- Components of metadata and data catalogs
Skills in:
- Using data catalogs to consume data from the data's source
- Building and referencing a data catalog (for example, AWS Glue Data Catalog, Apache Hive metastore)
- Discovering schemas and using AWS Glue crawlers to populate data catalogs
- Synchronizing partitions with a data catalog
- Creating new source or target connections for cataloging (for example, AWS Glue)
9.1 AWS Glue Data Catalog and crawlers ★★★ Core
The Data Catalog is the metadata backbone: one Hive-metastore-compatible catalog per Region that Athena, Redshift Spectrum, EMR, and Glue ETL all read. Know crawlers (infer schemas and partitions from S3, JDBC, and DynamoDB sources, on demand or scheduled), classifiers (built-in and custom for unusual formats), how new S3 partitions get registered (re-run the crawler, MSCK REPAIR TABLE in Athena, or partition projection), partition indexes for faster query planning, and the Glue Schema Registry for enforcing Avro/JSON/Protobuf schemas on streams. Expect 3-5 questions.
Core docs
- Data discovery and cataloging in AWS Glue — catalog concepts, databases, tables
- Defining crawlers in AWS Glue — sources, schedules, schema change policy
- Adding classifiers to a crawler — built-in and custom format detection
- Working with partition indexes — speed up GetPartitions on large tables
- AWS Glue Schema Registry — schema validation and evolution for streaming
- Using AWS Glue to connect to data sources in Athena — how Athena consumes the catalog
FAQ
Chapter 10 — Managing the data lifecycle
Maps to Task Statement 2.3 — Manage the lifecycle of data
Knowledge of:
- Appropriate storage solutions to address hot and cold data requirements
- How to optimize the cost of storage based on the data lifecycle
- How to delete data to meet business and legal requirements
- Data retention policies and archiving strategies
- How to protect data with appropriate resiliency and availability
Skills in:
- Performing load and unload operations to move data between Amazon S3 and Amazon Redshift
- Managing S3 Lifecycle policies to change the storage tier of S3 data
- Expiring data when it reaches a specific age by using S3 Lifecycle policies
- Managing S3 versioning and DynamoDB TTL
10.1 S3 Lifecycle, versioning, and archival ★★★ Core
Lifecycle questions are near-guaranteed. Know transition actions (move objects to colder classes after N days) and expiration actions (delete after N days, including noncurrent versions in versioned buckets), the Glacier retrieval classes (Instant Retrieval for millisecond access, Flexible Retrieval in minutes to hours, Deep Archive at 12+ hours and lowest cost), Intelligent-Tiering when access patterns are unknown, and the minimum-storage-duration charges that make transitioning tiny short-lived objects a wrong answer. Replication (same-Region and cross-Region) covers the resiliency bullet. Expect 2-4 questions.
Core docs
- Managing your storage lifecycle — transition and expiration rules
- Lifecycle transition general considerations — constraints, minimum durations, costs
- Using versioning in S3 buckets — protect against deletes, expire noncurrent versions
- Replicating objects — same-Region and cross-Region replication
10.2 Retention, expiry, and movement patterns ★★ Important
The recurring load/unload pattern: COPY from S3 into Redshift for hot analytics, UNLOAD back to S3 (as Parquet) when data cools, then query it with Spectrum or Athena — keeping the cluster small and the history cheap. Loading best practice is many similar-sized files (ideally a multiple of the cluster's slice count), compressed, via a single COPY. DynamoDB TTL handles record-level expiry; AWS Backup centralises backup plans and retention across services. Expect 1-2 questions.
Core docs
- Amazon Redshift best practices for loading data — file sizing, compression, single COPY
- UNLOAD — write query results to S3 in Parquet
- DynamoDB Time to Live (TTL) — expire items automatically
- What is AWS Backup? — centralised backup plans and retention
Chapter 11 — Data models and schema evolution
Maps to Task Statement 2.4 — Design data models and schema evolution
Knowledge of:
- Data modeling concepts
- How to ensure accuracy and trustworthiness of data by using data lineage
- Best practices for indexing, partitioning strategies, compression, and other data optimization techniques
- How to model structured, semi-structured, and unstructured data
- Schema evolution techniques
Skills in:
- Designing schemas for Amazon Redshift, DynamoDB, and Lake Formation
- Addressing changes to the characteristics of data
- Performing schema conversion (for example, by using the AWS Schema Conversion Tool [AWS SCT] and AWS DMS Schema Conversion)
- Establishing data lineage by using AWS tools (for example, Amazon SageMaker ML Lineage Tracking)
11.1 Modeling for the warehouse and for NoSQL ★★ Important
Know star and snowflake schemas (facts and dimensions; star denormalises dimensions for fewer joins), and how they map to Redshift physical design — distribute the fact table and its biggest dimension on the join key, DISTSTYLE ALL for small dimensions, sort keys on the common filter columns. For DynamoDB, model around access patterns (single-table design, composite keys), not around normal forms. Partitioning, compression, and columnar formats are the optimisation levers for lake tables. Expect 2-3 questions.
Core docs
- Amazon Redshift best practices for designing tables — distribution, sort keys, compression
- Best practices for DynamoDB — key design, avoiding hot partitions
- DynamoDB single-table design — access-pattern-first modeling
11.2 Schema conversion, evolution, and lineage ★ Light
Know the tools by name: AWS SCT and DMS Schema Conversion convert schemas between database engines during migration; the Glue Schema Registry manages schema versions and compatibility modes (backward, forward, full) for streaming data — Avro being the format built for evolution; crawlers can update the catalog when lake schemas drift. SageMaker ML Lineage Tracking is the exam guide's named example for data lineage. Usually one question.
Core docs
- What is the AWS Schema Conversion Tool? — heterogeneous schema conversion
- DMS Schema Conversion — managed conversion inside DMS
- AWS Glue Schema Registry — compatibility modes and versioning
- Amazon SageMaker ML Lineage Tracking — track lineage of ML data and models
Part III — Domain 3: Data Operations and Support (22%)
Around 11 of the 50 scored questions. Running pipelines day to day: automating processing, analysing data with Athena and QuickSight, monitoring and troubleshooting with CloudWatch, and enforcing data quality.
Chapter 12 — Automating data processing
Maps to Task Statement 3.1 — Automate data processing by using AWS services
Knowledge of:
- How to maintain and troubleshoot data processing for repeatable business outcomes
- API calls for data processing
- Which services accept scripting (for example, Amazon EMR, Amazon Redshift, AWS Glue)
Skills in:
- Orchestrating data pipelines (for example, Amazon MWAA, Step Functions)
- Troubleshooting Amazon managed workflows
- Calling SDKs to access Amazon features from code
- Using the features of AWS services to process data (for example, Amazon EMR, Amazon Redshift, AWS Glue)
- Consuming and maintaining data APIs
- Preparing data transformation (for example, AWS Glue DataBrew)
- Querying data (for example, Amazon Athena)
- Using Lambda to automate data processing
- Managing events and schedulers (for example, EventBridge)
12.1 Automation with SDKs, data APIs, and EventBridge ★★ Important
Repeatable operations means code calling APIs. Know the Redshift Data API — run SQL against provisioned or serverless Redshift over HTTPS from Lambda and Step Functions with no persistent connection or driver, results retrieved asynchronously. The same pattern exists for Athena (StartQueryExecution) and Glue (StartJobRun). EventBridge schedules and event rules kick these off; Lambda stitches them together. Expect 1-3 questions, often "trigger this SQL after that job with the least infrastructure".
Core docs
- Using the Amazon Redshift Data API — connectionless SQL from serverless code
- AWS SDK for Python (Boto3) — the scripting interface to every data service
- Scheduled rules in EventBridge — cron-driven pipeline starts
- Athena SQL reference — automatable queries and views
12.2 AWS Batch ★ Light
Managed batch computing on ECS/EC2/Fargate: job definitions, job queues, and compute environments. The answer when a workload is containerised batch processing that isn't Spark-shaped and outlives Lambda's 15 minutes. Learn the one-line distinction against Glue (Spark ETL), EMR (big-data frameworks), and Lambda (short event-driven functions). Usually one question or a distractor.
Core docs
- What is AWS Batch? — queues, job definitions, compute environments
Chapter 13 — Analysing data
Maps to Task Statement 3.2 — Analyze data by using AWS services
Knowledge of:
- Tradeoffs between provisioned services and serverless services
- SQL queries (for example, SELECT statements with multiple qualifiers or JOIN clauses)
- How to visualize data for analysis
- When and how to apply cleansing techniques
- Data aggregation, rolling average, grouping, and pivoting
Skills in:
- Visualizing data by using AWS services and tools (for example, AWS Glue DataBrew, Amazon QuickSight)
- Verifying and cleaning data (for example, Lambda, Athena, QuickSight, Jupyter Notebooks, Amazon SageMaker Data Wrangler)
- Using Athena to query data or to create views
- Using Athena notebooks that use Apache Spark to explore data
13.1 Amazon Athena ★★★ Core
Serverless SQL over S3, billed per terabyte scanned — which is why every Athena cost/performance question is answered by "scan less": columnar formats, compression, partitioning, and partition projection (compute partitions from a template instead of the catalog — also fixes the "new partitions don't show up" problem). Know CTAS for materialising transformed tables, views, workgroups for per-team query limits and cost controls, federated queries to non-S3 sources through Lambda connectors, and Athena notebooks running Apache Spark for exploratory work. Expect 5-7 questions.
Core docs
- What is Amazon Athena? — serverless interactive SQL on S3
- Performance tuning in Athena — partitioning, formats, join order
- Partitioning data in Athena — partition columns, loading partitions
- Partition projection — skip the catalog for predictable layouts
- Creating a table from query results (CTAS) — transform and re-format with SQL
- Using workgroups to control query access and costs — per-workgroup limits and settings
- Athena federated query — query DynamoDB, RDS, and more via connectors
- Using Apache Spark in Amazon Athena — serverless Spark notebooks
FAQ
13.2 Amazon QuickSight ★★ Important
The visualization answer. Know SPICE (in-memory engine — import data for fast dashboards and to stop hammering the source) vs direct query (always current, source pays the cost), scheduled SPICE refreshes, row-level security for per-user filtering, and embedded dashboards. If a question wants business users to explore data visually with no infrastructure, it's QuickSight. Expect 1-2 questions.
Core docs
- What is Amazon QuickSight? — serverless BI and dashboards
- Importing data into SPICE — in-memory datasets and refresh
- Row-level security in QuickSight — per-user data restrictions
FAQ
13.3 Cleansing and exploration tools ★ Light
Beyond DataBrew and Athena, know the exam guide's named exploration tools at recognition level: SageMaker Data Wrangler for visual data preparation feeding ML workflows, Jupyter notebooks (on SageMaker or EMR) for hands-on exploration, and Glue interactive sessions for on-demand Spark development without a cluster. These mostly show up as answer options rather than question subjects.
Core docs
- Amazon SageMaker Data Wrangler — visual preparation for ML datasets
- AWS Glue interactive sessions — serverless Spark for notebooks
Chapter 14 — Maintaining and monitoring pipelines
Maps to Task Statement 3.3 — Maintain and monitor data pipelines
Knowledge of:
- How to log application data
- Best practices for performance tuning
- How to log access to AWS services
- Amazon Macie, AWS CloudTrail, and Amazon CloudWatch
Skills in:
- Extracting logs for audits
- Deploying logging and monitoring solutions to facilitate auditing and traceability
- Using notifications during monitoring to send alerts
- Troubleshooting performance issues
- Using CloudTrail to track API calls
- Troubleshooting and maintaining pipelines (for example, AWS Glue, Amazon EMR)
- Using Amazon CloudWatch Logs to log application data (with a focus on configuration and automation)
- Analyzing logs with AWS services (for example, Athena, Amazon EMR, Amazon OpenSearch Service, CloudWatch Logs Insights, big data application logs)
14.1 Amazon CloudWatch ★★★ Core
The default monitoring answer for every pipeline service. Know metrics, alarms (alarm to SNS is the standard alerting pattern), log groups and retention settings, CloudWatch Logs Insights for querying logs with its purpose-built query language, metric filters to turn log patterns into metrics, and dashboards. Glue, EMR, Lambda, Redshift, and MWAA all emit to CloudWatch — questions often hinge on knowing that the evidence for a failure lives in a specific service's CloudWatch logs. Expect 3-4 questions.
Core docs
- What is Amazon CloudWatch? — metrics and observability
- CloudWatch Logs — log groups, streams, retention
- CloudWatch Logs Insights — interactive log querying
- Metric filters — extract metrics from log events
- CloudWatch alarms — thresholds and SNS notifications
- CloudWatch dashboards — pipeline health at a glance
FAQ
14.2 Troubleshooting Glue and EMR pipelines ★★ Important
Know where the evidence is: Glue job runs emit metrics and continuous logs to CloudWatch, and the Spark UI exposes stages, skew, and shuffle spills; EMR writes step and application logs to CloudWatch and S3. Common exam scenarios and fixes — Glue OOM errors (more or larger workers, fix skewed keys, enable pushdown), jobs reprocessing old data (enable job bookmarks), slow queries on many small files (compact them), and long-running EMR steps (managed scaling, right instance types). Expect 2-3 questions.
Core docs
- Monitoring AWS Glue — job metrics and run insights
- Monitoring jobs with the Apache Spark web UI — stage-level diagnosis
- Continuous logging for AWS Glue jobs — real-time driver and executor logs
- Configure cluster logging and debugging on EMR — step logs, S3 log archiving
14.3 Amazon OpenSearch Service for log analytics ★ Light
The exam guide names OpenSearch as a log-analysis destination: ship application or pipeline logs (often via Firehose) and search or dashboard them in near real time. Learn it as the "operational search and log analytics at scale" option versus Logs Insights (ad hoc queries on CloudWatch) and Athena (SQL on logs archived in S3). Usually one question.
Core docs
- What is Amazon OpenSearch Service? — managed search and log analytics
FAQ
Chapter 15 — Ensuring data quality
Maps to Task Statement 3.4 — Ensure data quality
Knowledge of:
- Data sampling techniques
- How to implement data skew mechanisms
- Data validation (data completeness, consistency, accuracy, and integrity)
- Data profiling
Skills in:
- Running data quality checks while processing the data (for example, checking for empty fields)
- Defining data quality rules (for example, AWS Glue DataBrew)
- Investigating data consistency (for example, AWS Glue DataBrew)
15.1 AWS Glue Data Quality and DataBrew profiling ★★ Important
Two named tools. Glue Data Quality evaluates rules written in DQDL (Data Quality Definition Language) — completeness, uniqueness, freshness — against catalog tables or inside ETL jobs, with recommended rules generated from the data, and can fail a pipeline or just report. DataBrew profile jobs produce column statistics, distributions, and anomaly signals, and DataBrew supports its own data quality rules and validation reports. Know the four validation dimensions from the exam guide: completeness, consistency, accuracy, integrity. Expect 2-3 questions.
Core docs
- AWS Glue Data Quality — rule-based quality evaluation
- Data Quality Definition Language (DQDL) reference — rule types and syntax
- Creating and working with DataBrew jobs — profile jobs and validation
Part IV — Domain 4: Data Security and Governance (18%)
The smallest domain — around 9 of the 50 scored questions — but security options also decide correct answers throughout the other three. Authentication, authorization, encryption, audit logging, and privacy.
Chapter 16 — Authentication
Maps to Task Statement 4.1 — Apply authentication mechanisms
Knowledge of:
- VPC security networking concepts
- Differences between managed services and unmanaged services
- Authentication methods (password-based, certificate-based, and role-based)
- Differences between AWS managed policies and customer managed policies
Skills in:
- Updating VPC security groups
- Creating and updating IAM groups, roles, endpoints, and services
- Creating and rotating credentials for password management (for example, AWS Secrets Manager)
- Setting up IAM roles for access (for example, Lambda, Amazon API Gateway, AWS CLI, CloudFormation)
- Applying IAM policies to roles, endpoints, and services (for example, S3 Access Points, AWS PrivateLink)
16.1 IAM for data engineers ★★★ Core
Roles everywhere, users nowhere: Glue jobs, Lambda functions, Redshift COPY, and crawlers all act through IAM roles, and cross-service questions usually come down to which role is missing which permission (a Redshift COPY failing to read S3 means the cluster's associated role lacks s3:GetObject). Know policy structure, identity-based vs resource-based policies, AWS managed vs customer managed policies, evaluation logic (explicit deny wins), and least privilege as the default tiebreaker between answer options. Expect 3-4 questions.
Core docs
- What is IAM? — identities, policies, permissions
- Policies and permissions — JSON structure, managed vs inline
- Identity-based vs resource-based policies — who can act vs who can access
- Policy evaluation logic — explicit deny, then allow
- IAM roles — trust policies, temporary credentials
FAQ
16.2 AWS Secrets Manager and Parameter Store ★★ Important
Database credentials for Glue connections, MWAA connections, and Lambda must never be hardcoded. Secrets Manager stores and automatically rotates credentials (built-in rotation for RDS, Redshift, and DocumentDB) — it is the answer whenever "rotate" appears. Parameter Store holds configuration and SecureStrings without built-in rotation, with a free standard tier. Expect 1-2 questions.
Core docs
- What is AWS Secrets Manager? — store and rotate secrets
- Rotating secrets — managed rotation for database credentials
- AWS Systems Manager Parameter Store — configuration and SecureString values
FAQ
16.3 VPC networking for data services ★★ Important
Know the plumbing that keeps pipeline traffic private: security groups (stateful, instance/ENI level — Glue JDBC connections need a self-referencing rule), gateway VPC endpoints for S3 and DynamoDB (free, route-table based), interface endpoints via PrivateLink for most other services, and Redshift enhanced VPC routing to force COPY/UNLOAD traffic through the VPC. IP allowlisting for partner data sources means security group rules or firewall entries. Expect 1-3 questions.
Core docs
- What is Amazon VPC? — private networking fundamentals
- Control traffic with security groups — stateful rules at the resource level
- VPC endpoints — gateway and interface endpoints
- What is AWS PrivateLink? — private connectivity to services
- Redshift enhanced VPC routing — keep load/unload traffic in the VPC
FAQ
Chapter 17 — Authorization
Maps to Task Statement 4.2 — Apply authorization mechanisms
Knowledge of:
- Authorization methods (role-based, policy-based, tag-based, and attribute-based)
- Principle of least privilege as it applies to AWS security
- Role-based access control and expected access patterns
- Methods to protect data from unauthorized access across services
Skills in:
- Creating custom IAM policies when a managed policy does not meet the needs
- Storing application and database credentials (for example, Secrets Manager, AWS Systems Manager Parameter Store)
- Providing database users, groups, and roles access and authority in a database (for example, for Amazon Redshift)
- Managing permissions through Lake Formation (for Amazon Redshift, Amazon EMR, Athena, and Amazon S3)
17.1 Lake Formation permissions ★★★ Core
The centre of gravity for authorization questions. Lake Formation replaces bucket-policy sprawl with grant/revoke permissions on catalog resources — database, table, column, row, and cell level — enforced consistently by Athena, Redshift Spectrum, EMR, Glue, and QuickSight. Know named-resource grants vs LF-tag-based access control (tags scale; the exam favours them for large estates), data filters for row/cell security, and cross-account sharing of catalog resources. Expect 2-4 questions.
Core docs
- What is AWS Lake Formation? — permission model overview
- Lake Formation tag-based access control — LF-tags on databases, tables, columns
- Data filtering and cell-level security — row and cell filters
FAQ
17.2 In-database access control ★★ Important
Inside Redshift, authorization is SQL: GRANT and REVOKE on schemas, tables, and columns; role-based access control with CREATE ROLE for bundling privileges; row-level security policies; and IAM-based temporary credentials for sign-in instead of passwords. For DynamoDB, IAM condition keys give fine-grained (item and attribute level) access. Least privilege phrasing decides most of these questions. Expect 1-2 questions.
Core docs
- GRANT — object privileges in Redshift
- Role-based access control in Amazon Redshift — roles and system privileges
- Using IAM policy conditions for fine-grained access control in DynamoDB — item and attribute-level permissions
Chapter 18 — Encryption and masking
Maps to Task Statement 4.3 — Ensure data encryption and masking
Knowledge of:
- Data encryption options available in AWS analytics services (for example, Amazon Redshift, Amazon EMR, AWS Glue)
- Differences between client-side encryption and server-side encryption
- Protection of sensitive data
- Data anonymization, masking, and key salting
Skills in:
- Applying data masking and anonymization according to compliance laws or company policies
- Using encryption keys to encrypt or decrypt data (for example, AWS Key Management Service [AWS KMS])
- Configuring encryption across AWS account boundaries
- Enabling encryption in transit for data.
18.1 AWS KMS ★★ Important
KMS keys sit under encryption in every data service. Know AWS managed keys vs customer managed keys (use customer managed when you need key policies, rotation control, or cross-account access), envelope encryption, and that cross-account use requires both a key policy grant on the key and IAM permissions on the caller. Client-side encryption means the data is encrypted before AWS sees it; server-side means the service encrypts on write. Expect 2-3 questions.
Core docs
- What is AWS KMS? — managed keys and cryptographic APIs
- AWS KMS concepts — key types, data keys, envelope encryption
- Key policies — the gate for cross-account access
FAQ
18.2 Encryption in the data stack ★★ Important
Per-service encryption facts that decide questions: S3 encrypts everything at rest by default (SSE-S3), with SSE-KMS for auditable key control; Redshift clusters can be KMS-encrypted (set at creation); EMR uses security configurations for at-rest (EMRFS/local disk) and in-transit encryption; Glue uses security configurations for job bookmarks, CloudWatch logs, and S3 targets. In transit is TLS everywhere. Expect 1-2 questions.
Core docs
- Protecting data with server-side encryption in S3 — SSE-S3, SSE-KMS, SSE-C, DSSE
- Amazon Redshift database encryption — KMS-backed cluster encryption
- Encrypt data at rest and in transit on EMR — security configurations
- Encrypting data written by AWS Glue — Glue security configurations
18.3 Masking and anonymization ★★ Important
Distinguish the techniques: masking hides values while keeping the column usable (Redshift dynamic data masking applies masking policies at query time by user role); anonymization removes the link to a person irreversibly; hashing with salts prevents rainbow-table reversal of identifiers; and Lake Formation data filters simply deny access to sensitive columns and cells. DataBrew includes PII redaction and hashing transformations for masking at preparation time. Expect 1-2 questions.
Core docs
- Dynamic data masking in Amazon Redshift — role-aware masking policies
- Lake Formation data filtering — hide columns and cells outright
- AWS Glue DataBrew recipe steps — PII redaction and hashing transforms
Chapter 19 — Preparing logs for audit
Maps to Task Statement 4.4 — Prepare logs for audit
Knowledge of:
- How to log application data
- How to log access to AWS services
- Centralized AWS logs
Skills in:
- Using CloudTrail to track API calls
- Using CloudWatch Logs to store application logs
- Using AWS CloudTrail Lake for centralized logging queries
- Analyzing logs by using AWS services (for example, Athena, CloudWatch Logs Insights, Amazon OpenSearch Service)
- Integrating various AWS services to perform logging (for example, Amazon EMR in cases of large volumes of log data)
19.1 AWS CloudTrail and CloudTrail Lake ★★ Important
CloudTrail answers "who called what API when": management events by default, data events (S3 object-level, Lambda invocations) opt-in, trails delivering to S3 for retention. CloudTrail Lake is the exam's named answer for centralized, SQL-queryable audit logging without building your own Athena pipeline — immutable event data stores queried directly. Expect 1-2 questions.
Core docs
- What is AWS CloudTrail? — API audit logging
- Logging management events — control plane vs data events
- Working with AWS CloudTrail Lake — SQL queries over centralized audit events
FAQ
19.2 Centralized log analysis ★ Light
Match the tool to the log location: CloudWatch Logs Insights for logs already in CloudWatch, Athena for logs archived in S3 (CloudTrail, ALB, VPC Flow Logs — a very common pattern question), OpenSearch for interactive search at scale, and EMR when log volumes are genuinely big-data sized. Usually one question.
Core docs
- Querying AWS CloudTrail logs with Athena — SQL over audit logs in S3
- CloudWatch Logs Insights — query CloudWatch log groups
Chapter 20 — Data privacy and governance
Maps to Task Statement 4.5 — Understand data privacy and governance
Knowledge of:
- How to protect personally identifiable information (PII)
- Data sovereignty
Skills in:
- Granting permissions for data sharing (for example, data sharing for Amazon Redshift)
- Implementing PII identification (for example, Macie with Lake Formation)
- Implementing data privacy strategies to prevent backups or replications of data to disallowed AWS Regions
- Managing configuration changes that have occurred in an account (for example, AWS Config)
20.1 Amazon Macie ★★ Important
Macie is the managed answer for finding PII: it continuously discovers sensitive data in S3 using managed data identifiers (names, credentials, card numbers) plus custom identifiers, produces findings you can route via EventBridge, and pairs with Lake Formation to lock down what it finds. If the question says "discover" or "identify" PII in S3, it's Macie; if it says "mask" or "restrict access to" columns, it's back to Chapter 18. Expect 1-2 questions.
Core docs
- What is Amazon Macie? — sensitive data discovery for S3
- Managed data identifiers — built-in PII and secret detection
20.2 AWS Config, data sovereignty, and governed sharing ★ Light
AWS Config records resource configuration changes and evaluates rules (an unencrypted bucket or a public Redshift cluster triggers noncompliance) — the answer for "track configuration changes in the account". Data sovereignty questions are about keeping data in allowed Regions: restrict replication destinations, and deny disallowed Regions with IAM or SCP condition keys. Redshift data sharing (Chapter 6) reappears here as the governed way to share warehouse data without copying. Usually one question.
Core docs
- What is AWS Config? — resource configuration history
- Evaluating resources with AWS Config rules — compliance-as-code checks
- Data sharing in Amazon Redshift — governed, no-copy sharing