Select Two (Multi-Select) Questions

Amazon Kinesis Data Firehose

Why it fails: Firehose is for delivering data to destinations, not for multiple consumers; it buffers data.

Amazon Simple Queue Service (SQS)

Why it fails: SQS is a queue, not a streaming platform; it doesn't support multiple independent consumers efficiently.

Amazon S3

Why it fails: S3 is object storage, not a streaming ingestion service.

Improves write throughput by batching writes.

Why it fails: DAX does not batch writes.

Supports write-through caching to improve write performance.

Why it fails: DAX is primarily for reads, not writes.

The number of columns in the table.

Why it fails: Column count does not influence Redshift distribution; the planner distributes rows by key values or round-robin, so width is irrelevant to collocation and join data movement. It is tempting because wider tables do cost more to scan, which matters for columnar storage, not for distribution style selection.

The data type of the distribution key column.

Why it fails: Distribution keys must be hashable, and Redshift supports common types, so the key's data type does not determine collocation or reduce join data movement. It is tempting because type mismatches can force casting in join predicates, which is a query-design concern rather than a distribution-style factor.

AWS CloudTrail

Why it fails: CloudTrail logs API activity for audit purposes, recording who called which AWS action, but it captures no CPU or storage metrics and sends no threshold alerts. It is tempting because CloudTrail is a monitoring service, and it would be correct for auditing configuration changes made to the RDS instance.

AWS Config

Why it fails: AWS Config records resource configuration changes and evaluates compliance rules; it does not collect CPU or free-storage metrics or dispatch threshold notifications. It is tempting because Config monitors AWS resources, and it would be correct for detecting an RDS instance whose settings drift from a defined baseline.

Amazon Route 53

Why it fails: Route 53 provides DNS resolution and health-check-based routing, so it neither gathers RDS performance metrics nor raises threshold alarms. It is tempting because Route 53 health checks trigger notifications, and it would be correct for failing over DNS traffic when an endpoint becomes unreachable.

Use server-side encryption with customer-provided keys (SSE-C).

Why it fails: SSE-C requires managing your own keys, which is not recommended for simplicity.

Enable S3 Transfer Acceleration for the bucket.

Why it fails: Transfer Acceleration improves upload speed, not security.

Enable object-level access control lists (ACLs).

Why it fails: ACLs are legacy; bucket policies and IAM are recommended.

Store data in a single large file without partitioning

Why it fails: One unpartitioned object prevents Athena from pruning irrelevant data and limits read parallelism to a single split, so every query scans the entire dataset. It is tempting because fewer, larger files reduce small-file overhead, and that would help when objects are tiny, but partitioning by common filter columns enables partition pruning.

Use GZIP compression on the Parquet files

Why it fails: GZIP is not splittable, so Athena cannot parallelise reads across a large Parquet object, negating the columnar benefit. It is tempting because GZIP shrinks storage and transfer volumes, and suits archival or small-file workloads, but query engines need splittable compression such as Snappy to read partitions concurrently.

Split large files into many small files

Why it fails: Many small files worsen Athena performance: each file incurs per-object listing and request overhead, and Parquet's row-group statistics and columnar compression work best on larger files. Splitting is tempting when files are too large for a single node's memory, but the stem asks about query performance on large Parquet files, where compaction into fewer, right-sized files is the fix.

AWS Glue

Why it fails: Primarily for batch ETL, not real-time streaming.

Amazon S3 Transfer Acceleration

Why it fails: Speeds up file uploads to S3, not a streaming ingestion service.

AWS Database Migration Service (DMS)

Why it fails: Used for migrating databases, not for streaming data ingestion.

Amazon S3 Transfer Acceleration

Why it fails: Transfer Acceleration speeds up transfers of existing objects to S3 over long distances using edge locations; it does not ingest streaming data. It is tempting because it genuinely accelerates uploads, and would be correct for large batch migrations or geographically distant clients uploading files.

Amazon Elastic Block Store (Amazon EBS)

Why it fails: EBS provides block storage volumes attached to EC2 instances; it is not an ingestion service and does not write to S3. It is tempting because EC2 can run streaming producers, but EBS itself would be correct only for instance-local persistent disk storage.

AWS Snowball

Why it fails: Snowball is a physical appliance for shipping bulk data offline into S3; it cannot ingest continuous streams. It is tempting because it does move data into S3, and would be correct for migrating terabytes of existing on-premises data where network transfer is impractical.

SSL/TLS

Why it fails: SSL/TLS encrypts data in transit between clients and endpoints, so it cannot satisfy the stem's at-rest requirement for objects stored in Amazon S3. It is tempting because TLS is the standard mechanism for protecting data moving over networks, and it would be the right answer if the question asked how to secure uploads or API calls in flight.

AWS SDK client-side encryption

Why it fails: AWS SDK client-side encryption encrypts objects before they reach S3, so the service stores ciphertext it cannot decrypt — that is client-side, not server-side, encryption. It is tempting because it protects data in transit and at rest from AWS itself, and would be correct where the customer must retain sole control of keys and plaintext.

AWS CloudHSM

Why it fails: AWS CloudHSM supplies dedicated hardware security modules for key storage and cryptographic operations, not server-side encryption of S3 objects itself; S3 SSE-KMS and SSE-S3 perform that encryption. It is tempting because CloudHSM underpins custom key management, and would be correct where you must retain exclusive control of keys under strict compliance rules.

Use Amazon Kinesis Data Streams to capture DynamoDB Streams changes.

Why it fails: This is for streaming, not for bulk export; also may not guarantee exactly-once for large backfills.

Use Amazon S3 Object Lambda to transform data on the fly.

Why it fails: S3 Object Lambda is for user-defined transformations on GET requests, not for ingestion pipelines.

Enable Redshift Enhanced VPC Routing.

