AWS DEA-C01: Data Operations and Support Practice Questions

glue.driver.aggregate.bytesRead tracks the total bytes read from all data sources since the job started, making it the best first indicator of whether the job is actively reading data and making progress. If this metric is flat or near zero, the job may be stuck at the read phase. glue.driver.ExecutorRunTime measures cumulative executor CPU time, which would still increment even if a job is spinning on a bottleneck, making it less useful for diagnosing a stall. glue.ALL.jvm.heap.usage is relevant for diagnosing out-of-memory conditions but does not directly show whether records are being processed. glue.driver.aggregate.recordsRead is also useful, but bytesRead is the more fundamental I/O signal that indicates whether data is actually being ingested from S3 at the source level.

In Amazon Redshift, deleted and updated rows are not immediately removed from storage — they are marked as logically deleted but remain in blocks until a VACUUM operation is run. VACUUM DELETE ONLY reclaims the disk space occupied by these rows and reclaims storage without the overhead of re-sorting data (unlike a full VACUUM). This directly addresses the high del_rows count and elevated storage utilization. ANALYZE updates column statistics for the query planner, which helps with plan quality but does not reclaim storage space — it is the correct fix for stale statistics but not for space reclamation. A classic resize adds capacity to delay the problem but does not fix the underlying cause of wasted space from un-vacuumed deleted rows. UNLOAD/truncate/reload would achieve the goal but is an extremely disruptive, operationally complex approach that requires downtime or careful coordination, making it far from the best answer when VACUUM is designed precisely for this purpose.

AWS CloudTrail records every API call made against AWS services, including management-plane operations that change Redshift cluster configuration (e.g., ModifyCluster, CreateClusterParameterGroup). This provides a timestamped, immutable audit trail of who made what configuration change and when, which is exactly what auditors need. CloudWatch Logs with connection logging captures database-level connections, not AWS API-level configuration changes. Redshift audit logging records SQL activity inside the database (logins, queries) but does not capture AWS-level configuration changes. AWS Config tracks resource configuration state changes and is complementary, but CloudTrail is the primary source of API call evidence that auditors specifically ask for when verifying unauthorized changes.

Converting to Parquet (a columnar, compressed format) dramatically reduces the amount of data Athena scans per query because only the relevant columns are read and data compresses at high ratios — directly lowering both cost (Athena charges per TB scanned) and query time. Partitioning by date enables Athena's partition pruning: date-range queries skip entire S3 prefixes, further reducing scanned data. These two changes together address the root causes of slow, expensive queries. Query result reuse helps for identical repeated queries but does not improve performance for unique or near-unique queries and does not reduce the underlying data scanned. Increasing concurrency allows more simultaneous queries but does not make individual queries faster or cheaper. Workgroup data limits add governance controls but do not improve performance or reduce cost per query. S3 Transfer Acceleration is designed for upload performance from clients outside AWS and does not accelerate Athena's internal S3 reads.

GetRecords.IteratorAgeMilliseconds measures the age of the last record retrieved from the stream. A high or growing value means consumers are not keeping up with the rate at which data is being written — the consumer is falling behind. The most appropriate immediate remediation is to increase the shard count (reshard), which increases the parallel read capacity available to consumers. Decreasing shards would reduce throughput, making the problem worse. The retention period controls how long records are available, but expiration does not cause a high iterator age — a high age close to the retention window could signal records are at risk of expiration, but the root cause is still consumer lag. Enabling enhanced shard-level metrics is useful for deeper diagnosis but does not itself remediate the lag.