CCNA Data Ingestion Transformation Questions

Why this answer

How to eliminate wrong answers

Option A is wrong because Amazon Kinesis Data Firehose does not support a custom HTTP endpoint as a source; it can only ingest data from Kinesis Data Streams, Amazon CloudWatch, AWS IoT, or custom sources via the Kinesis Agent, not directly from an external HTTP API. Option B is wrong because while an AWS Lambda function triggered by CloudWatch Events can poll an HTTP API and write to S3, it requires custom code for HTTP requests, error handling, and data transformation, increasing operational overhead compared to a managed service like AppFlow. Option D is wrong because AWS Glue ETL jobs are designed for batch data transformation and processing, not for direct ingestion from external HTTP APIs; they would require a custom script to fetch the API data, adding complexity and overhead.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because compression reduces the size of data after buffering, but the buffer size limit is based on the uncompressed data; compression does not cause smaller objects to be created before the buffer interval triggers. Option C is wrong because a data transformation Lambda can modify records but does not inherently split records into smaller ones; it processes records as a batch and returns them, and any splitting would be a custom logic not default behavior. Option D is wrong because S3 lifecycle policies manage object transitions or deletions after objects are created; they do not split objects during delivery.

Why this answer

How to eliminate wrong answers

Option A is wrong because Lambda functions can access Kinesis streams across regions as long as the IAM permissions and network connectivity (e.g., VPC endpoints) are correctly configured; region mismatch does not inherently cause access denied. Option B is wrong because the Lambda function is triggered by an S3 event and only needs permission to read from Kinesis; listing S3 buckets is irrelevant to the Kinesis read failure. Option D is wrong because the S3 bucket policy controls access to the S3 bucket itself, not to Kinesis; the error occurs when reading from Kinesis, not when the S3 event triggers the function.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because inserting AWS Glue as an intermediate step between Firehose and Redshift introduces unnecessary complexity, cost (Glue jobs run on a per-DPU-hour basis), and latency, as Glue is designed for batch ETL, not real-time streaming transformations. Option B is wrong because Redshift's COPY command does not perform record-level transformations; it only maps source fields to target columns and can apply basic data format conversions (e.g., JSON parsing via 'jsonpaths'), but it cannot restructure or compute new fields from the JSON payload. Option D is wrong because using the Kinesis Client Library (KCL) on an EC2 instance requires manual provisioning, scaling, and management of the EC2 fleet, which incurs significant operational overhead and cost compared to the serverless Lambda integration within Firehose.

Why this answer

How to eliminate wrong answers

Option A is wrong because AWS Data Pipeline is designed for scheduled data movement and transformation between data stores, not for real-time log ingestion from multiple AWS services; it would require custom pipeline definitions and adds unnecessary complexity. Option B is wrong because AWS Glue is an ETL service for crawling, cataloging, and transforming data, not a log collection or delivery service; it cannot natively ingest logs from CloudTrail, VPC Flow Logs, or ALB logs without first having the data in S3. Option C is wrong because Amazon Kinesis Data Firehose can ingest streaming data but does not natively subscribe to CloudTrail, VPC Flow Logs, or ALB logs; these services do not send data to Firehose directly, requiring additional setup like CloudWatch Logs subscriptions or custom agents.

Why this answer

How to eliminate wrong answers

Option A is wrong because AWS DataSync is designed for online data transfer over the network, and at 100 Mbps, it would take over 46 days to transfer 50 TB, which does not meet the one-week requirement. Option C is wrong because Amazon CloudFront is a content delivery network (CDN) for caching and distributing content to edge locations, not a data transfer service for ingesting large volumes of historical data into S3. Option D is wrong because AWS Database Migration Service (DMS) is specialized for migrating databases (e.g., relational, NoSQL) and does not support transferring HDFS files or large-scale file-based data to S3.

Why this answer

How to eliminate wrong answers

