AWS Certified Data Engineer Associate DEA-C01 (DEA-C01) — Questions 976–1050

Why this answer

How to eliminate wrong answers

Option A is wrong because bucket policies are attached to the S3 bucket, not to IAM roles; the policy is already configured on the bucket. Option B is wrong because cross-account access is possible with proper permissions, and the question does not indicate a different account; the failure is due to the tag condition, not account mismatch. Option D is wrong because the question explicitly states the IAM role has s3:GetObject permission, so the failure is not due to missing permission.

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because taking a snapshot and restoring it captures only a point-in-time copy, requiring the source database to be offline or read-only during the snapshot, causing downtime. Option B is wrong because AWS DMS full load only transfers the current data once, without capturing ongoing changes, so any writes during the migration are lost and downtime is needed to stop writes before cutover. Option C is wrong because mongodump and mongorestore are offline tools that require the source MongoDB to stop accepting writes during the export, resulting in significant downtime.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because enabling CloudWatch Logs captures error logs but does not store the actual failed records; it only provides visibility into errors without preventing data loss. Option C is wrong because Kinesis Data Firehose does not natively support sending failed records to an SQS queue; the Lambda function would need custom code to write to SQS, and this does not address the timeout issue. Option D is wrong because storing failed records in S3 before processing would require modifying the Lambda function to write to S3 first, which adds complexity and does not resolve the timeout; the records are already in the Firehose stream and need to be processed or redirected after failure.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because AWS Glue ETL jobs with JDBC connections run batch queries that pull full table snapshots or large result sets, which can cause significant performance degradation on the source MySQL database and cannot achieve near real-time latency. Option C is wrong because Amazon RDS for MySQL with a read replica is a database migration or read scaling solution, not a data ingestion service to S3; it does not natively stream data to S3 without additional tooling. Option D is wrong because AWS Schema Conversion Tool (SCT) is designed for converting database schemas between different database engines (e.g., Oracle to Aurora), not for ingesting data into S3.

Why this answer

How to eliminate wrong answers

Option A is wrong because automated backups capture point-in-time snapshots of the entire database, not a continuous, row-level change stream with before-and-after images; exporting logs to S3 provides error logs or slow query logs, not row-level audit trails. Option B is wrong because Enhanced Monitoring collects OS-level metrics (CPU, memory, disk I/O) and publishes them to CloudWatch Logs, not database row changes. Option D is wrong because Multi-AZ deployment provides high availability via synchronous standby replication, and read replicas serve read traffic; neither logs individual row modifications or provides before-and-after images.

Why this answer

How to eliminate wrong answers

Option A is wrong because using all on-demand instances eliminates cost savings from spot instances and does not address the transient cluster design; a long-running cluster increases costs unnecessarily. Option C is wrong because storing intermediate data in S3 via EMRFS introduces higher latency and cost for transient data, and EMRFS does not natively support checkpointing for HDFS-dependent intermediate data. Option D is wrong because increasing HDFS replication to 5 consumes more storage and network bandwidth, and using only spot instances increases the risk of frequent failures without on-demand fallback, leading to higher recomputation costs.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because increasing AWS Glue job timeout and DPUs improves processing capacity but does not prevent data loss during ingestion spikes; data can still be lost if Firehose delivery fails before Glue runs. Option C is wrong because scaling Redshift nodes handles downstream load but does not protect against data loss at the ingestion layer; data may be dropped before it reaches Redshift. Option D is wrong because S3 bucket size limit and versioning are irrelevant to data loss prevention during spikes; S3 has no practical size limit, and versioning protects against accidental deletion, not ingestion failures.

Why this answer

How to eliminate wrong answers

Option A is wrong because S3 Intelligent-Tiering is designed for data with unknown or changing access patterns, automatically moving data between tiers based on usage, which incurs monitoring and automation costs that are unnecessary for rarely accessed archival data. Option B is wrong because S3 Glacier Flexible Retrieval offers retrieval times from minutes to hours (typically 1-5 minutes for expedited, 3-5 hours for standard), but its storage cost is higher than Glacier Deep Archive, making it less cost-effective for data that only needs retrieval within 12 hours. Option C is wrong because S3 Standard is designed for frequently accessed data with millisecond retrieval times, and its storage cost is significantly higher than archival classes, making it prohibitively expensive for data that is rarely accessed and retained for 7 years.

