Practice Test #2

Lake Formation data filters do not register S3 prefixes as data locations; registration and filtering are separate Lake Formation steps. Trap: It uses the right service vocabulary but combines two different Lake Formation constructs incorrectly.

Data filters are not attached to IAM roles. Lake Formation grants permissions to a principal using a data filter. Trap: The distinct IAM roles are important, but the filter is referenced in a Lake Formation grant, not attached like an IAM policy.

Creating separate buckets violates the requirement to avoid new buckets or duplicated data and adds operational overhead. Trap: Bucket-level IAM policies can isolate objects, but this scenario asks for centralized query-time governance over one S3 data lake.

S3 Glacier Deep Archive is not suitable for data that a dashboard must query every 15 minutes. Objects would need restore workflows before Athena could analyze them. Trap: It reduces storage cost, but the question is about active Athena query cost and SLA-friendly access.

Athena query result reuse only helps when the same SQL can reuse a prior result and does not lower the first scan cost. Dashboard queries often vary by time window or filter. Trap: Caching sounds low effort, but it is narrower than reducing scan volume for all queries.

ElastiCache adds new infrastructure, integration work, cache invalidation, and operations. That conflicts with the requirement for no new infrastructure and least overhead. Trap: Application caching can reduce repeated reads, but it is not the native Athena data-lake optimization.

ALL distribution replicates the table to every node, which is appropriate for small dimension tables, not a wide table growing to 3 TB. Trap: It can speed joins for small reference data, but the storage and load overhead explode for large fact tables.

EVEN distribution avoids choosing a bad key, but it is still a fixed manual choice and does not best satisfy the maintenance requirement. Trap: EVEN is a reasonable fallback when no key exists, but AUTO is the stronger answer when Redshift-managed optimization is offered.

KEY distribution requires a stable, evenly distributed join key, and the prompt explicitly says no suitable column exists. Trap: DISTKEY is powerful when it matches common joins, but a poor key causes skew and future rework.

Separate S3 buckets would move the isolation to storage and conflicts with the requirement to keep using the same S3 buckets without duplicating data. Trap: Bucket policies are a familiar isolation tool, but they do not isolate Athena query history, saved queries, or execution costs.

IAM roles can grant permissions, but roles alone do not create separate Athena saved-query, query-history, or cost-control boundaries. Trap: Per-team roles sound like access isolation, but the question asks for resource tag enforcement and workgroup-scoped artifacts.

Glue Data Catalog policies can control table metadata access, but they do not isolate Athena execution resources, saved queries, query history, or costs. Trap: Glue is involved in Athena metadata, but the requested isolation is in Athena's operational control plane.

MWAA plus Lambda plus Step Functions is overbuilt, and Lambda is not ideal for joining PostgreSQL logs with 100 GB of ticket history. Trap: Each service is managed, but combining them adds duplicated orchestration and custom code.

AppFlow and Glue fit the data sources, but MWAA adds an Airflow environment to manage for a simple once-nightly workflow. Trap: Airflow is a valid orchestrator, but the question asks for the least operational overhead.

Kinesis Data Streams and Managed Service for Apache Flink are streaming services, while the requirement is a nightly batch process. Trap: Streaming correlation sounds powerful, but it adds unnecessary cost and operations for a once-per-night job.

AWS Glue is useful for serverless Spark ETL, but it does not provide the complete Hadoop ecosystem, especially HBase and Oozie. Trap: The phrase serverless where possible points toward Glue, but the named frameworks make Glue incomplete.

Lambda cannot run Spark, Flink, HBase, and Oozie as a distributed processing platform, and it is not suitable for multi-petabyte ETL runs. Trap: It has low operational overhead, but it is event-function compute rather than a Hadoop runtime.

Amazon Redshift is a data warehouse for SQL analytics and ELT, not a managed runtime for Spark, Flink, HBase, or Oozie workflows. Trap: Redshift can transform data with SQL, but it does not meet the requirement to continue using the existing frameworks.

Changing the Athena results location and encryption only affects SQL query output storage; it does not enable PySpark notebooks or Spark execution. Trap: Result settings are real Athena settings, but they are unrelated to the requested compute engine.

Athena data source connectors are for federated querying external systems, not for adding Apache Spark runtime support to S3 data. Trap: The Glue Data Catalog is part of Athena metadata, but registering a connector there does not create Spark notebooks.

Spark execution is not just a per-query toggle in the SQL editor; Athena uses workgroups to configure and govern Spark workloads. Trap: The UI may expose multiple experiences, but the operational boundary is still the workgroup.

A sort key can reduce scanned blocks for predicates, but it does not change which node owns the rows. Trap: WHERE-clause tuning helps many Redshift queries, but the symptom here is node imbalance from distribution skew.

Larger RA3 nodes add capacity, but they do not fix uneven data placement and do not meet the intent of distributing workload evenly. Trap: More CPU could mask the hot node for a while, but five nodes would still be underutilized.

Changing a primary key does not redistribute data in Redshift; primary keys are not enforced like OLTP database constraints. Trap: It sounds like a table-design fix, but Redshift physical placement is controlled by distribution style and key.

Making Aurora publicly accessible violates the private connectivity requirement and does not fit private subnets with no internet gateway route. Trap: Public accessibility can solve some external connectivity problems, but this scenario explicitly forbids public internet traversal.

Security groups do not have a source type named Lambda function invocations. Network access is allowed by CIDR, prefix list, or security group reference. Trap: Lambda invocation permissions are a separate resource-policy concept and do not open VPC network traffic.

A network ACL self-reference is not a valid security group-style control and would add stateless subnet rule complexity. The blocker is Lambda VPC placement and security group access. Trap: NACLs are network controls, but they are not the least-operational-overhead tool for allowing Lambda ENIs to reach Aurora.