Option A is wrong because AWS DMS with continuous replication is designed for ongoing, near-real-time data synchronization or migration, not for a daily batch ingestion of 500 GB; continuous replication would incur unnecessary overhead and cost for a scheduled daily load. Option B is wrong because Amazon Athena with federated query to RDS is an interactive query engine that can read data directly from RDS, but it is not designed for ingesting or moving large volumes of data into S3; it would require additional steps to write results and is inefficient for 500 GB daily transfers. Option C is wrong because Amazon EMR with a Spark job is a valid but overkill and more complex option; it requires provisioning and managing clusters, whereas AWS Glue offers a simpler, serverless alternative that is better suited for this scheduled batch ETL workload.

Why this answer

How to eliminate wrong answers

Option B (Amazon S3 Transfer Acceleration) is wrong because it only speeds up uploads to S3 over the internet using optimized network paths and edge locations, but it does not transfer database files directly to Aurora PostgreSQL; DMS would still need to read from S3 and apply the data, which does not bypass the network transfer for the initial load. Option C (AWS Direct Connect) is wrong because it provides a dedicated network connection from on-premises to AWS, which can improve bandwidth and latency but still requires the full 2 TB to traverse the network; it does not eliminate the network transfer bottleneck for large initial loads. Option D (Amazon Kinesis Data Firehose) is wrong because it is a real-time streaming data ingestion service designed for streaming data (e.g., logs, events) into S3, Redshift, or Elasticsearch, not for bulk transferring database files for a migration; it cannot handle the initial load of a 2 TB database directly to Aurora PostgreSQL.

Why this answer

How to eliminate wrong answers

Option A is wrong because a down VPC peering connection would cause a complete connectivity failure, not selective missing changes; DMS would report a connection error. Option B is wrong because incorrect table mapping would cause specific tables or columns to be missing entirely, not intermittent missing changes during CDC. Option C is wrong because DMS not publishing logs to CloudWatch Logs affects monitoring and troubleshooting, not the actual data capture or replication process.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because Amazon Athena with CTAS is a batch query engine that reads data from S3, not a streaming ingestion service; it cannot process data from a Kinesis Data Stream in near-real-time and would require intermediate storage, adding latency and cost. Option C is wrong because AWS Glue ETL jobs are designed for batch processing and incur costs for DPU hours even when idle; they are not optimized for continuous, low-latency streaming transformations and would be overkill for simple field mapping. Option D is wrong because Amazon EMR with Spark Streaming requires provisioning and managing a cluster of EC2 instances, which incurs significant cost even for small workloads, and is more complex than necessary for simple transformations on a single Kinesis stream.

Why this answer

How to eliminate wrong answers

Option B is wrong because using too many DynamicFrames does not directly cause a MemoryError; DynamicFrames are lazy transformations and memory issues arise from data volume or worker size, not the number of frames. Option C is wrong because an S3 output bucket in a different region would cause a cross-region access error (e.g., AccessDenied or timeout), not a MemoryError. Option D is wrong because insufficient Kinesis shards cause throttling (ProvisionedThroughputExceededException) or data latency, not a memory exhaustion in the Glue job.

Why this answer

How to eliminate wrong answers

Option A is wrong because Amazon EMR with Spark requires provisioning and managing a cluster, which incurs higher costs and operational overhead for simple transformations that DataBrew can handle natively. Option C is wrong because AWS Lambda has a maximum execution timeout of 15 minutes and is not designed for data transformation workloads that may process large Parquet files, making it unsuitable for scheduled batch jobs. Option D is wrong because AWS Glue ETL with PySpark requires writing and maintaining custom Spark code, which is more complex and costly than using DataBrew's visual recipe approach for the described transformations.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because increasing the buffer size (e.g., MBs or interval) only affects how long Firehose waits before delivering a batch; it does not capture or handle Lambda transformation failures. Option C is wrong because disabling the Lambda transformation would stop all data transformation, which is a core requirement of the pipeline, and processing records in batch later would not recover records already lost during the stream. Option D is wrong because while writing failed records to DynamoDB from within the Lambda function is possible, it requires modifying the Lambda code and does not leverage Firehose's built-in error handling; moreover, DynamoDB has a 400 KB item size limit and is not designed for high-volume streaming failure capture, making it less suitable than the native S3 backup bucket.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because Amazon EMR running Spark Streaming requires you to provision and manage a cluster, incurring significant operational overhead for a simple transformation task. Option B is wrong because AWS Glue ETL jobs are batch-oriented and not designed for near real-time streaming; they cannot be directly triggered by a Kinesis stream in a low-latency manner. Option D is wrong because Amazon Kinesis Data Analytics for Apache Flink is intended for complex stream processing and analytics (e.g., windowed aggregations), not for simple data format conversion to Parquet, and it requires more operational effort than Firehose.

