Practice Test #1

Amazon Kinesis Data Streams is a fully managed streaming service with elastic scaling (via shard management or on-demand mode), but it is not Kafka-compatible. Migrating from Kafka/Debezium would require refactoring producers/consumers to Kinesis APIs and rethinking offsets/consumer groups and partitioning semantics. It can meet throughput needs, but it violates the requirement to preserve Kafka APIs under a replatform (not refactor) strategy.

Amazon MSK provisioned cluster preserves Kafka APIs and is a common replatform target for lift-and-shift Kafka migrations. However, it requires more operational management than serverless: you must choose broker instance types/count, plan capacity for bursts, manage scaling operations, and handle partition/broker balancing considerations. It is managed (patching, replacements), but it is not the least-overhead option when automatic scaling is explicitly required.

Amazon Kinesis Data Firehose is designed for delivery to destinations (S3, Redshift, OpenSearch, Splunk) with optional buffering and transformation, not as a general-purpose Kafka-compatible streaming platform. It does not provide Kafka broker semantics, topics/partitions, or consumer group coordination. Using Firehose would require redesigning the CDC pipeline and consumer behavior, making it a refactor and not suitable for preserving Kafka APIs.

Incorrect. While partitioning by reading_date is good, using Amazon Redshift adds cost and operational overhead (loading data from S3, maintaining tables, vacuum/analyze, or paying for Redshift Serverless). For weekly ad hoc KPIs, Athena on partitioned Parquet in S3 is usually cheaper and simpler. Redshift is better when you need consistently high concurrency/latency or complex warehouse workloads.

Incorrect. Partitioning by ingestion_date does not match the filter on reading_date, so Spark jobs may still scan large amounts of data unless additional indexing/partitioning is done. EMR also introduces cluster management and compute costs that are typically not justified for weekly ad hoc SQL KPIs. Spark is appropriate for heavy transformations/ML, not the most cost-effective option for simple date-filtered KPI queries.

Incorrect. Aurora is an OLTP relational database and is not designed for large-scale analytical scans over growing Parquet datasets in S3. You would need to ETL and load data into Aurora tables, increasing cost and complexity, and queries over hundreds of days of data would not be as cost-effective as scanning partition-pruned Parquet with Athena. Aurora also has ongoing instance/storage costs.

Incorrect. Hive-style bucketing (rebucketing files by a commonly filtered column) can help certain query patterns (e.g., joins/aggregations) by reducing shuffle and improving parallelism, but it does not address the core issue: Athena’s planning overhead from millions of partitions in the Glue Data Catalog. Bucketing changes file layout within partitions, not the number of partitions or the need to resolve partition metadata.

Incorrect. Converting to Parquet is a strong optimization for Athena because it is columnar, supports predicate pushdown, and reduces scanned bytes, improving runtime and cost. However, it does not inherently reduce the number of partitions or the need for Athena to resolve partition metadata during planning. If planning is the bottleneck (not scan), Parquet alone will not remove it.

Incorrect. Combining many small objects into larger objects reduces S3 request overhead and can improve Athena runtime by reducing the number of splits and file-open operations. But it does not reduce Glue partition metadata volume or the partition enumeration that drives planning time. It’s a good optimization for the “small files problem,” not for “too many partitions in the catalog.”

Incorrect. An AWS Glue streaming ETL job that writes Parquet files to Amazon S3 creates an additional durable raw copy outside the streaming source, which directly conflicts with the requirement to avoid extra storage cost. The use of hourly partitions is especially problematic because it introduces latency far beyond the under-45-second freshness SLA. Querying through Redshift Spectrum is also better suited to lake-style analytics than low-latency operational dashboards. This design adds operational overhead through job management, partition handling, and S3 file lifecycle concerns.

Incorrect. An external schema by itself is only the connection layer to the streaming source and does not mean a normal Redshift table can simply reference the stream directly as described. For Redshift streaming ingestion, the supported pattern is to define a materialized view over the external streaming source so Redshift can consume and store the stream data appropriately. Without that mechanism, the option is incomplete and technically misleading. It therefore does not represent a valid or best-practice solution for low-latency dashboard access.

Incorrect. Sending the stream to Amazon S3 first creates the extra durable copy that the question explicitly wants to avoid. Using S3 events and AWS Lambda to insert records into Redshift also adds significant operational complexity and is not an efficient loading pattern at the stated sustained and burst event rates. Lambda-based per-object or small-batch inserts can create scaling, retry, and transactional inefficiencies for Redshift. This architecture is therefore both more complex and less likely to meet the sub-minute SLA reliably.

Setting provisioned capacity permanently to peak ensures performance, but it is not cost-effective. You would pay for the maximum RCU/WCU 24/7 even though usage drops significantly after 10:00 and over the weekend (down to ~10% of weekday peak). This directly conflicts with the requirement to minimize spend during off-hours. It’s a common “safe” choice but wastes capacity most of the time.