Why this answer

How to eliminate wrong answers

Option A is wrong because Amazon S3 Glacier Flexible Retrieval is optimized for archival data where retrieval times range from minutes to hours, but it incurs higher retrieval costs and is not designed for frequent or rapid access within minutes. Option B is wrong because Amazon S3 Glacier Deep Archive is the lowest-cost storage class for long-term archival, but retrieval times are typically 12 hours or more, far exceeding the 'within minutes' requirement. Option D is wrong because Amazon S3 Standard is designed for frequently accessed data with high durability and low latency, but it is more expensive than S3 Standard-IA for infrequently accessed data, making it less cost-effective for this use case.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because S3 One Zone-IA is not durable enough for a data lake (single AZ, 99.5% availability) and does not provide the lowest cost for the first 30 days of frequent access; it also skips the 90-day rare access period. Option B is wrong because transitioning directly to S3 Glacier Flexible Retrieval after 90 days ignores the first 30 days of frequent access, incurring higher costs during that period, and does not archive after 1 year. Option C is wrong because S3 Glacier Instant Retrieval is designed for data accessed once a quarter, not for frequent access in the first 30 days, and expiring after 365 days deletes data instead of archiving it, failing the requirement to archive after 1 year.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because client-side encryption requires the application to manage encryption keys and perform encryption before upload, adding significant operational effort and complexity, which contradicts the 'minimal effort' requirement. Option C is wrong because S3 Versioning and MFA Delete provide data protection against accidental deletion and overwrites, but they do not encrypt objects at rest. Option D is wrong because a bucket policy to deny PutObject without encryption only enforces encryption on upload but does not encrypt existing objects or objects uploaded without the required headers; it also requires additional policy management and does not automatically encrypt data at rest.

Why this answer

How to eliminate wrong answers

Option B is wrong because the policy does allow `s3:PutObject` on the bucket; the issue is the condition key, not the action. Option C is wrong because S3 is a global service and bucket operations are not restricted by the user's AWS region; the region is specified in the bucket ARN, not the user's location. Option D is wrong because the resource ARN `arn:aws:s3:::example-bucket/*` correctly includes all objects within the bucket, which is the standard way to grant object-level permissions; the bucket itself is not needed for object uploads.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because switching to on-demand mode would not resolve the hot partition issue; it only eliminates the need to manage provisioned capacity but does not fix the underlying data skew that causes throttling on the GSI. Option B is wrong because DynamoDB Accelerator (DAX) caches read results but does not address the root cause of throttling on the GSI due to uneven partition access; it would only mask the symptom for cached queries. Option C is wrong because increasing provisioned read capacity on the main table does not affect the GSI's separate capacity; the throttling is occurring on the GSI, not the base table, and the consumed read capacity on the main table is already well below its limit.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because AWS SCT is used for schema conversion (e.g., from Oracle to PostgreSQL), but the source is already PostgreSQL, so no schema conversion is needed; copying data via S3 adds unnecessary complexity and does not provide ongoing replication for minimal downtime. Option B is wrong because Aurora read replicas can only be created from an existing Aurora DB instance, not from an on-premises PostgreSQL database; native PostgreSQL replication (e.g., streaming replication) is not supported across an on-premises-to-Aurora boundary without a custom intermediary. Option D is wrong because pg_dump/pg_restore is a logical backup and restore method that requires the source database to be offline or in a read-only state during the dump to ensure consistency, resulting in significant downtime for a 2 TB database.

Why this answer

How to eliminate wrong answers

