Lab 3B — Athena on Iceberg

15 timed scenario questions (~24 min, ~96 sec each). Reinforces night-24-athena-iceberg.md and night-24-lab-athena-setup scripts. Answer without peeking at night-24-quiz-answers.json first.

1. 1.GSA leadership wants ad hoc SQL: resort counts grouped by country_code on Parquet files exported to the Night 20 migration bucket. No always-on warehouse cluster. Best fit?

   A.Amazon Athena with Glue catalog tables over the S3 Parquet/Iceberg pathsB.Amazon Aurora Serverless v2 — run GROUP BY on the live writer endpoint for this workloadC.ElastiCache Redis — store pre-aggregated country counts as JSON blobsD.AWS DMS CDC — replicate S3 Parquet rows back into DynamoDB for GetItem

2. 2.Night 17 stats-uploader must UPSERT monthly_runs on resort_stats with millisecond latency and ACID guarantees. Which store is purpose-built?

   A.Athena INSERT INTO over Iceberg — primary transactional path for ski uploadsB.Aurora PostgreSQL writer endpoint in private subnets — OLTP relational storeC.S3 Standard with object lock — one object per resort row updated via PUTD.Athena CTAS nightly — replaces Aurora for all live write traffic for this workload

3. 3.An Athena query fails with “Table not found” though Parquet files exist in S3. What does the Glue Data Catalog provide that raw S3 lacks?

   A.Automatic ACID transactions so INSERT competes with Lambda writers for this workloadB.Internet-facing HTTPS endpoint so browsers query Parquet directly for this workloadC.Registered table metadata — column names, format, and S3 location for SQLD.Replacement for IAM — Glue stores user passwords for Athena login for this workload

4. 4.GSA prod registers Apache Iceberg tables on pipeline output instead of a loose Parquet folder. Which Iceberg capability matters most for “query yesterday’s snapshot after a bad ETL run”?

   A.Iceberg replaces the need for any S3 bucket — data lives in Athena RAMB.Iceberg forces DynamoDB streams to push every viewCount change into SQL for this workloadC.Iceberg converts Aurora WAL into binlog for DMS heterogeneous movesD.Iceberg snapshots / time travel — query an earlier table version without

5. 5.Your Athena bill spikes after analysts scan an unpartitioned 8 TB export. Primary billing driver to optimize first?

   A.Data scanned per query — add partition columns and filter predicatesB.Number of Glue crawlers scheduled per hour — disable all crawlers for this workloadC.Aurora ACU hours — Athena queries always spin up an Aurora readerD.CloudFront edge requests — Athena SQL runs at every POP globally

6. 6.night-24-lab creates workgroup saa-study-gsa-athena with EnforceWorkGroupConfiguration. Queries fail until OutputLocation is set. Where do result CSV files land?

   A.ElastiCache Redis — Athena streams result rows into cache keysB.S3 prefix night-24/athena-results/ in the migration bucket workgroup configC.DynamoDB saa-study-gsa-wiki-views — each row becomes a query itemD.Lambda /tmp only — S3 is never used for Athena query result outputs for this workload

7. 7.Night 20 exported saa-study-gsa-wiki-views to night-20/dynamodb/wiki-views/ as DynamoDB JSON. Why is that path not tonight’s direct SQL target for resort_stats analytics?

   A.DynamoDB JSON exports are encrypted with KMS keys Athena cannot readB.Athena only queries Aurora snapshots already loaded into the writerC.Format mismatch — wiki export is DynamoDB JSON, not relationalD.Glue crawlers refuse to run on buckets tagged saa-study-migration=night-20

8. 8.200 BI users run concurrent complex JOINs on a 50 TB curated star schema all day. Ad hoc serverless SQL on raw S3 alone is too slow. Better primary warehouse?

   A.Amazon Athena — pay per query with no cluster tuning ever needed for this workloadB.ElastiCache Memcached — store every JOIN result as a string key for this workloadC.CloudFront — cache warehouse SQL responses at the edge for this workloadD.Amazon Redshift or Redshift Serverless — provisioned/ serverless MPP warehouse

9. 9.night-24-lab registers resort_snapshot with explicit Athena DDL and CTAS — no crawler deployed. Exam-accurate statement about Glue crawlers?

   A.Crawlers are optional — manual DDL or CTAS can populate the catalog withoutB.Every Athena query requires an hourly crawler run before SQL is allowedC.Crawlers replace IAM roles for S3 read permissions on query results for this workloadD.Crawlers only work on Aurora — S3 tables must use DMS instead for this workload

10. 10.night-24-lab runs CREATE TABLE … table_type=ICEBERG via CTAS. DDL fails on Athena engine version 2 with unsupported table type. Fix?

    A.Move Redis to public subnets so Athena can reach Iceberg metadataB.Select Athena engine version 3 on the workgroup — Iceberg DDL needs v3C.Enable PITR on the Glue database — Iceberg requires continuous backupD.Switch to Memcached — Iceberg tables must be loaded into ElastiCache first

11. 11.You run night-24-lab-athena-teardown.ps1 after finishing analytics practice. What remains in AWS?

    A.Nothing — teardown deletes the entire migration bucket including Night 20 DynamoDBB.Aurora cluster and Redis — teardown always deletes all Week 3 databasesC.Night 20 night-20/ DynamoDB export prefix and bucket — only night-24/ AthenaD.Glue catalog for every GSA prod Iceberg table in the production account

12. 12.A 5-year resort export grows to terabytes. Queries filter on country_code every time. Best cost/latency habit?

    A.Store all countries in one giant CSV object — Athena loves single filesB.Query Aurora reader instead — readers automatically partition S3 for freeC.Disable workgroup OutputLocation to avoid writing result files for this workloadD.Partition by country_code (or use Iceberg hidden partitioning) so Athena

13. 13.Nightly Spark job transforms 500 GB of raw JSON logs into curated Parquet before analysts run SQL. Which service runs the heavy batch transform?

    A.AWS Glue ETL or Amazon EMR (Spark) — batch transform; Athena queries the outputB.Amazon Athena — primary engine for long-running Spark shuffle jobs for this workloadC.AWS Backup — backup plans convert JSON to Parquet during vault copyD.Route 53 latency routing — routes log bytes to the cheapest S3 AZ for this workload

14. 14.Match workload to store: (1) live resort_stats UPSERT from SQS, (2) quarterly country rollup on historical S3 snapshots.

    A.Both on Athena Iceberg — single store simplifies architecture for this workloadB.(1) Aurora OLTP writer, (2) Athena SQL on Glue/Iceberg over S3 exportsC.Both on DynamoDB streams — relational UPSERT and GROUP BY in one tableD.(1) CloudFront cache, (2) ElastiCache Redis TTL keys only for this workload

15. 15.Wiki viewCount hot reads (Night 18) need microsecond DynamoDB acceleration. Resort country analytics run on S3 snapshots (Tonight). Pick the DynamoDB-specific cache vs analytics SQL tool.

    A.Use Athena workgroups to cache GetItem responses for wiki pageId keys for this workloadB.Redshift Spectrum replaces both DAX and DynamoDB for all GSA reads for this workloadC.DAX for DynamoDB hot reads; Athena for SQL analytics on S3 — different layersD.ElastiCache Redis replaces Glue catalog registration for Iceberg tables for this workload