Data Engineer Associate · 22% of the exam

Data Operations and Support: free practice questions

5 sample questions from our 55-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real AWS exam.

1. A company runs an Amazon EMR cluster to process daily batch workloads. The jobs are fault-tolerant and can tolerate interruptions. The cluster runs for approximately four hours each night and uses r5.2xlarge instances for core and task nodes. The team wants to minimize compute costs. Which change will provide the GREATEST cost reduction with the LEAST risk to job completion?

  • A. Replace all core nodes with EC2 Spot Instances to maximize savings across the full cluster.
  • B. Keep core nodes as On-Demand instances and replace task nodes with EC2 Spot Instances, using instance fleets with multiple instance types to reduce interruption risk.✓ Correct
  • C. Switch the cluster to EMR Serverless so that compute is billed only during active task execution.
  • D. Purchase one-year Convertible Reserved Instances for the r5.2xlarge instance type used by the cluster.
Explanation

Task nodes do not store HDFS data, so Spot interruptions on task nodes do not cause data loss or job failure—EMR simply removes the task node and redistributes work. Using instance fleets with multiple instance types increases Spot availability and reduces interruption probability. Keeping core nodes On-Demand protects HDFS data integrity. This combination maximizes cost savings with minimal risk. Option A is incorrect because replacing core nodes with Spot Instances risks data loss if they are interrupted; HDFS blocks on a terminated core node become unavailable. Option C (EMR Serverless) is a valid cost-optimization path but involves architectural change and may not provide greater savings than Spot for a well-defined four-hour batch window. Option D is incorrect because Reserved Instances require a one-year commitment for a nightly four-hour workload; the cluster is idle most of the time, making reservations inefficient compared to Spot.

2. A team manages a data lake on Amazon S3. They use Amazon Athena with the AWS Glue Data Catalog. Recently, analysts report that some Athena queries return stale results even though new data has been loaded into S3. The partitions for the new data were added manually to S3 without running a Glue Crawler. What is the MOST likely cause, and what is the recommended fix?

  • A. Athena caches query results for 24 hours by default; the fix is to disable query result reuse in the Athena workgroup settings.
  • B. The new S3 partitions are not registered in the Glue Data Catalog; the fix is to run ALTER TABLE ADD PARTITION or MSCK REPAIR TABLE in Athena to register the new partitions.✓ Correct
  • C. The Glue Data Catalog has a replication lag of up to one hour when new S3 objects are added; the fix is to wait for the catalog to synchronize automatically.
  • D. Athena uses Amazon S3 Select pushdown to filter data; new partitions are excluded until a Glue crawler re-crawls the full bucket.
Explanation