Why this answer

How to eliminate wrong answers

Option A is wrong because using a single large file instead of multiple small files would reduce parallelism in Spark's file scanning, potentially increasing execution time due to less efficient task distribution. Option B is wrong because reducing the number of partitions in the output data affects the write phase but does not address the root cause of slow processing during the read and filter stages. Option C is wrong because converting from Parquet to CSV would increase I/O and CPU overhead due to CSV's lack of compression, schema enforcement, and columnar storage, making the job slower, not faster.

Why this answer

How to eliminate wrong answers

Option A is wrong because DPU allocation affects job parallelism and memory, not network connectivity; increasing DPUs would not resolve a 'Communications link failure' caused by a missing network path. Option B is wrong because data type mismatches typically cause runtime errors during data conversion, not connection-level failures like 'Communications link failure'. Option D is wrong because increasing max_connections addresses connection limits on the RDS side, but the error indicates the Glue job cannot even reach the database, not that connections are being refused due to exhaustion.

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 pg_dump is a one-time logical backup tool, not a CDC solution; it cannot capture ongoing changes and would require full exports, exceeding the 5-minute latency window. Option B is wrong because replicating to Redshift then unloading to S3 adds unnecessary complexity and latency; Redshift is optimized for analytics, not as a CDC staging area, and the unload operation introduces additional delay. Option D is wrong because DMS does not natively support SQS as a target endpoint; DMS can write to S3, Kinesis, or other targets, but not directly to SQS, and the proposed architecture would require custom integration, breaking the near-real-time requirement.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because the region in the ARN must match the Lambda function's region for the policy to apply, but the question does not indicate a region mismatch; the error is specifically about log-stream permissions. Option B is wrong because a Lambda function must have an execution role to access AWS resources, and the question implies a role exists (the policy is attached), but the role lacks the necessary log-stream permissions. Option D is wrong because the wildcard in the ARN is correctly placed for the log group name (my-log-group) and is not the cause of the failure; the issue is the missing log-stream component, not the wildcard format.

Why this answer

How to eliminate wrong answers

Option A is wrong because it requires manual conversion of files with pipes, which contradicts the requirement of no manual intervention and is not efficient for a data pipeline. Option C is wrong because AWS Glue crawlers are designed for schema discovery and cataloging, not for dynamically executing Redshift COPY commands with varying delimiters; they would require additional orchestration to handle the actual data ingestion. Option D is wrong because Amazon Athena with OpenCSVSerDe does not automatically detect delimiters; it requires the delimiter to be specified in the table DDL, and writing results to Redshift adds unnecessary complexity and latency compared to a direct COPY command.

Why this answer

How to eliminate wrong answers

Option A is wrong because the `s3:ListBucket` permission is required for listing objects (e.g., `s3:ListBucket` on the bucket resource), not for writing objects; the error occurs during a write operation, and the policy already includes `s3:PutObject` on the bucket objects. Option C is wrong because the error message is specifically 'access denied when writing to S3', not a KMS-related error; if KMS encryption were the issue, the error would typically mention 'KMS' or 'decrypt' and the policy would need `kms:GenerateDataKey` or `kms:Decrypt`, not just `kms:Decrypt`. Option D is wrong because `glue:StartJobRun` is a permission to start a Glue job run, not a permission for writing to S3; the error occurs during the job execution (writing to S3), not during job initiation.

Why this answer

How to eliminate wrong answers

Option A is wrong because the error is specifically about writing (s3:PutObject), and if the policy lacked that action, the error would still occur, but the question asks for the 'most likely' cause given the policy is attached; the mismatch in the resource ARN is a more precise and common cause. Option C is wrong because wildcards in resource ARNs are allowed in IAM policies (e.g., 'arn:aws:s3:::example-bucket/*'), and using a wildcard would not cause an AccessDenied error if the bucket name matches. Option D is wrong because the job is failing on an S3 write, not on triggering other Glue jobs; Glue actions (like 'glue:StartJobRun') are separate and would produce a different error if missing.