Option A is wrong because S3 Intelligent-Tiering incurs a monthly monitoring and automation fee per object, which over 7 years would be more expensive than a lifecycle-based approach, especially for rarely accessed data. Option B is wrong because storing all data in S3 Standard for 7 years is the most expensive option, as it does not take advantage of lower-cost tiers for data that is rarely accessed after 30 days. Option C is wrong because S3 One Zone-IA does not provide the durability or availability needed for long-term compliance (data is stored in a single Availability Zone) and is more expensive than Glacier Deep Archive for data accessed rarely over 7 years.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because using Amazon SQS to buffer write requests introduces additional latency for processing batches, which contradicts the requirement to minimize latency during the spike, and it adds complexity and cost for queue management. Option B is wrong because disabling auto scaling and setting write capacity to the peak observed value is wasteful and costly, as it permanently allocates high capacity that is only needed during spikes, and it requires manual intervention to adjust. Option D is wrong because DynamoDB Accelerator (DAX) is an in-memory cache for read operations, not writes; it does not reduce write throttling or ProvisionedThroughputExceeded exceptions, and it adds cost without addressing the write capacity issue.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because AWS Data Pipeline is a batch-oriented orchestration service, not designed for near-real-time streaming ingestion; it would introduce significant latency and require periodic polling, failing the near-real-time requirement. Option C is wrong because Amazon MSK (Managed Streaming for Apache Kafka) introduces unnecessary operational overhead and cost for this use case, as it requires managing Kafka clusters, brokers, and the Kafka Connect S3 sink, while Kinesis Data Firehose provides a simpler, fully managed, and more cost-effective direct S3 delivery. Option D is wrong because SQS FIFO queues are designed for exactly-once processing and low throughput (300 transactions per second by default), making them unsuitable for 10,000 messages per second; additionally, Lambda consumers would incur high costs due to the large number of invocations and lack built-in batching and compression for S3 writes.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because AWS CloudHSM provides hardware-based key storage but does not directly integrate with DynamoDB for encryption at rest; DynamoDB only supports KMS keys, not CloudHSM-generated keys imported via the HSM. Option C is wrong because DynamoDB does not use S3-managed keys; default encryption in DynamoDB uses AWS-owned keys or AWS-managed keys, not S3-managed keys, and S3-managed keys are specific to Amazon S3. Option D is wrong because AWS Certificate Manager and TLS are used for encryption in transit, not encryption at rest, and do not address the requirement for encrypting stored data with a customer-managed key.

Why this answer

How to eliminate wrong answers

Option A is wrong because on-demand capacity does not use auto-scaling; it automatically adjusts capacity without needing auto-scaling enabled. Option B is wrong because on-demand capacity is designed to handle sudden spikes without manual provisioning, so insufficient capacity is not the issue—the problem is partition-level limits. Option D is wrong because the sort key does not affect write throughput distribution; partition key selection determines write distribution, and a sort key is irrelevant to throttling caused by hot partitions.

Why this answer

How to eliminate wrong answers

Option A is wrong because scheduling an AWS Glue job every 5 minutes introduces unnecessary startup overhead and may not achieve the lowest latency, as Glue jobs have a cold start time and are better suited for larger batch processing. Option C is wrong because Redshift Spectrum queries data directly from S3 without loading it into Redshift tables, which does not make the data available in Redshift for fast, indexed queries and can incur higher latency for repeated access. Option D is wrong because Amazon Kinesis Data Firehose cannot directly ingest data from S3; it is designed to stream data into S3 or Redshift from producers like Kinesis Data Streams, not to read existing S3 files.

Why this answer

How to eliminate wrong answers

Option B (Amazon DynamoDB) is wrong because it is a NoSQL key-value and document database optimized for low-latency, high-throughput transactional workloads, not for ad-hoc SQL querying of semi-structured logs; it lacks native SQL support and would require expensive scanning of large datasets. Option C (Amazon RDS for MySQL) is wrong because it requires you to predefine a schema, load the JSON logs into relational tables, and pay for provisioned compute and storage even when idle, making it less cost-effective for sporadic ad-hoc queries compared to Athena's serverless model. Option D (Amazon Kinesis Data Analytics) is wrong because it is designed for real-time stream processing and analytics on streaming data using SQL, not for querying stored JSON logs in S3; it would require continuous ingestion and incurs ongoing costs regardless of query frequency.

Why this answer

How to eliminate wrong answers

