AWS Data Engineer – Associate (DEA-C01) — Free Sample Questions
Practice with 30 free Data Engineer Associate questions covering real-world data pipeline scenarios on AWS. Each question is mapped to an official DEA-C01 domain with a detailed explanation.
Exam Domains
- Data Ingestion and Transformation (34%) — Kinesis Data Streams vs. Firehose, Glue ETL jobs, Glue crawlers, Step Functions orchestration
- Data Store Management (26%) — S3 partitioning strategies, DynamoDB table design, Redshift distribution keys, Lake Formation permissions
- Data Operations and Support (22%) — Glue job bookmarks, pipeline scheduling, data quality checks, EventBridge triggers
- Data Security and Governance (18%) — Lake Formation column-level security, S3 bucket policies, KMS CMK rotation, CloudTrail data events
Critical Concepts for DEA-C01
This exam expects you to choose the right tool for each stage of a data pipeline:
- Ingestion: Kinesis Streams (low-latency), Firehose (zero admin), DMS (database migration), AppFlow (SaaS)
- Transformation: Glue Spark (batch), Glue Streaming (near-real-time), EMR (custom Spark/Hive)
- Storage: S3 (data lake), Redshift (warehouse), DynamoDB (key-value), OpenSearch (search/analytics)
- Governance: Lake Formation (fine-grained access), Glue Data Catalog (metadata), Macie (PII discovery)
Study Approach
- Understand Glue end-to-end: crawlers → Data Catalog → ETL jobs → bookmarks
- Know S3 partitioning for Athena query performance (Hive-style partitions)
- Learn Kinesis shard math: 1 MB/s in per shard, 2 MB/s out
- Practice choosing between Glue, EMR, and Athena for different workloads
Access the Full Path
Beyond these samples, access 600 DEA-C01 questions in a structured 30-day path with 2 full-length practice exams.
All 30 Free Sample Questions
Question 1 — Domain 1: Data Ingestion and Transformation
A data pipeline needs to run every day at 2 AM to ingest batch data from multiple sources. Which service should be used for scheduling?
- Continuous Lambda polling
- Amazon EventBridge scheduled rules — Correct answer
- Manual execution each day
- S3 Event Notifications
Explanation:
- Why B is correct: Amazon EventBridge supports cron and rate-based schedule rules that can trigger AWS services (Lambda, Step Functions, Glue, etc.) at precise times. A cron rule for 2 AM daily is the standard, fully managed approach for time-based batch pipeline orchestration.
- Why A is wrong: Continuously polling with Lambda would run 24/7, consuming unnecessary invocations and cost, when the requirement is a single daily execution at a fixed time.
- Why C is wrong: Manual execution introduces human error, cannot guarantee the 2 AM window, and does not scale across multiple pipelines or team members.
- Why D is wrong: S3 Event Notifications fire when objects are created, modified, or deleted in a bucket. They are event-driven, not time-driven, so they cannot schedule a pipeline to run at a specific clock time.
Question 2 — Domain 1: Data Ingestion and Transformation
A company needs to convert hundreds of gigabytes of CSV files in Amazon S3 into Apache Parquet format on a recurring weekly schedule. The team has no existing Hadoop or Spark infrastructure and wants to minimize operational overhead. Which AWS service should the data engineer use?
- Provision an Amazon EMR cluster with Apache Spark to run the conversion
- Use an AWS Glue ETL job to read CSV and write Parquet to S3 — Correct answer
- Load the data into Amazon Redshift and use UNLOAD to export as Parquet
- Use AWS Lambda functions to convert each file individually
Explanation:
- Why correct: AWS Glue is a fully managed, serverless ETL service that automatically provisions and scales the infrastructure needed for data transformation. For a straightforward CSV-to-Parquet conversion with no existing Hadoop/Spark cluster, Glue is the simplest and most operationally efficient choice. It requires no cluster management, no infrastructure provisioning, and integrates natively with the AWS Glue Data Catalog for schema discovery.
- Why A is wrong: Amazon EMR requires provisioning and managing a cluster (choosing instance types, configuring Spark, managing scaling policies). For a simple format conversion job, this adds unnecessary operational overhead compared to the serverless Glue approach.
- Why C is wrong: Amazon Redshift is a data warehouse designed for analytical queries, not a general-purpose ETL tool. Using UNLOAD to convert formats requires first loading data into Redshift, which is an expensive and convoluted approach for a simple transformation task.
- Why D is wrong: AWS Lambda has a 15-minute execution timeout and limited memory (up to 10 GB). Processing large datasets (hundreds of GBs) would require complex chunking logic and orchestration, making it impractical compared to Glue which handles large-scale transformations natively.
Question 3 — Domain 1: Data Ingestion and Transformation
A company has over 50 interdependent ETL jobs that run on different schedules, with complex dependency chains between them. The data engineering team has experience with Apache Airflow and needs full control over scheduling, retry logic, and dependency management. Which AWS service should they use to orchestrate these pipelines?
- AWS Step Functions with a single large state machine
- Amazon MWAA (Managed Workflows for Apache Airflow) with DAG-based scheduling — Correct answer
- AWS Glue workflows with triggers and crawlers
- Amazon EventBridge rules with scheduled invocations
Explanation:
- Why correct: Amazon MWAA is a managed Apache Airflow service that supports complex DAG-based scheduling with dependencies, branching, and conditional logic. Teams already experienced with Airflow can migrate existing DAGs with minimal changes, making MWAA the best fit for complex dependency management across many interdependent jobs.
- Why A is wrong: AWS Step Functions excels at orchestrating sequential or parallel workflows with built-in integrations, but it uses a state-machine model rather than DAG-based scheduling. Managing 50+ jobs with complex inter-dependencies and time-based schedules is more naturally expressed in Airflow DAGs than Step Functions state machines.
- Why C is wrong: AWS Glue workflows can orchestrate Glue crawlers and jobs, but they are limited to Glue-native components. They cannot natively orchestrate non-Glue services like EMR or Lambda within the same workflow, making them too narrow for this use case.
- Why D is wrong: Amazon EventBridge can trigger workflows on schedules or events, but it is an event bus, not a workflow orchestrator. It cannot manage complex job dependencies, branching logic, or retry policies across 50+ interdependent jobs.
Question 4 — Domain 1: Data Ingestion and Transformation
A data pipeline uses multiple Lambda functions. A high-throughput ingestion function triggered by SQS is consuming most of the account's concurrent execution limit, causing downstream transformation functions to be throttled. How should a data engineer resolve this?
- Set provisioned concurrency to 500 for all Lambda functions in the pipeline
- Configure reserved concurrency on the ingestion function to prevent it from consuming the account's entire concurrent execution pool — Correct answer
- Increase the account-level concurrent execution limit to 50,000
- Remove all concurrency settings and let Lambda auto-scale without limits
Explanation:
- Why correct: Reserved concurrency guarantees a specific number of concurrent executions for a Lambda function while also capping it, preventing one function from starving others in the account. This is essential when a high-throughput ingestion function (triggered by SQS) could otherwise consume the account's default 1,000 concurrent execution limit and throttle downstream functions.
- Why A is wrong: Reserved concurrency is the right tool here, not provisioned concurrency. Provisioned concurrency keeps execution environments warm to eliminate cold starts—it does not cap or reserve a share of the concurrency pool. Also, applying it to all functions at 500 would be expensive and unnecessary.
- Why C is wrong: Increasing the account limit is a quota change request, not a configuration that prevents one function from starving others. Even with a higher limit, the ingestion function could still consume a disproportionate share.
- Why D is wrong: Without any concurrency controls, a spike in SQS messages could cause the ingestion function to scale to the full account limit, throttling all other Lambda functions in the account.
Question 5 — Domain 1: Data Ingestion and Transformation
A data engineering team uses AWS Step Functions to orchestrate an ETL pipeline. After a data quality validation step, the workflow must route records to different processing paths: clean records go to a transformation job, while records with errors are sent to a quarantine S3 bucket. Which Step Functions state type should the team use to implement this routing logic?
- Use a Parallel state to run both paths and discard the unnecessary output
- Use a Map state to iterate over records and apply conditional logic within each iteration
- Use a Wait state to pause execution until the data quality results are available
- Use a Choice state to evaluate the data quality result and branch to the appropriate path — Correct answer
Explanation:
- Why correct: The Choice state in Step Functions evaluates input variables against conditions (e.g., checking a data quality flag) and routes execution to different branches accordingly. This is the standard pattern for conditional branching in state machines — for example, checking if a 'qualityStatus' field equals 'PASS' or 'FAIL' and routing to the appropriate next state.
- Why A is wrong: The Parallel state executes multiple branches simultaneously and waits for all to complete. It does not make routing decisions based on input data — it always runs all branches, which would process both the transformation and quarantine paths regardless of data quality results.
- Why B is wrong: The Map state iterates over a collection of items and applies the same processing to each item. While useful for batch processing arrays of records, it does not provide conditional routing logic between different workflow paths.
- Why C is wrong: The Wait state simply pauses execution for a specified time or until a timestamp. It has no decision-making or routing capability.
Question 6 — Domain 2: Data Store Management
A streaming analytics application ingests 500,000 events per second from IoT sensors and requires real-time processing with sub-second latency. The data must be retained for 7 days to support replay and reprocessing. The team wants to minimize operational overhead while handling variable traffic. Which service meets these requirements?
- Amazon Managed Streaming for Apache Kafka (Amazon MSK) with provisioned brokers
- Amazon SQS FIFO queue
- Amazon Kinesis Data Streams with on-demand capacity mode — Correct answer
- Amazon Redshift Streaming Ingestion
Explanation:
- Why correct: Amazon Kinesis Data Streams with on-demand capacity mode automatically scales to handle variable throughput without manual shard management. It supports data retention up to 365 days (7 days is within range), enables stream replay, and delivers sub-second latency for real-time analytics. On-demand mode eliminates the need to provision and manage shard counts.
- Why A is wrong: Amazon MSK (Managed Streaming for Apache Kafka) can handle the throughput and retention requirements, but it requires provisioning and managing broker instances and cluster capacity. This adds operational overhead compared to Kinesis on-demand mode, which was a key concern in the scenario.
- Why B is wrong: Amazon SQS is a message queue, not a streaming platform. It does not natively support ordered stream processing, replay of consumed messages, or the throughput patterns required for real-time streaming analytics at this scale.
- Why D is wrong: Amazon Redshift Streaming Ingestion is a feature for ingesting streaming data into Redshift for analytics, not a standalone streaming data store. It consumes from Kinesis or MSK but does not replace the need for an upstream streaming service.
Question 7 — Domain 2: Data Store Management
A company uses Amazon EMR with Apache Spark for data processing and also runs AWS Glue ETL jobs. Both services need to share the same table metadata. How should the data engineer configure EMR to achieve this with the LEAST operational overhead?
- Export Hive metastore data to Amazon S3 nightly and import it into the Glue Data Catalog using a scheduled Lambda function
- Configure Amazon EMR to use the AWS Glue Data Catalog as the external Hive metastore — Correct answer
- Create duplicate table definitions in both the EMR Hive metastore and the Glue Data Catalog and synchronize them manually
- Use Amazon RDS for MySQL as a shared Hive-compatible metastore for both EMR and Glue
Explanation:
- Why correct: Amazon EMR can be configured to use the AWS Glue Data Catalog as its external Hive metastore. This gives both EMR Spark jobs and Glue ETL jobs a single, shared source of truth for table metadata with no additional infrastructure to manage.
- Why A is wrong: Exporting and importing metastore data via S3 and Lambda introduces latency, complexity, and the risk of stale metadata. The Glue Data Catalog integration is a native, real-time solution.
- Why C is wrong: Maintaining duplicate metadata in two systems creates drift and synchronization overhead. A single shared catalog eliminates this problem.
- Why D is wrong: AWS Glue ETL does not support using an external RDS-based Hive metastore. Glue only reads from the Glue Data Catalog. This approach would not meet the shared-metadata requirement.
Question 8 — Domain 2: Data Store Management
A company needs to export the results of a complex Redshift analytical query to Amazon S3 so that a downstream machine learning team can consume the data. The output must be in Parquet format and partitioned by date. Which solution meets these requirements with the LEAST operational overhead?
- Create a Redshift stored procedure that writes results to an EC2-mounted EBS volume, then copy to S3
- Use the Redshift UNLOAD command with the FORMAT AS PARQUET option and PARTITION BY clause — Correct answer
- Use AWS Glue to read from Redshift via a JDBC connection and write to S3 in Parquet format
- Use Amazon Kinesis Data Firehose to stream query results from Redshift to S3
Explanation:
- Why correct: The Redshift UNLOAD command natively supports FORMAT AS PARQUET and the PARTITION BY clause. This exports query results directly from Redshift to S3 in Parquet format with the specified partitioning, all in a single SQL statement — no additional services or orchestration needed.
- Why A is wrong: Writing to an EC2-mounted EBS volume and then copying to S3 introduces an unnecessary intermediate hop, requires managing EC2 infrastructure, and does not natively produce Parquet output or partitioned data.
- Why B is correct: This is the correct answer.
- Why C is wrong: While AWS Glue can read from Redshift and write Parquet to S3, it requires setting up a Glue job, Redshift connection, IAM roles, and a VPC configuration. This adds significant operational overhead compared to a single UNLOAD statement.
- Why D is wrong: Kinesis Data Firehose is a streaming ingestion service. It cannot execute Redshift queries or export query results. Firehose delivers streaming data to destinations, not query outputs from a data warehouse.
Question 9 — Domain 2: Data Store Management
A gaming company stores player session data in Amazon DynamoDB. Each player generates hundreds of sessions per month. The application must support two access patterns: (1) retrieve all sessions for a specific player sorted by timestamp, and (2) query sessions by game mode across all players for the last 24 hours. Which table design supports both patterns most efficiently?
- Use session_id as the partition key with no sort key; scan the table with filters for both access patterns
- Use game_mode as the partition key and player_id as the sort key on the base table
- Use player_id as the partition key and session_timestamp as the sort key; create a global secondary index (GSI) with game_mode as the partition key and session_timestamp as the sort key — Correct answer
- Use a composite attribute player_id#session_timestamp as the partition key with no sort key; create a local secondary index on game_mode
Explanation:
- Why C is correct: Using player_id as the partition key and session_timestamp as the sort key on the base table directly supports pattern 1—a Query on player_id returns sessions in chronological order. The GSI with game_mode as the partition key and session_timestamp as the sort key efficiently supports pattern 2 by partitioning sessions by game mode and sorting by time, enabling a key condition on the last 24 hours.
- Why A is wrong: Using session_id as the sole partition key with no sort key forces full table scans for both access patterns, which is extremely inefficient and expensive at scale.
- Why B is wrong: Using game_mode as the base table partition key optimizes only pattern 2 and makes pattern 1 (all sessions for a specific player) require a full table scan or an additional GSI not addressed in this option.
- Why D is wrong: A composite string as the partition key prevents range queries on the timestamp component. Local secondary indexes share the same partition key as the base table, so an LSI on game_mode would only allow queries within a single composite partition—not across all players.
Question 10 — Domain 2: Data Store Management
A company ingests clickstream data from its website at a rate of 500,000 events per second. The data engineering team needs to store this streaming data with the ability to replay events for up to 7 days. Multiple downstream consumer applications will read the stream independently at their own pace. Which TWO services can meet these requirements? (Select TWO.)
- Amazon Kinesis Data Firehose
- Amazon Kinesis Data Streams — Correct answer
- Amazon SQS
- Amazon MSK — Correct answer
- Amazon DynamoDB Streams
Explanation:
- Why correct (B - Amazon Kinesis Data Streams): Kinesis Data Streams is designed for real-time streaming ingestion at scale. It supports configurable data retention from 24 hours up to 365 days, and multiple consumers can independently read from the same stream using enhanced fan-out, enabling replay of events at each consumer's own pace.
- Why correct (D - Amazon MSK): Amazon MSK (Managed Streaming for Apache Kafka) provides a fully managed Apache Kafka service that retains data based on configurable retention policies. Kafka natively supports multiple independent consumer groups, each tracking their own offset and reading at their own pace with full replay capability.
- Why A is wrong: Amazon Kinesis Data Firehose is a delivery service that loads streaming data into destinations like Amazon S3, Amazon Redshift, or Amazon OpenSearch Service. It does not retain data for consumer replay — it delivers and moves on. There is no concept of multiple independent consumers replaying from Firehose.
- Why C is wrong: Amazon SQS is a message queue service. Standard SQS does not guarantee ordering and deletes messages after they are consumed by a single consumer. While SQS FIFO provides ordering, neither variant supports independent multi-consumer replay of the same messages over 7 days.
- Why E is wrong: Amazon DynamoDB Streams captures item-level changes in DynamoDB tables but has a fixed 24-hour retention limit, which does not meet the 7-day replay requirement. It is also designed for change data capture, not high-throughput event ingestion at 500,000 events per second.
Question 11 — Domain 3: Data Operations and Support
A data engineer has an Amazon MWAA environment running a daily ETL DAG. One of the tasks in the DAG fails intermittently with no clear pattern. The engineer needs to identify the root cause. What should the engineer do FIRST?
- Increase the MWAA environment class to provide more resources
- Review the Apache Airflow task logs in Amazon CloudWatch Logs for the failing task — Correct answer
- Delete the DAG file from the S3 bucket and re-upload it
- Restart the MWAA environment to reset all running workflows
Explanation:
- Why correct: When an MWAA DAG task fails, the first troubleshooting step is to check the Apache Airflow task logs in Amazon CloudWatch Logs. MWAA automatically streams Airflow task logs, scheduler logs, web server logs, and worker logs to CloudWatch. The task-level logs show the exact error, stack trace, and operator output that caused the failure.
- Why A is wrong: Increasing the MWAA environment class (e.g., from mw1.small to mw1.large) addresses resource constraints but does not help diagnose why a specific task failed. You must first identify the root cause from logs before scaling resources.
- Why C is wrong: Deleting and recreating the DAG file in S3 would restart from scratch but does not address the underlying failure. The DAG definition is not necessarily the problem — the issue could be a runtime error, permission issue, or connection failure that logs would reveal.
- Why D is wrong: Restarting the entire MWAA environment is a heavy-handed approach that causes downtime for all DAGs. It does not address the root cause and should only be considered after logs have been reviewed and other targeted fixes have been attempted.
Question 12 — Domain 3: Data Operations and Support
A data engineer needs to quickly understand data quality issues in a new dataset stored in Amazon S3 before building an ETL pipeline. The engineer wants to see column distributions, missing values, and correlations without writing code. Which approach is MOST efficient?
- Write custom PySpark scripts in AWS Glue to compute column-level statistics
- Create an Amazon QuickSight analysis connected directly to the raw S3 files
- Run an AWS Glue DataBrew data profile job on the dataset — Correct answer
- Query the data using Amazon Athena and manually calculate statistics with SQL
Explanation:
- Why correct (C): AWS Glue DataBrew data profile jobs automatically generate over 40 statistics per column — including distributions, missing value counts, correlations, outliers, and data type detection — all through a visual, no-code interface. This is the fastest way to assess data quality before building an ETL pipeline.
- Why A is wrong: Writing custom PySpark scripts requires coding effort, testing, and Glue job configuration. This is not the most efficient approach when DataBrew can produce the same insights with zero code.
- Why B is wrong: QuickSight is a business intelligence dashboarding service designed for reporting and visual analytics. It is not optimized for data quality profiling tasks like detecting missing values, outliers, or column correlations.
- Why D is wrong: Using Athena would require the engineer to write individual SQL queries for each statistic (COUNT, DISTINCT, NULL checks, percentiles) manually. This is time-consuming and does not provide the comprehensive, automated profiling that DataBrew offers.
Question 13 — Domain 3: Data Operations and Support
A data engineering team runs Apache Spark jobs on Amazon EMR to process clickstream data. They need to capture application-level logs (such as custom metrics and processing counts) from each Spark executor and make them available for near-real-time troubleshooting in a centralized location. Which approach should they use?
- Write all Spark executor logs to HDFS and query them after cluster termination
- Install the Amazon CloudWatch agent on EMR nodes to push application logs to CloudWatch Logs — Correct answer
- Enable S3 server access logging on the EMR log bucket to capture executor output
- Use AWS X-Ray to trace and collect all Spark executor log output
Explanation:
- Why correct: The Amazon CloudWatch agent can be installed on EMR cluster nodes to push custom application logs from Spark executors directly to CloudWatch Logs. This provides centralized, near-real-time log access without requiring additional infrastructure. EMR also natively supports pushing logs to CloudWatch when configured.
- Why A is wrong: Writing logs to HDFS keeps them distributed across the cluster nodes. HDFS is local to the cluster and does not provide centralized near-real-time access — an engineer would need to SSH into nodes or wait for the cluster to terminate for logs to be archived.
- Why C is wrong: While S3 server access logging tracks requests made to S3 buckets, it does not capture application-level logs from Spark executors. It is designed for auditing S3 access patterns, not EMR application monitoring.
- Why D is wrong: AWS X-Ray provides distributed tracing for request flows across microservices, not log aggregation for batch Spark jobs. It would not capture custom application metrics or processing counts from Spark executors.
Question 14 — Domain 3: Data Operations and Support
A company ingests streaming IoT sensor data through Amazon Kinesis Data Streams into an AWS Glue streaming ETL job before writing to Amazon S3 in Parquet format. The data engineering team has noticed that some sensor readings arrive with invalid timestamps (future dates) and out-of-range temperature values. Which solution validates data quality during stream processing with the LEAST operational overhead?
- Deploy a separate AWS Lambda consumer on the Kinesis stream to validate each record before the Glue job processes it
- Add AWS Glue Data Quality rules within the streaming ETL job to validate timestamp ranges and temperature bounds, routing invalid records to a dead-letter S3 prefix — Correct answer
- Write a custom Apache Spark Structured Streaming application on Amazon EMR to validate and filter records
- Use Amazon Kinesis Data Analytics (managed Apache Flink) to validate records and write only valid ones to a second Kinesis stream
Explanation:
- Why correct: AWS Glue Data Quality can be embedded directly within Glue streaming ETL jobs. Using DQDL rules such as ColumnValues to check that timestamps are not in the future and that temperature values fall within expected ranges, you can validate data inline during processing. Invalid records can be automatically routed to a dead-letter prefix. This requires no additional infrastructure and provides the least operational overhead since it runs within the existing Glue job.
- Why A is wrong: Adding a separate Lambda consumer increases operational complexity with a second consumer application to manage. It also introduces ordering and coordination challenges between the Lambda validator and the Glue job.
- Why C is wrong: Running a custom Spark Structured Streaming application on EMR requires managing cluster infrastructure, writing custom validation code, and significantly more operational overhead than using Glue's built-in data quality features.
- Why D is wrong: Using Kinesis Data Analytics adds another managed service and requires writing Flink SQL or application code for validation. This adds cost and complexity compared to using built-in Glue Data Quality rules.
Question 15 — Domain 3: Data Operations and Support
A company receives small CSV files from vendors that are uploaded to an S3 bucket at unpredictable intervals throughout the day. Each file must be validated, lightly transformed, and written to a DynamoDB table within minutes of arrival. The team wants minimal operational overhead. What is the MOST operationally efficient way to automate this processing?
- Create an Amazon EventBridge scheduled rule to invoke a Lambda function every 5 minutes to check for new files
- Configure an S3 event notification to trigger a Lambda function on object creation — Correct answer
- Run a continuously polling script on an EC2 instance that monitors the S3 bucket
- Schedule an AWS Glue crawler to run every 10 minutes to detect new files and process them
Explanation:
- Why correct: Configuring an S3 event notification to trigger a Lambda function is the most operationally efficient approach for this use case. When a new CSV file lands in the S3 bucket, S3 sends an event notification directly to Lambda, which can then validate, transform, and write the processed data to the target. This is fully serverless, event-driven, requires no polling infrastructure, and scales automatically with the volume of incoming files. Lambda's 15-minute timeout is sufficient for small-to-medium CSV files.
- Why A is wrong: An EventBridge scheduled rule that invokes Lambda every 5 minutes introduces unnecessary polling. During periods with no new files, Lambda runs wastefully and incurs costs. When multiple files arrive between intervals, processing is delayed. Event-driven triggers are more responsive and cost-efficient than scheduled polling for file-arrival use cases.
- Why C is wrong: Running a continuously polling script on an EC2 instance is not serverless and requires you to manage the instance, handle scaling, and pay for idle compute time. It also introduces complexity around polling intervals, error handling, and instance availability. This approach contradicts the requirement for minimal operational overhead.
- Why D is wrong: AWS Glue crawlers are designed to discover and catalog metadata (schemas, partitions) from data sources. They do not perform data transformation or loading logic. A crawler would update the Glue Data Catalog with the CSV schema but would not validate, transform, or move the data to a target store.
Question 16 — Domain 4: Data Security and Governance
A company hires five new data analysts who need read access to specific Amazon S3 buckets and Amazon Athena query permissions. The data engineering team wants to manage their permissions efficiently and follow AWS best practices. What should the team do?
- Create individual IAM users for each analyst with inline policies granting S3 and Athena permissions
- Create an IAM group called DataAnalysts, attach managed policies for S3 read and Athena access to the group, and add each analyst's IAM user to the group — Correct answer
- Share a single IAM user with the team and attach the required policies to that user
- Create an IAM role for each analyst and have them assume the role using their personal AWS credentials
Explanation:
- Why correct (B): Creating an IAM group and attaching policies to the group is the AWS-recommended approach for managing permissions for multiple users with the same access requirements. When a new analyst joins, the administrator simply adds their IAM user to the group and they inherit all group policies. This centralizes permission management and reduces administrative overhead.
- Why A is wrong: Inline policies attached to individual users are harder to manage at scale. If the permission set changes, every user's inline policy must be updated individually. AWS recommends using managed policies attached to groups instead.
- Why C is wrong: Sharing a single IAM user among multiple people violates AWS security best practices. It eliminates individual accountability because CloudTrail logs cannot distinguish which person performed an action, and credentials cannot be revoked for one person without affecting everyone.
- Why D is wrong: Creating a separate IAM role for each analyst is unnecessary overhead for this use case. IAM roles are designed for temporary credential delegation (e.g., cross-account access, service access), not for assigning day-to-day permissions to individual human users. IAM groups are the correct mechanism for grouping users with identical permission needs.
Question 17 — Domain 4: Data Security and Governance
A company's Lambda function connects to an Amazon RDS PostgreSQL database using credentials stored as plaintext Lambda environment variables. A security audit requires that credentials be centrally managed with automatic rotation. Which solution meets these requirements?
- Move credentials to an S3 object encrypted with SSE-KMS and update Lambda to read from S3 at runtime
- Store credentials in AWS Systems Manager Parameter Store as a SecureString parameter
- Store credentials in AWS Secrets Manager and enable automatic rotation with a Lambda rotation function — Correct answer
- Encrypt the existing Lambda environment variables using a customer-managed AWS KMS key
Explanation:
- Why C is correct: AWS Secrets Manager is purpose-built for storing and automatically rotating database credentials. It provides native integration with Amazon RDS for automatic rotation using a Lambda rotation function, meeting both the centralized management and automatic rotation requirements.
- Why A is wrong: Storing credentials in S3, even encrypted with SSE-KMS, does not provide automatic credential rotation. The team would still need to build and maintain custom rotation logic.
- Why B is wrong: Parameter Store SecureString encrypts values at rest using KMS, but it does not provide built-in automatic rotation. The team would need to build custom rotation logic on top of Parameter Store, adding unnecessary complexity.
- Why D is wrong: Encrypting Lambda environment variables with a customer-managed KMS key protects them at rest, but does not address centralized management or automatic rotation. The credentials remain static and tied to the specific Lambda function.
Question 18 — Domain 4: Data Security and Governance
A healthcare company ingests patient records into an S3 data lake. Before downstream analytics teams access this data, a data engineer must detect and mask personally identifiable information (PII) such as Social Security numbers and patient names. Which approach meets this requirement?
- Use the AWS Glue detect_pii_entities transform to identify PII columns, then apply hashing or redaction before writing to the target — Correct answer
- Export data to a local machine, run a custom regex script to find PII, then re-upload the sanitized data to S3
- Enable S3 server-side encryption on the target bucket, which automatically masks all PII values during upload
- Use Amazon Athena views to hide PII columns, which permanently removes PII from the underlying data files
Explanation:
- Why correct: AWS Glue provides built-in PII detection through the detect_pii_entities transform, which uses machine learning to identify PII such as SSNs, names, and addresses. After detection, the data engineer can apply hashing, redaction, or replacement before writing the transformed data to the target location. This is a scalable, serverless approach that keeps data within AWS.
- Why B is wrong: Exporting data to a local machine to process PII violates data residency best practices, introduces security risk by moving sensitive data outside the cloud, and does not scale for large datasets.
- Why C is wrong: S3 server-side encryption (SSE) protects data at rest by encrypting the entire object. It does not inspect or mask individual PII values within the data. Encryption and masking are different controls.
- Why D is wrong: Athena views can restrict which columns users see in query results, but they do not remove or mask PII in the underlying S3 data files. Other tools or direct S3 access could still expose the raw PII.
Question 19 — Domain 4: Data Security and Governance
A company must retain all AWS API activity logs for 7 years to satisfy regulatory compliance. Currently, CloudTrail event history only provides 90 days of lookup. What should the data engineer configure to meet the 7-year requirement at the lowest cost?
- Increase the CloudTrail event history retention period to 7 years
- Create a CloudTrail trail that delivers logs to an S3 bucket with a lifecycle policy for Glacier archival — Correct answer
- Export CloudTrail events to Amazon DynamoDB with TTL disabled
- Enable CloudTrail Insights to extend the retention period
Explanation:
- Why B is correct: Creating a CloudTrail trail delivers log files to an S3 bucket, where S3 lifecycle policies can transition older logs to S3 Glacier or Glacier Deep Archive for low-cost long-term archival. This approach supports any retention duration and is the most cost-effective way to store CloudTrail logs for years.
- Why A is wrong: CloudTrail event history retention is fixed at 90 days and cannot be changed or extended. It is a read-only lookup feature, not a configurable retention setting.
- Why C is wrong: DynamoDB is not a standard or cost-effective destination for CloudTrail logs. CloudTrail natively integrates with S3, and DynamoDB pricing (per read/write capacity) would be significantly more expensive for storing years of log data.
- Why D is wrong: CloudTrail Insights analyzes management events to detect unusual API activity patterns (e.g., spikes in API calls). It does not extend log retention or store historical events.
Question 20 — Domain 4: Data Security and Governance
A data engineering team manages a centralized data lake in Amazon S3 with AWS Lake Formation. Multiple business units across different AWS accounts need access to specific databases and tables based on their department. The team wants to grant fine-grained, column-level permissions without sharing IAM credentials across accounts. Which approach should the data engineer use?
- Configure S3 bucket policies with cross-account access and use IAM roles in each account to restrict access to specific prefixes
- Use Lake Formation cross-account sharing to grant column-level permissions to specific AWS accounts and let receiving admins delegate access — Correct answer
- Share the AWS Glue Data Catalog databases using AWS Resource Access Manager and rely on IAM policies for column-level access
- Replicate the data to each business unit's own S3 bucket and apply Lake Formation permissions locally in each account
Explanation:
- Why B is correct: AWS Lake Formation cross-account data sharing allows you to grant table-level and column-level permissions to external AWS accounts using the Lake Formation permission model. You grant permissions to the target account's principal (account ID or organization), and the receiving account's Lake Formation admin can then delegate access to specific IAM users or roles. This avoids sharing IAM credentials and provides fine-grained access control.
- Why A is wrong: S3 bucket policies with cross-account access grant access at the object/prefix level, not at the column level. They also bypass the Lake Formation permission model, making it harder to enforce fine-grained governance.
- Why C is wrong: AWS RAM (Resource Access Manager) can share Lake Formation resources, but it works alongside Lake Formation permissions — you still configure the actual column-level permissions through Lake Formation grants. RAM alone does not provide the column-level access control described.
- Why D is wrong: Replicating data to each account's S3 bucket creates data duplication, increases storage costs, and makes governance harder because you now have multiple copies of the data to secure and keep synchronized.
Question 21 — Domain 4: Data Security and Governance
A company has two data engineering teams — one focused on real-time streaming pipelines and the other on batch ETL jobs. Both teams use SageMaker Unified Studio and need access to shared compute resources but must be restricted to their own datasets and notebooks. A data platform administrator needs to set up access controls that balance collaboration with isolation. What is the BEST approach?
- Create a single SageMaker Unified Studio domain for the entire company and assign all data engineers to one project with full access to all resources
- Create a domain for the data platform, use domain units to separate the teams logically, and create separate projects for each team's datasets and notebooks — Correct answer
- Create separate SageMaker Unified Studio domains for each team and use cross-domain sharing to enable collaboration
- Create one project per data engineer within a single domain unit to ensure individual-level access control
Explanation:
- Why correct: The three-tier hierarchy of SageMaker Unified Studio — domains, domain units, and projects — maps directly to this scenario. A domain provides centralized authentication and governance for the data platform. Domain units logically group the two teams (real-time and batch), enabling separate permission boundaries. Projects within each domain unit control access to specific resources like datasets, notebooks, and models, ensuring each team only accesses what they need.
- Why A is wrong: Placing all data engineers in one project with full access violates the principle of least privilege. Without domain units or separate projects, there is no way to restrict the real-time team from accessing batch resources and vice versa.
- Why C is wrong: Creating separate domains per team is over-engineering the solution. Domains are the top-level organizational boundary and are meant for broader organizational separation (e.g., different business units or environments). Within a single data platform, domain units and projects provide sufficient isolation without the overhead of managing multiple domains and cross-domain sharing.
- Why D is wrong: Creating one project per individual data engineer is overly granular and increases management overhead significantly. Projects are designed to group related resources for team-level collaboration, not to serve as per-user permission boundaries.
Question 22 — Domain 1: Data Ingestion and Transformation
A company ingests clickstream data into an Amazon Kinesis Data Stream. Five downstream applications need to process the same stream independently and in near-real time. The team is experiencing read throttling. Which solution addresses this with the LEAST operational overhead?
- Use Amazon Data Firehose to deliver the stream to each application separately
- Use Amazon MSK to re-ingest the data and create separate consumer groups
- Enable enhanced fan-out on the Kinesis Data Stream so each consumer gets dedicated throughput — Correct answer
- Use the same Kinesis Data Stream without enhanced fan-out and increase the number of shards
Explanation:
- Why correct: Amazon Kinesis Data Streams with enhanced fan-out provides dedicated throughput of 2 MB/s per consumer per shard using a push model (SubscribeToShard via HTTP/2). This means each of the five downstream applications gets its own independent read throughput, eliminating contention. Without enhanced fan-out, all consumers share a single 2 MB/s per shard read limit using GetRecords polling, which would throttle five consumers competing for the same data.
- Why A is wrong: Amazon Data Firehose is a delivery service that writes streaming data to destinations like S3, Redshift, or OpenSearch. It does not support multiple independent consumer applications reading from the same stream—it delivers to configured destinations, not to arbitrary consumer apps.
- Why B is wrong: Amazon MSK (Managed Streaming for Apache Kafka) supports multiple consumer groups natively via Kafka's consumer group protocol. However, the scenario specifies the data already arrives in a Kinesis Data Stream, so re-architecting to MSK adds unnecessary migration complexity. Enhanced fan-out solves the problem within the existing Kinesis architecture.
- Why D is wrong: While a single Kinesis Data Stream can support multiple consumers, without enhanced fan-out all consumers share the 2 MB/s per shard read limit. With five consumers, each would effectively get only ~400 KB/s per shard, causing throttling and increased latency. Increasing shards raises total throughput but does not eliminate per-shard contention among consumers, and adds resharding operational overhead.
Question 23 — Domain 2: Data Store Management
A retail company stores shopping cart data in Amazon DynamoDB. During flash sales, the table experiences sudden traffic spikes of 10x normal load lasting 15-30 minutes, followed by hours of minimal activity. The team currently uses provisioned capacity mode and is experiencing throttling during sales events. What is the MOST cost-effective solution?
- Keep provisioned capacity mode and configure Auto Scaling with a target utilization of 70%
- Switch to on-demand capacity mode to automatically handle unpredictable spikes without capacity planning — Correct answer
- Keep provisioned capacity mode and manually increase WCU/RCU before each flash sale event
- Enable DynamoDB Accelerator (DAX) to cache reads and reduce the load on the base table
Explanation:
- Why correct: On-demand capacity mode is ideal for unpredictable, spiky workloads. It instantly accommodates up to double the previous peak traffic and scales automatically with no capacity planning required. For workloads with long idle periods and short intense bursts, on-demand is typically more cost-effective than provisioned capacity.
- Why A is wrong: DynamoDB Auto Scaling reacts to sustained traffic changes by adjusting provisioned capacity via CloudWatch alarms, but it takes several minutes to scale up. Flash sale spikes that arrive suddenly (10x in seconds) would still cause throttling before Auto Scaling can respond.
- Why C is wrong: Manually increasing capacity before events requires operational overhead, precise timing knowledge, and human intervention. It does not scale down automatically afterward, leading to wasted cost during idle periods.
- Why D is wrong: DAX caches read operations, but shopping cart workloads are write-heavy (adding/updating items). DAX would not help with write throttling, which is the primary concern during flash sales.
Question 24 — Domain 3: Data Operations and Support
A data pipeline reads messages from an Amazon SQS standard queue and writes transformed records to Amazon Redshift. Occasionally, malformed messages cause the Lambda consumer to fail repeatedly. The team wants to isolate these poison-pill messages without losing them, while allowing healthy messages to continue processing. What should the team configure?
- Increase the SQS visibility timeout to 24 hours so failed messages are retried less frequently
- Configure a dead-letter queue (DLQ) on the source SQS queue with a maxReceiveCount of 3, and set up a CloudWatch alarm on the DLQ ApproximateNumberOfMessagesVisible metric — Correct answer
- Enable SQS long polling with a 20-second wait time to reduce the rate of failed processing attempts
- Delete the failed messages programmatically in the Lambda function's catch block to prevent reprocessing
Explanation:
- Why correct: A dead-letter queue (DLQ) automatically moves messages that exceed the maxReceiveCount threshold to a separate queue, isolating poison-pill messages while allowing healthy messages to continue flowing. Setting maxReceiveCount to 3 means a message is moved to the DLQ after 3 failed processing attempts. Adding a CloudWatch alarm on the DLQ ensures the team is notified when failures occur, enabling investigation.
- Why A is wrong: Increasing the visibility timeout only delays retries — it does not isolate or remove the problematic messages. The malformed messages would still eventually be retried and fail, blocking processing capacity.
- Why C is wrong: Long polling controls how SQS waits for messages when the queue is empty — it reduces empty-response API calls and cost, but has no effect on handling failed or malformed messages.
- Why D is wrong: Programmatically deleting failed messages discards them permanently, violating the requirement to not lose them. A DLQ preserves them for later analysis and reprocessing after the root cause is fixed.
Question 25 — Domain 1: Data Ingestion and Transformation
A data pipeline runs an AWS Lambda function that transforms JSON files uploaded to S3. During peak hours, hundreds of files arrive per minute, and the team observes throttling errors (TooManyRequestsException). The function takes an average of 3 seconds per invocation. Which configuration change BEST resolves the throttling while keeping costs predictable?
- Increase the function timeout to 60 seconds
- Enable provisioned concurrency with 50 pre-initialized environments
- Reduce the S3 event notification batch size to process fewer files per invocation
- Set reserved concurrency on the function to guarantee a dedicated share of the account concurrency pool — Correct answer
Explanation:
- Why D is correct: Reserved concurrency guarantees a fixed number of concurrent Lambda executions for this function, preventing it from being throttled by other functions consuming the account's concurrency pool. It also caps the function's concurrency, keeping costs predictable. This directly addresses the throttling scenario.
- Why A is wrong: Increasing the function timeout from 3 seconds to 60 seconds does not affect concurrency. Timeout controls how long a single invocation can run, not how many invocations run in parallel. The throttling is caused by too many concurrent invocations, not by invocations timing out.
- Why B is wrong: Provisioned concurrency pre-initializes execution environments to eliminate cold starts and does reserve capacity from the account pool. However, it is designed primarily for cold-start elimination, not throttling protection, and it charges for every pre-initialized environment whether invoked or not. The scenario describes a throttling problem with no mention of cold-start latency. Reserved concurrency is free, purpose-built for guaranteeing concurrency capacity, and caps usage to keep costs predictable — making it the better fit.
- Why C is wrong: Reducing the S3 event notification batch size would increase the number of Lambda invocations (more invocations with fewer files each), which would worsen the throttling problem rather than solve it.
Question 26 — Domain 2: Data Store Management
A company wants to build a Retrieval Augmented Generation (RAG) application using internal PDF documents stored in Amazon S3. They need the documents to be automatically chunked, converted into vector embeddings, and stored for semantic search. Which AWS service provides a fully managed pipeline for this?
- Amazon Kendra with an S3 data source connector
- Amazon Bedrock Knowledge Bases — Correct answer
- Amazon OpenSearch Service with a custom ingestion Lambda
- Amazon Comprehend with topic modeling
Explanation:
- Why correct: Amazon Bedrock Knowledge Bases provides a fully managed RAG pipeline that automatically ingests documents from S3, chunks them (using fixed-size, semantic, or hierarchical strategies), converts text into vector embeddings, and stores them in a supported vector database (such as Amazon OpenSearch Serverless or Aurora PostgreSQL). It also exposes Retrieve and RetrieveAndGenerate APIs for semantic search.
- Why A is wrong: Amazon Kendra is an enterprise search service that supports natural language queries but does not produce vector embeddings or integrate directly with foundation models for RAG generation in the same managed pipeline.
- Why C is wrong: OpenSearch Service can store vectors, but this approach requires building a custom ingestion pipeline with Lambda for chunking and embedding—it is not a fully managed solution.
- Why D is wrong: Amazon Comprehend is an NLP service for text analysis (sentiment, entities, PII detection). It does not perform vectorization or support RAG workflows.
Question 27 — Domain 4: Data Security and Governance
A security team needs to investigate which IAM principals accessed sensitive data in an Amazon S3 bucket containing personally identifiable information (PII) over the past 30 days. They need details including the caller identity, source IP address, and exact timestamp of each access. Which AWS service should the team use?
- AWS CloudTrail with S3 data event logging enabled — Correct answer
- Amazon CloudWatch Logs with S3 bucket metrics
- AWS Config with S3 bucket configuration recording
- Amazon S3 server access logging sent to a separate bucket
Explanation:
- Why correct (A): AWS CloudTrail records all API calls made in an AWS account, including S3 data-level events such as GetObject and PutObject. By enabling data event logging for the S3 bucket, the security team can see exactly who accessed which objects, from what IP address, and when. This provides the audit trail needed for the investigation.
- Why B is wrong: CloudWatch Logs can store application-level logs if configured, but it does not automatically capture S3 API calls. CloudWatch monitors metrics and operational data, not API-level access patterns, unless logs are explicitly sent to it from another source.
- Why C is wrong: AWS Config tracks resource configuration changes over time (e.g., bucket policy modifications, encryption settings) but does not record individual data access events like GetObject calls. Config answers 'what changed about the resource' not 'who accessed the data.'
- Why D is wrong: S3 server access logging records requests made to an S3 bucket in a best-effort manner and writes logs to another S3 bucket, but it is not an AWS Management & Governance service. Additionally, server access logs can be delayed and are less structured than CloudTrail logs, making them less suitable for security investigations requiring precise, timely audit data.
Question 28 — Domain 2: Data Store Management
A company needs to migrate a Microsoft SQL Server database to Amazon Aurora PostgreSQL. The source and target database engines are different. Which combination of tools should the data engineer use to convert the schema and migrate the data?
- Use AWS DMS alone — it automatically converts schemas between different database engines
- Use AWS SCT alone — it converts schemas and migrates data in a single step
- Use AWS SCT to convert the schema, then use AWS DMS to migrate the data — Correct answer
- Use AWS DMS for data migration and AWS Backup for schema conversion
Explanation:
- Why correct (C): When performing a heterogeneous migration (different source and target database engines), you need AWS SCT to convert the schema, stored procedures, and application code from the source engine format to the target engine format. AWS DMS then handles the actual data migration. SCT generates an assessment report highlighting conversion issues, and DMS moves the data with optional CDC for minimal downtime.
- Why A is wrong: AWS DMS alone handles data migration but does not convert schemas between different database engines. It can migrate data between heterogeneous engines, but the schema objects (stored procedures, views, triggers) require SCT for conversion.
- Why B is wrong: AWS SCT converts schemas but does not perform the actual data migration. You need DMS to move the data from source to target.
- Why D is wrong: AWS Database Migration Service and AWS Backup serve different purposes. AWS Backup creates backups of AWS resources — it cannot convert schemas between different database engines or migrate on-premises databases.
Question 29 — Domain 4: Data Security and Governance
A data engineering team deploys an Amazon Redshift cluster in a private subnet. The team's BI application runs on EC2 instances in a separate subnet within the same VPC. Only the BI application should be allowed to connect to Redshift on port 5439. No other resources should have access. What is the MOST secure way to configure this?
- Add a subnet-level network ACL rule that allows inbound traffic on port 5439 from 0.0.0.0/0
- Create a security group for the Redshift cluster that allows inbound traffic on port 5439 only from the BI application's security group ID — Correct answer
- Assign an IAM role to the Redshift cluster that restricts connections to the BI application's IAM role ARN
- Configure a VPC endpoint policy that permits only the BI application's subnet CIDR to reach Redshift
Explanation:
- Why B is correct: Security groups are stateful firewalls that operate at the network interface level. By referencing the BI application's security group ID as the inbound source, only instances attached to that specific security group can connect to Redshift on port 5439. This follows the principle of least privilege at the network layer and automatically allows return traffic (stateful).
- Why A is wrong: A NACL rule allowing 0.0.0.0/0 on port 5439 opens the port to every resource in the VPC (and beyond if routing allows), violating the requirement that only the BI application should connect. NACLs are also stateless, so you would need an additional outbound rule for return traffic.
- Why C is wrong: IAM roles control API-level authorization (e.g., who can call Redshift APIs like CreateCluster or GetClusterCredentials). They do not control network-level TCP connections on port 5439. Network access and IAM access are separate layers.
- Why D is wrong: VPC endpoints provide private connectivity to AWS services but are not used to restrict which resources within a VPC can connect to a Redshift cluster. Redshift in a VPC is accessed directly via its ENI, not through a VPC endpoint.
Question 30 — Mixed Review (All Domains)
A data engineering team queries 10 TB of CSV log files stored in Amazon S3 using Amazon Athena. Most queries filter by date and select only 3 of 50 columns. The team's monthly Athena bill is growing rapidly. Which approach will MOST effectively reduce Athena query costs?
- Convert the CSV files to Apache Parquet format, partition the data by date in S3, and update the Athena table to use the partitioned Parquet data — Correct answer
- Enable Amazon Athena Provisioned Capacity reservations to get a discounted per-query rate for the team
- Create an AWS Glue ETL job to load the CSV data into an Amazon RDS MySQL instance and query from RDS instead
- Enable S3 Transfer Acceleration on the bucket and increase the Athena query timeout to process the CSV files faster
Explanation:
- Why correct (A): Athena charges based on the amount of data scanned per query. Converting CSV (row-based) to Parquet (columnar) dramatically reduces scanned data because Athena only reads the columns needed by the query. Partitioning by date means queries filtered by date only scan relevant S3 prefixes. Together, these two changes can reduce costs by 90% or more.
- Why B is wrong: Athena Provisioned Capacity is for consistent query performance, not cost reduction for ad hoc queries on large datasets. It requires committing to reserved capacity (DPUs) and is cost-effective only for sustained high-concurrency workloads, not for reducing per-query scan costs.
- Why C is wrong: Moving data to RDS would work for small datasets but is not cost-effective or performant for 10 TB of log data. RDS has storage limits, is not designed for analytical queries over massive datasets, and introduces ongoing instance costs that would far exceed Athena's pay-per-scan model.
- Why D is wrong: S3 Transfer Acceleration speeds up uploads to S3 from distant locations — it has no effect on Athena query performance or cost. Athena costs are driven by data scanned, not query duration or data transfer speed.
JavaScript is required to use this application.
Please enable JavaScript in your browser to access the full NestedCerts platform.
Contact: support@nestedcerts.com