Why this answer

How to eliminate wrong answers

Option A is wrong because job bookmarks track previously processed data to avoid reprocessing, but they do not reduce the initial full load or the per-run data volume; scheduling more frequently would only compound the problem by running incomplete jobs. Option B is wrong because 'hashexpression' and 'hashfield' are not valid JDBC parallelism parameters in AWS Glue; the correct approach for parallel JDBC reads is to set 'hashfield' and 'hashpartitions' (not 'hashexpression'), and even then, parallelism alone cannot overcome the I/O bottleneck of scanning 500 million rows without filtering. Option D is wrong because increasing DPUs to 100 may improve compute parallelism for transformations, but the bottleneck is the JDBC read from PostgreSQL, which is constrained by the source database's network and query capacity, not by Glue's compute resources; excessive DPUs can also cause throttling or connection limits.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because 2 MB/s is the per-shard read throughput with enhanced fan-out, not the total for 5 shards. Option C is wrong because 1 MB/s is the per-shard read throughput for standard (non-enhanced) consumers, not for enhanced fan-out. Option D is wrong because 5 MB/s would be the total read throughput if each shard provided only 1 MB/s (standard) across 5 shards, but enhanced fan-out provides 2 MB/s per shard per consumer.

Why this answer

How to eliminate wrong answers

Option A is wrong because replacing Firehose with Kinesis Data Streams would require additional components (e.g., a consumer to write to S3) and increase cost and complexity, not reduce latency cost-effectively. Option B is wrong because increasing the buffer size to 10 MB would allow more data to accumulate before delivery, potentially increasing latency, not reducing it. Option C is wrong because increasing the buffer interval to 120 seconds would double the maximum buffering time, worsening delivery latency.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because Amazon Kinesis Data Streams is designed for real-time streaming of small records (up to 1 MB per record) and cannot handle bulk transfer of 10 TB of historical data from an HDFS cluster; it lacks the throughput and batch processing capability for such large volumes. Option C is wrong because AWS DMS (Database Migration Service) is intended for migrating databases (e.g., Oracle, MySQL) and does not support HDFS as a source endpoint; it cannot read data from HDFS or transfer it to S3. Option D is wrong because using AWS CLI to copy data directly over a 1 Gbps network link would take at least 22.2 hours under perfect conditions, but real-world factors like TCP overhead, retransmissions, and network congestion make it highly unlikely to complete within 2 days, especially with a single 20 TB disk that may have I/O bottlenecks.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because Kinesis Data Firehose with a Lambda function that queries Oracle would require periodic polling of the source table, which either misses changes between polls or causes high load on the database if polled too frequently, and it does not natively support CDC from Oracle redo logs. Option C is wrong because AWS Data Pipeline with a periodic SQL query activity to copy full table snapshots performs full table scans, which impacts the source database and cannot capture changes in near real-time (only at scheduled intervals). Option D is wrong because AWS Glue with a JDBC connection running a crawler every 5 minutes performs full table scans or incremental queries based on the 'last_modified' column, but this still causes repeated query load on Oracle and cannot achieve true near real-time CDC without reading redo logs.

Why this answer

How to eliminate wrong answers

Option A is wrong because Amazon Kinesis Data Analytics adds unnecessary cost and complexity for a pipeline that only needs to persist raw data to S3, and it requires a separate stream consumer. Option B is wrong because Amazon SQS with Auto Scaling EC2 instances introduces significant operational overhead for managing instance scaling, SQS polling, and potential data loss or duplication, and it is not optimized for near-real-time streaming at 10 MB/s. Option C is wrong because AWS Lambda has a maximum invocation duration of 15 minutes and a concurrency limit that can cause throttling during spikes, making it unsuitable for sustained 10 MB/s throughput without complex sharding and retry logic.

Why this answer

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 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

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

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

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

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 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 DynamoDB on-demand capacity does not use provisioned write capacity units; increasing write capacity units is irrelevant and would require switching to provisioned mode, which is unnecessary. Option B is wrong because replacing Data Pipeline with AWS Glue using a DynamoDB connector does not inherently resolve throttling; Glue also uses the same DynamoDB read APIs and would face the same throttling issue without proper retry handling. Option D is wrong because disabling retry logic and increasing the timeout would cause the pipeline to fail permanently on the first throttling error, as it would not retry the request, and a longer timeout does not prevent throttling.