Splitting into two tables does not inherently reduce cost or improve latency. You still need the same aggregate RCU/WCU to handle the same total read/write volume, so you pay roughly the same (or more) while adding complexity: dual writes/reads, routing logic, potential hot-key issues per table, and operational overhead. This is not a standard DynamoDB cost-optimization technique for predictable time-based demand.

On-demand capacity mode automatically accommodates traffic without explicit provisioning and can maintain low latency, but it is usually most cost-effective for unpredictable or highly variable workloads. With a very predictable schedule and long off-peak periods, provisioned capacity with scheduled scaling typically costs less because you pay for exactly the planned capacity rather than per-request pricing. On-demand is simpler operationally, but not the most cost-effective here.

Incorrect. Enabling “Publicly accessible” for Aurora is intended for access from public networks and typically requires public subnets and routing to an internet gateway. It violates the requirement to connect privately without traversing the public internet and increases the attack surface. Also, the cluster is currently in private subnets with no IGW route, so this change alone would not provide the required connectivity.

Incorrect. Security groups do not provide an inbound source selector called “Lambda function invocations.” Security group rules allow sources by CIDR, prefix list, or another security group. To allow Lambda, you must reference the Lambda ENIs’ security group (or use the same SG) rather than relying on an invocation-based permission concept (which applies to Lambda permissions, not VPC network access).

Incorrect. Network ACL changes are not required for this scenario and add operational overhead. NACLs are stateless and would require both inbound and outbound rules, careful ephemeral port handling, and ongoing maintenance. The default NACL typically already allows all traffic; the real blocker here is that Lambda is not in the VPC and the DB SG only allows self-referenced inbound traffic.

Incorrect. "$(NY|LA).*" uses "$" which anchors the match to the end of the string, not the beginning. That means it would only match if the pattern occurs at the end position (and the rest of the expression is also inconsistent with that intent). It does not implement “port_code begins with NY or LA”. The alternation "(NY|LA)" is fine, but the anchor is wrong.

Incorrect. It uses "$" (end-of-string anchor) rather than "^" (start-of-string anchor), so it cannot enforce “begins with”. Additionally, "&" is not the regex operator for OR; alternation is "|". As written, it will not correctly match values starting with NY or LA and may not behave as intended in Redshift’s POSIX regex engine.

Incorrect. Although it uses "^" to anchor at the start, it incorrectly uses "&" instead of "|" for alternation. Regex alternation for “either/or” is "|". "^(NY&LA).*" would attempt to match the literal sequence "NY&LA" (or otherwise fail depending on regex interpretation), not “NY or LA”.

This option is architecturally incorrect because Amazon Kinesis Data Streams does not deliver records directly to Amazon S3 on its own. A consumer such as a KCL application, AWS Lambda, or another processing service must read from the stream and write the data to S3. Although 4 shards would be sufficient for the throughput, the absence of a delivery mechanism to S3 makes the option invalid. On the exam, any answer claiming Streams writes directly to S3 without a consumer should be eliminated.

This is a workable architecture, but it is not the lowest-latency choice presented. The option explicitly says the KCL consumer writes to S3 with a 10-second application buffer, which means records wait up to that long before becoming S3 objects. A custom consumer also adds operational burden for scaling, checkpointing, retries, object naming, and failure handling. Since Firehose is purpose-built for S3 delivery and avoids that explicit 10-second application delay, this option is not the best answer.

This option adds Amazon Managed Service for Apache Flink even though there is no requirement for stream transformation, enrichment, or analytics before landing the data in S3. It also configures Firehose with a 60-second buffer interval, which clearly increases end-to-end latency beyond the other valid choices. The extra processing layer adds complexity and potential delay without solving any stated business need. Therefore, it is not appropriate when the goal is the least-latency delivery into S3.

Incorrect. Although AWS Lambda is serverless, this option requires custom code to parse SQS messages, interpret S3 object events, and call Glue Data Catalog APIs correctly. That creates ongoing maintenance for retries, idempotency, schema evolution, and error handling across multiple accounts. The question explicitly asks for a solution without building custom code and with the least operational overhead.

Incorrect. Manually starting a crawler is operationally intensive and cannot reliably guarantee updates within 10 minutes of every new object write. It does not scale for frequent telemetry arrivals across multiple buckets and accounts. This directly conflicts with the automation and low-overhead requirements.

Incorrect. AWS Step Functions would add orchestration complexity and still would not by itself update the Data Catalog without additional custom tasks or integrations. The team would need to manage state machines, permissions, retries, and likely Lambda functions or other components to process SQS messages. That is more operationally heavy than using the native Glue crawler event-driven capability.