Practice Test #2

Amazon MWAA can certainly orchestrate SQL tasks on a schedule, but it requires creating and maintaining an Airflow environment, DAGs, IAM roles, and supporting configuration. That is significantly more operational overhead than the question requires for a straightforward recurring SQL maintenance task. The requirement explicitly says to avoid provisioning or managing orchestration infrastructure, and MWAA is still an orchestration platform even though AWS manages parts of it. Therefore, MWAA is functional but not the least-effort option.

Redshift Lambda UDFs are invoked from SQL statements during query execution and are not a native scheduling mechanism for recurring database maintenance. A UDF cannot independently wake up every 30 minutes and trigger refreshes on a timer inside Redshift Serverless. To make this work, the team would still need an external scheduler such as EventBridge or another orchestration service, which contradicts the stated requirement. In addition, using a UDF for this purpose is an unnatural design compared with built-in scheduled queries.

AWS Glue workflows and jobs can be scheduled and can connect to Amazon Redshift, but they are designed primarily for ETL and data integration pipelines rather than simple recurring SQL administration tasks. Implementing this would require creating and maintaining a Glue job or Python shell job, configuring connectivity, IAM permissions, and operational monitoring. That is more setup and more moving parts than necessary when Redshift already provides native scheduled query capability. As a result, Glue can meet the functional requirement but not the least-effort requirement.

Pandas drop_duplicates() is simple for exact duplicate rows, but it is not a managed, auto-scaling approach for 3 TB/week. You would need to run it on self-managed compute (EC2/ECS/EKS) or engineer a distributed approach, and Pandas is memory-bound (single-node) unless you add additional frameworks. This increases operational overhead and risks performance bottlenecks at 120M rows.

A custom Python ETL using the third-party dedupe library can perform probabilistic matching, but it violates the requirement to avoid third-party libraries. It also implies operational overhead for dependency management, packaging, runtime compatibility, and scaling the compute environment. This approach is harder to operationalize reliably at multi-terabyte weekly volumes without significant engineering effort.

Running the third-party dedupe library inside an AWS Glue job still violates the “avoid third-party libraries” requirement and adds operational burden (managing Python wheel/egg dependencies, Glue version compatibility, job bootstrap, and troubleshooting). While Glue provides serverless scaling, the dependency lifecycle and potential Spark/Python environment issues increase overhead compared to using Glue’s built-in FindMatches transform.

Not ideal. Implementing 30-minute time-based aggregations with 90 seconds of late arrivals in Lambda requires external state storage (e.g., DynamoDB) and custom windowing, watermarking, and deduplication logic. This increases operational overhead and complexity, and correctness becomes harder under retries and partial failures. Lambda is better for stateless transforms or lightweight enrichment, not robust event-time analytics.

Partially relevant because Managed Service for Apache Flink is the right engine for stateful aggregations. However, the option focuses on duplicates rather than the stated requirement of event-time windows with late arrivals. While Flink can handle duplicates (often via keys/ids and state), the core requirement is time-based analytics with event-time windowing; this option is less directly aligned than D.

Still not ideal. Even though it mentions tumbling windows and event timestamps, Lambda does not natively provide Flink-like event-time windowing semantics, watermarks, and managed state for long windows with late data. You would need to build and operate significant custom logic and state management to handle late arrivals and window finalization, which conflicts with the “minimum operational overhead” requirement.

Kinesis Data Firehose can deliver streaming data to Redshift, but it commonly uses S3 staging and COPY under the hood, operating in buffered micro-batches. Achieving consistent sub-60-second freshness can be challenging depending on buffering settings, COPY performance, and peak throughput. It’s lower-ops than custom consumers, but not as direct/low-latency as Redshift streaming ingestion for Kinesis Data Streams.

Landing to S3 and using the Redshift COPY command is a batch ingestion pattern. It requires building and operating a process to write files, manage partitions, trigger COPY jobs, handle retries, and tune file sizes/manifesting. This increases operational overhead and typically cannot guarantee sub-minute freshness because it depends on file creation and batch load scheduling.

Aurora zero-ETL integration with Amazon Redshift is specifically for replicating data from Amazon Aurora (MySQL/PostgreSQL) into Redshift with minimal ETL. The source in this scenario is Amazon Kinesis Data Streams, not Aurora, so this option does not address the ingestion requirement and cannot meet the stated streaming telemetry use case.

This is incorrect because the Lambda execution role trust policy determines which service can assume the execution role when the function runs. EventBridge does not assume the Lambda execution role in order to invoke the function. Invocation permission is controlled by the Lambda function's resource-based policy, so changing the execution role trust relationship would not resolve the AccessDeniedException. This option confuses runtime permissions with invoke permissions.

This is incorrect because placing a Lambda function in a private subnet affects the function's network access to resources inside or outside a VPC. It does not control whether EventBridge is authorized to invoke the function. EventBridge-to-Lambda invocation is governed by IAM and Lambda resource-based permissions, not subnet placement. Therefore, moving the function into a private subnet would not fix an authorization failure from Lambda.

This is incorrect because the EventBridge schema registry and event pattern mapping are related to event discovery and rule matching, not Lambda authorization. If the event pattern were wrong, the rule would simply not match or the target would not be invoked. The question specifically states that the invocation fails with AccessDeniedException from Lambda, which points to missing invoke permission on the Lambda side. Therefore, schema or pattern corrections would not address the root cause.