Why it fails: Enhanced VPC Routing only forces COPY and UNLOAD traffic through your VPC, so it governs where Redshift's own S3 and external data flows travel, not who may reach the cluster. It is tempting because it tightens network control around a cluster, but it would be the right choice when you must audit or restrict Redshift's data-loading paths, not for on-premises access.

Create a VPC endpoint for Redshift.

Why it fails: A VPC endpoint (PrivateLink) exposes Redshift to resources inside the VPC or to other VPCs, not to an on-premises network reached over Direct Connect. It is tempting because it provides private connectivity without internet exposure, and would be correct for accessing Redshift from another VPC or AWS service.

Make the Redshift cluster publicly accessible.

Why it fails: Public accessibility assigns a public IP, letting the cluster be reached over the internet, which contradicts the requirement that access come only from the on-premises network via Direct Connect. It is tempting because it removes connectivity friction, and would be correct for clients connecting from outside the VPC without private links.

AWS Glue ETL for CDC from Aurora.

Why it fails: AWS Glue ETL lacks native change data capture (CDC) integration for Aurora; it requires custom logic or additional services like AWS DMS to capture ongoing row-level changes. This option is tempting because Glue ETL is commonly used for batch transformations and could handle initial Aurora snapshots, but it cannot continuously stream CDC events without external tooling.

Amazon EMR for daily CSV ingestion.

Why it fails: Amazon EMR processes and analyses data on S3 or HDFS; it does not poll an SFTP endpoint or schedule file transfers. It would be correct for transforming or querying the ingested CSV data at scale, but ingestion from SFTP needs AWS Transfer Family or a scheduled DataSync task instead.

Enable concurrency scaling

Why it fails: Concurrency scaling adds transient clusters for concurrent queries, not for accelerating a single frequently run dashboard query. It is tempting because it improves throughput, but it would be the correct choice when many users run queries simultaneously, not for one dashboard's repeated workload.

Add more nodes to the cluster

Why it fails: Adding nodes increases cluster capacity and cost but does not by itself optimise the dashboard's query pattern; sort keys, distribution keys or materialised views address that. It is tempting because scaling is a familiar remedy, but it would be correct when sustained CPU or storage pressure, not query design, limits performance.

Amazon Kinesis Data Streams

Why it fails: Kinesis Data Streams provides real-time ingestion but lacks native deduplication and schema evolution handling; the pipeline would require custom code for these tasks, increasing latency beyond the 1-hour target. It is tempting because it excels for streaming data under 5-minute latency, such as clickstream processing, where schema changes are managed externally.

AWS Database Migration Service (DMS)

Why it fails: DMS is for database migration, not SaaS applications.

The partition key should be chosen to maximize the size of items in each partition.

Why it fails: Maximising item size per partition is not a selection factor; DynamoDB partitions split on throughput and storage limits, and larger items consume more capacity without improving distribution. It is tempting because even data spread across partitions is desirable, but item size is governed by the 400 KB limit, not by partition key design.

The partition key should be chosen to minimize read capacity unit consumption.

Why it fails: Minimising read capacity unit consumption is not a partition key selection factor; RCU consumption depends on item size and access patterns, not key choice. It is tempting because cost reduction is a general design goal, and a well-distributed key does avoid hot partitions, but that is a throughput concern rather than an RCU-minimisation criterion.

AWS Glue

Why it fails: Glue is for ETL, not for bulk data transfer.

Amazon S3 Transfer Acceleration

Why it fails: May not guarantee 1 week transfer for 50 TB over 1 Gbps.

AWS Direct Connect

Why it fails: It is a dedicated network connection, not a data transfer service.

Route the CloudWatch Logs subscription to an Amazon SQS queue first

Why it fails: Adds latency and complexity, not directly reducing backlog.

Change the Lambda function runtime from Python to Node.js

Why it fails: Minor difference; not a primary fix.

AWS Snowcone

Why it fails: AWS Snowcone is a physical edge device shipped to your site for offline data transfer; it never traverses the internet. It is tempting because it is secure and handles large volumes, but it is the right choice for remote or bandwidth-constrained locations, not for online ingestion from on-premises sources.

Amazon Kinesis Data Firehose

Why it fails: Amazon Kinesis Data Firehose delivers streaming data into destinations such as S3, but it consumes streams from producers rather than pulling files from on-premises systems over the internet. It is tempting because it lands data in S3, yet it suits real-time streaming pipelines, not batch transfer from on-premises sources.

AWS Direct Connect

Why it fails: AWS Direct Connect provisions a dedicated private network circuit from on-premises to AWS, not a transfer over the public internet. It is tempting because it is secure and fast, but it is the correct choice when consistent bandwidth and reduced egress costs matter, not for internet-based ingestion.

AWS Step Functions

Why it fails: Step Functions orchestrates workflows and state machines; it does not itself watch Glue job runs or send failure notifications. It tempts because it can invoke Glue jobs and branch on their outcomes, which would suit coordinating a pipeline rather than alerting on failures.

Amazon Kinesis Data Streams

Why it fails: Kinesis Data Streams ingests and transports real-time records; it neither detects Glue job state changes nor delivers alerts. It tempts because it is a core streaming service, and would be correct for capturing event data feeding the pipeline, not for failure monitoring.

Amazon SQS

Why it fails: Amazon SQS is a message queue, not a notification delivery service; it cannot send alerts to engineers when a Glue job fails. It is tempting because SQS decouples pipeline components, and it would be correct for buffering events between producers and consumers, not for failure alerting.

AWS Lambda with S3 SDK

Why it fails: Requires custom code.

AWS Glue with a Python shell job

Why it fails: Glue is not designed for webhook ingestion.

Amazon Kinesis Data Streams

Why it fails: Requires a custom producer to put records.