Option A is wrong because ElastiCache caches query results, not database endpoints; it does not address the DNS resolution or endpoint caching issue during a failover. Option B is wrong because promoting a read replica creates a new standalone instance with a different endpoint, requiring application reconfiguration and causing longer disruption than Multi-AZ automatic failover. Option C is wrong because private IP addresses can change after a failover (the new primary may have a different IP), and using IPs bypasses DNS-based failover mechanisms, leading to connectivity failures.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because S3 Same-Region Replication (SRR) replicates objects within the same AWS Region, not across regions, so it does not provide disaster recovery across geographic boundaries. Option C is wrong because S3 Transfer Acceleration speeds up uploads over long distances using AWS edge locations but does not replicate objects to another bucket; it only improves transfer performance for clients. Option D is wrong because S3 Batch Operations is used for bulk actions like copying existing objects or tagging, but it is a one-time operation, not an automatic, ongoing replication configuration for new objects.

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because S3 Transfer Acceleration is for speeding up uploads over long distances, not for streaming ingestion, and S3 Event Notifications have at-least-once delivery with potential latency, not providing immediate durable storage upon arrival. Option B is wrong because Kinesis Data Firehose batches data before delivering to S3, introducing latency and not providing true near-real-time ingestion; it also does not offer the same level of automatic scaling for unpredictable spikes as KDS. Option C is wrong because SQS is a message queue with no native streaming shard model, and using an Auto Scaling group of EC2 instances adds significant operational overhead (managing instances, scaling policies, polling logic) and does not guarantee data durability as soon as it arrives (messages are stored but processing is decoupled).

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a throttling global secondary index (GSI) would cause its own ProvisionedThroughputExceededException, but the question states the write requests fail directly on the table, and a GSI throttling would typically manifest as errors on writes that affect the index, not necessarily all table writes. Option C is wrong because the question explicitly states that the maximum capacity is high enough, so insufficient maximum capacity is not the cause. Option D is wrong because the auto scaling policy is configured with a target utilization of 70% and a high enough maximum capacity, which is a standard and correct configuration; the issue is the inherent lag in auto scaling's response to sudden spikes, not a misconfiguration.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because reducing item size does not increase the number of writes per second; it only reduces WCU consumption per write, but the core issue is insufficient provisioned capacity, not item size. Option B is wrong because global tables replicate data across regions for disaster recovery and low-latency reads, but they do not increase write throughput for a single table; writes are still subject to the table's WCU limit in each region. Option D is wrong because DynamoDB Accelerator (DAX) is an in-memory cache for reads only; it does not offload or accelerate write operations, which still go directly to the DynamoDB table.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because Amazon S3 access points and VPC endpoints control network-level access and simplify bucket management, but they do not provide the required logging of data access for auditing. Option C is wrong because Amazon Macie discovers and classifies PII, and S3 Object Lock prevents deletion or overwriting, but neither service enforces access control or logs data access events. Option D is wrong because AWS KMS encrypts data at rest, which protects confidentiality but does not control who can access the data, and while AWS CloudTrail logs API calls, it does not log data events by default; without enabling data event logging, object-level access (e.g., reading a file) is not recorded.

Why this answer

How to eliminate wrong answers

Option A is wrong because the Deny statement in the policy only blocks decrypt requests that do not include the encryption context 'Project=Alpha', not all decrypt requests; the error is likely due to missing key policy permissions, not a blanket Deny. Option B is wrong because the error is about decrypting an object, not generating a data key; kms:GenerateDataKey is used for encryption operations, not decryption, and the Lambda function is trying to decrypt, not encrypt. Option D is wrong because the IAM policy shown in the question includes kms:Decrypt permission (the policy lists kms:Decrypt as an allowed action), so the issue is not a missing IAM permission but rather the KMS key policy not granting the Lambda role decrypt permission.

Why this answer

How to eliminate wrong answers

Option B is wrong because DynamoDB Accelerator (DAX) is an in-memory cache that improves read performance, not write throughput; it does not increase write capacity or reduce write throttling. Option C is wrong because adding a global secondary index (GSI) consumes additional write capacity from the base table and can actually increase write throttling, not resolve it. Option D is wrong because auto scaling for read capacity units does not affect write throttling; write throttling requires adjusting write capacity, not read capacity.

Why this answer

How to eliminate wrong answers