Why this answer

How to eliminate wrong answers

Option A is wrong because RecordMaxBufferedTime is a Kinesis Firehose parameter that controls how long data is buffered before delivery to a destination; it does not affect Kinesis Data Streams consumer throughput or latency. Option C is wrong because increasing the batch size in the Kinesis Producer Library (KPL) improves write efficiency by aggregating records, but the problem is with the consumer falling behind, not the producer. Option D is wrong because enhanced fan-out provides dedicated 2 MB/s read throughput per consumer per shard, but it does not increase the total number of shards; if the consumer is already saturated on a single shard, enhanced fan-out helps only if multiple consumers exist, but the core issue of insufficient shard count remains.

Why this answer

How to eliminate wrong answers

Option B is wrong because Amazon SQS with AWS Lambda provides at-least-once delivery by default; SQS does not guarantee deduplication without a FIFO queue and idempotent Lambda logic, and even then, exactly-once is not natively supported across retries. Option C is wrong because Amazon MSK (Kafka) with AWS Lambda requires custom checkpointing and idempotency logic in the Lambda function; MSK does not natively provide exactly-once semantics without a stream processing framework like Flink or Kafka Streams. Option D is wrong because Amazon Kinesis Data Firehose with AWS Lambda delivers records at least once and cannot guarantee exactly-once processing; Firehose buffers and batches data but does not support transactional commits or deduplication across retries.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because AWS Transfer Family is used for transferring files into and out of Amazon S3 or Amazon EFS using SFTP, FTPS, or FTP protocols, not for integrating with SaaS APIs. Option B is wrong because AWS Glue is a serverless data integration service for ETL (extract, transform, load) jobs, but it does not natively connect to SaaS sources like Salesforce or Marketo without custom connectors or third-party libraries. Option D is wrong because AWS DataSync is designed for moving large volumes of data between on-premises storage and AWS (e.g., NFS, SMB, S3) or between AWS storage services, not for ingesting data from SaaS applications.

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 if the stream ARN were incorrect, the error would typically be a 'ResourceNotFoundException' or 'InvalidArgumentException', not an AccessDenied error. Option C is wrong because the Glue job is reading from the stream, not writing to it; `kinesis:PutRecord` is for writing data, and the job would need `kinesis:GetRecords` and `kinesis:GetShardIterator` instead. Option D is wrong because the error is specifically for the Kinesis stream, not for S3; an S3 bucket policy blocking PutObject would cause an AccessDenied error on the S3 PutObject operation, not on the Kinesis stream.

Why this answer

How to eliminate wrong answers

Option A is wrong because AWS Direct Connect provides a dedicated network connection, but it is a network service, not a data transfer service; it requires significant setup and cost, and does not include built-in data management features like scheduling or validation for bulk ingestion. Option B is wrong because Amazon S3 Transfer Acceleration only speeds up uploads to S3 over the public internet using edge locations, but it does not handle the initial data extraction from on-premises databases or provide the orchestration needed for multi-TB daily transfers. Option C is wrong because AWS Snowball is a physical device for offline data transfer, which is suitable for very large datasets (petabytes) or low-bandwidth scenarios, but it introduces latency for shipping and is not ideal for daily recurring transfers of several TB per day.

Why this answer

How to eliminate wrong answers

Option A is wrong because Limited LOB mode truncates LOB data to a maximum size, which can cause data loss or row mismatches, but it does not produce duplicate primary key errors. Option B is wrong because source triggers that insert additional rows would add extra rows to the source, but DMS captures changes from the source transaction logs (e.g., Oracle Redo Logs) and would replicate those additional inserts as separate events; they would not cause duplicate key errors on the target unless the inserted rows have the same primary key as existing rows, which is not a typical trigger behavior. Option D is wrong because Parallel apply threads improve performance by applying changes concurrently, but DMS handles conflict resolution and ordering to prevent race conditions; duplicate key errors from parallel apply are extremely rare and not the most likely cause.

Why this answer