When data is added to S3 following a Hive-compatible partition structure (e.g., s3://bucket/table/year=2024/month=01/) without notifying the Glue Data Catalog, Athena has no knowledge of those partitions and cannot include them in query results. Running MSCK REPAIR TABLE scans the S3 path and adds all discovered partitions to the catalog, or ALTER TABLE ADD PARTITION can be used for individual partitions. This is the standard fix. Option A is incorrect because Athena query result reuse only caches the output of a specific query; it does not cause missing data from S3—it would only return a cached result if the exact same query was run recently, and the question describes new data being absent, not cached old results. Option C is incorrect because the Glue Data Catalog does not automatically poll S3 for new objects; it only discovers new partitions when a crawler runs or when DDL commands are explicitly executed. Option D is incorrect because S3 Select is a feature for filtering data within objects; it is not related to partition discovery or catalog registration.

3. An operations team is running an AWS Glue streaming ETL job that continuously reads from an Amazon Kinesis Data Stream and writes micro-batch results to Amazon S3. After a code deployment, the team notices the job is consuming 3× more Glue DPUs than before, significantly increasing cost. Which TWO actions should the team take FIRST to diagnose and reduce DPU consumption? (Select TWO)

  • A. Review the Glue job's CloudWatch metrics for glue.driver.memoryUsage and glue.ALL.s3.filesystem.write_duration to identify whether the increase correlates with higher data volume or code inefficiency✓ Correct
  • B. Immediately scale the Kinesis stream's shard count down by 50% to reduce the data volume the Glue job processes
  • C. Enable the Glue job's profiling metrics and compare the executor CPU and shuffle read/write metrics before and after the deployment to isolate the inefficiency introduced by the code change✓ Correct
  • D. Switch the Glue streaming job from a Glue version 3.0 (Spark 3.1) worker to a Glue version 2.0 (Spark 2.4) worker, as older Spark versions use fewer DPUs
  • E. Reduce the Glue streaming job's 'window size' (micro-batch interval) so that each batch processes fewer records, lowering per-batch DPU usage
  • F. Increase the number of DPU workers in the Glue job configuration so that processing finishes faster and the job terminates sooner, reducing total DPU-hours
Explanation

Option A is correct because reviewing CloudWatch metrics for memory usage and write durations immediately after the deployment can reveal whether the new code is causing memory pressure or excessive I/O, both common causes of increased DPU usage. Option C is correct because enabling Glue job profiling and comparing executor-level CPU and shuffle metrics before and after the deployment directly identifies the code path responsible for increased resource consumption. — Option B is wrong: reducing shard count affects stream throughput and could cause data backup; it is a destructive action that does not help diagnose a code-related DPU spike. Option D is wrong: downgrading Glue version does not reduce DPU count and may introduce compatibility issues; Glue DPU usage is governed by worker type and count, not Spark version. Option E is wrong: reducing micro-batch window size causes more frequent but smaller batches; DPU-hours may remain the same or increase due to per-batch overhead. Option F is wrong: adding more DPUs increases DPU-hours (cost), even if wall-clock time decreases — and this does not address the root cause.

4. A data engineer is setting up cost controls for an AWS Glue ETL workload. The Glue job processes a 50 GB daily dataset. The engineer has set the job to use 10 G.2X workers. After profiling, they find the job spends most of its time reading from S3 and writing to S3, with CPU utilization on workers averaging only 15%. What is the MOST cost-effective tuning action?

  • A. Switch to G.1X workers and reduce the number of workers, since the workload is I/O-bound and not computationally intensive✓ Correct
  • B. Increase the number of workers to 20 G.2X workers to finish the job faster and reduce billed duration
  • C. Enable Glue auto-scaling so the job can dynamically add workers during the S3 write phase
  • D. Switch to Glue Flex execution class to run the job on spare capacity at a lower cost
Explanation

Correct: G.2X workers provide 2 vCPUs and 16 GB RAM — double the resources of G.1X. If CPU utilization is only 15%, the workload does not need the extra compute power, and workers are being paid for unused capacity. Switching to G.1X workers (or reducing worker count) reduces the DPU-hour billing without impacting job throughput for an I/O-bound job. Wrong answers: (B) Adding more G.2X workers would reduce wall-clock time but increase total DPU-hours billed, making it more expensive overall. (C) Glue auto-scaling helps right-size dynamic workloads, but the root issue is that the selected worker type is oversized; auto-scaling won't downgrade the worker type. (D) Glue Flex reduces cost for non-time-sensitive jobs by running on spare capacity, which is useful but secondary to fixing the overprovisioned worker type — it doesn't address the wasted compute per worker.

5. A company's data lake uses Amazon Athena to query tables stored in Amazon S3. A data engineer notices that analysts' queries are returning stale results because new S3 data partitions added in the last 24 hours are not visible in Athena. The tables are registered in the AWS Glue Data Catalog. What is the MOST operationally efficient solution to ensure new partitions are visible without requiring schema changes?

  • A. Drop and recreate the Glue Data Catalog table each time new data is added to S3 so that the catalog reflects the current state of all partitions
  • B. Use the Athena DDL statement MSCK REPAIR TABLE to automatically discover and register new partitions, and schedule it as a recurring query using Amazon EventBridge and AWS Lambda✓ Correct
  • C. Instruct analysts to append the partition column filter manually in every query using WHERE clauses referencing the exact S3 prefix so that Athena skips catalog lookup
  • D. Enable AWS Glue partition indexing on the table so that new S3 prefixes are automatically added to the catalog without any additional commands
Explanation

Option B is correct. MSCK REPAIR TABLE is the standard Athena DDL command that scans S3 for partition directories matching the Hive-compatible structure and registers any missing partitions in the Glue Data Catalog. Scheduling it via EventBridge + Lambda provides an automated, recurring solution without structural changes to the table. — Option A (dropping and recreating the table) is highly disruptive, removes all metadata and permissions, and is not operationally efficient. Option C does not actually add partitions to the catalog — Athena still needs partition metadata to plan queries, and WHERE clauses on partition columns only prune already-registered partitions. Option D is incorrect: Glue partition indexing accelerates partition-filtered queries against existing catalog partitions but does not automatically discover new S3 prefixes — that still requires a crawler run or MSCK REPAIR TABLE.

50 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free