Option A is wrong because SSE-C requires the customer to provide and manage their own encryption keys, and AWS does not support automatic key rotation or logging of key access for customer-provided keys. Option B is wrong because client-side encryption encrypts data before it reaches S3, but storing the master key in AWS Secrets Manager does not provide automatic key rotation every 90 days (Secrets Manager rotation is configurable but not native to KMS key rotation) and does not log key usage in CloudTrail as KMS does. Option C is wrong because SSE-S3 uses S3-managed keys that are rotated annually (not every 90 days) and do not provide granular access logging for key usage.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because the Lambda function reads from the Kinesis Data Stream (requiring `kinesis:GetRecords`, `kinesis:DescribeStream`, etc.), not writes to it, so `kinesis:PutRecord` is irrelevant. Option C is wrong because CloudWatch Logs permissions (`logs:CreateLogGroup`, `logs:CreateLogStream`) are needed for logging but would cause a different error (e.g., 'Unable to create log stream'), not an access denied on Firehose. Option D is wrong because `s3:PutObjectAcl` is not required for Firehose to deliver to S3; Firehose uses `s3:PutObject` with bucket owner full control by default, and ACLs are not involved in this scenario.

Why this answer

How to eliminate wrong answers

Option A is wrong because Amazon SQS FIFO queues guarantee exactly-once processing and strict ordering within a message group, but they are designed for decoupling microservices, not for high-throughput streaming ingestion from thousands of devices; FIFO throughput is limited to 300 transactions per second (with batching) and does not support multiple consumers reading the same stream in real-time. Option C is wrong because Amazon SNS is a pub/sub messaging service that does not provide ordered delivery or durable stream storage; it pushes messages to subscribers like Lambda, but ordering is not guaranteed and messages are not persisted for replay. Option D is wrong because Amazon Kinesis Data Firehose is a near-real-time delivery service that buffers data and writes it to destinations like S3 or Redshift, but it does not support ordered stream processing per device and cannot be consumed by multiple real-time applications directly; it is designed for batch loading, not for real-time ordered stream consumption.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because server-side encryption with KMS is enforced using the `s3:x-amz-server-side-encryption-aws:kms` condition key, not the `s3:x-amz-acl` key. Option B is wrong because object size limits are enforced using the `s3:content-length-range` condition key, not the ACL-related condition shown. Option C is wrong because restricting uploads to a specific AWS account is done using the `aws:SourceAccount` or `aws:SourceArn` condition keys, not the `s3:x-amz-acl` key which controls object ACL permissions.

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because S3 object paths do not include the bucket's region; the path format is s3://bucket-name/key, and region is irrelevant to the path. Option C is wrong because Python version compatibility would cause a syntax error during execution, not a 'Unable to locate script' error, which is a file access issue. Option D is wrong because S3 buckets and Glue jobs can operate across regions as long as the Glue job's IAM role has appropriate cross-region permissions; the error message specifically indicates a missing object, not a region mismatch.

Why this answer

How to eliminate wrong answers

Option A is wrong because changing DISTKEY to region affects data distribution across nodes, not the physical order of rows within a node; it does not help with block pruning for a full table scan. Option B is wrong because an interleaved sort key gives equal weight to all columns, which can cause overhead in maintenance and is less efficient for range-based queries on the leading column compared to a compound sort key. Option D is wrong because changing DISTSTYLE to ALL replicates the entire table to every node, which can improve join performance but does not reduce the number of blocks scanned during a full table scan and may waste storage and memory.

Why this answer

How to eliminate wrong answers

Option A is wrong because global tables replicate data across regions for disaster recovery and low-latency global access, but they do not solve hot partition issues within a single table; they add complexity and cross-region latency. Option C is wrong because increasing read capacity units (RCUs) only increases the provisioned throughput, but if a single partition key (user_id) is hot, the partition-level throughput limit (3,000 RCUs or 1,000 WCUs) still caps performance; more RCUs cannot overcome a single partition's bottleneck. Option D is wrong because changing to eventually consistent reads would reduce latency by sacrificing consistency, but the requirement explicitly states the application performs strongly consistent reads and the code cannot be changed.

Why this answer

How to eliminate wrong answers

Option A is wrong because 'MFADelete' does not require MFA for any modification (e.g., PUT, POST, or COPY operations); it only applies to permanent deletes of specific versions. Option C is wrong because read operations (GET, HEAD) are never subject to MFA requirements under this setting. Option D is wrong because 'MFADelete' is a versioning-specific sub-setting and does not enforce MFA on all bucket operations, only on permanent version deletion.