A city’s open-data program needs distributed Apache Spark jobs to transform large civic datasets before publishing. Which AWS service is the appropriate managed big-data processing cluster choice?
Select an answer to reveal the explanation.
Short Explanation
Spark wants a real big-data cluster, not a website host or a desktop farm. EMR is the AWS managed path for distributed Spark jobs that reshape city open data at scale. Amplify hosts apps, WorkSpaces are desktops, and Transit Gateway moves packets—it doesn’t run Spark stages.
Full Explanation
Distributed Apache Spark transformations over large civic open-data sets need a managed big-data processing cluster, not a website host or desktop farm. Amazon EMR provides managed Hadoop and Spark environments so the city’s open-data program can run distributed jobs at scale with less undifferentiated cluster toil. Selecting EMR is the Task 3.2 high-performing compute choice for this Spark ETL pattern before publishing transformed datasets. AWS Amplify Hosting fails because it is an application hosting and CI/CD-oriented service for web front ends, not a Spark execution cluster. Amazon WorkSpaces for each analyst as the sole processing fabric fails conceptually: desktops help interactive users but do not provide distributed Spark cluster compute for large civic datasets. AWS Transit Gateway fails because it is a network transit hub for connecting VPCs and on-premises networks; it moves packets and does not compute Spark stages. Exam caveat: EMR is the cluster fabric—storage often still lands in S3, and you must size instance fleets, spot vs on-demand mix, and job parallelism for open-data SLAs. Operational check: launch an EMR Spark job against a representative open-data lake prefix, verify output partitions land where publishers expect, and monitor step failures and cluster utilization before production schedules.