Least-overhead row- and column-level access for a multi-engine S3 data lake?
A company needs to build a data lake in AWS. The company must provide row-level data access and column-level data access to specific teams. The teams will access the data by using Amazon Athena, Amazon Redshift Spectrum, and Apache Hive from Amazon EMR. Which solution will meet these requirements with the LEAST operational overhead?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The exam tests whether you can match a fine-grained authorization requirement across multiple query engines to a single managed governance layer — the trap is picking S3 bucket policies or a self-managed Apache Ranger install, both of which cannot cover columns/rows across all three engines without extra operations work.
This question asks which AWS service delivers row-level and column-level authorization over an S3 data lake that is queried by Athena, Redshift Spectrum, and Hive on EMR with the least operational overhead. AWS Lake Formation is the answer because its fine-grained permission model is enforced natively by all three engines.
Choosing Apache Ranger on Amazon EMR (option B) because it is the familiar Hadoop-native tool for row/column masking — it forces you to install, configure, and maintain Ranger policies and plugins on the cluster, and it does not govern Athena or Redshift Spectrum, so it fails the least-overhead requirement.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option D keeps the data where a data lake belongs — Amazon S3 — and delegates fine-grained authorization to AWS Lake Formation, which supports column-level and row-level (data filter) permissions on tables registered in the AWS Glue Data Catalog. Lake Formation is purpose-built for the three consumers named in the question: Athena and Redshift Spectrum enforce Lake Formation permissions through their native Glue/Spectrum integration, and Hive on Amazon EMR can use the Lake Formation-enabled EMRFS/Glue catalog configuration. Because permissions are defined once in Lake Formation and enforced by the service rather than by cluster-side plugins, ongoing operational effort is minimal, which is exactly the 'LEAST operational overhead' constraint. This is the standard AWS reference architecture for a multi-engine, fine-grained-access data lake on DEA-C01.Why the Other Options Are Wrong
Option A fails on capability: S3 access policies (bucket policies, IAM policies, ACLs) operate at bucket, prefix, and object granularity — they cannot express 'rows where team = sales' or 'all columns except salary'. Option B uses Apache Ranger on EMR, which can do row/column filtering for Hive/Spark but requires you to run and maintain the Ranger admin server and EMR plugins, and it does not govern Athena or Redshift Spectrum queries, so it is both higher-overhead and incomplete; Apache Pig as the access path is also irrelevant to the stated engines. Option C puts the lake in Amazon Redshift, which is a warehouse rather than S3-based lake storage, and Redshift row-level security and column-level grants only apply to data inside Redshift — Redshift Spectrum still reads external S3 data, and the federated-query/Spark access pattern adds moving parts instead of removing them.Community Comment Notes
All recorded votes landed on D, and Felix_G framed it exactly as the exam does: "Option D is the best solution to meet the requirements with the least operational overhead", citing S3 durability/scalability plus Lake Formation's column- and row-level control and its native Athena integration. rralucard_ pointed at the Lake Formation cell-level (CBAC) tutorial documentation and stressed integration with Athena, Redshift Spectrum, and Hive on EMR with lower operational overhead. Shanmahi summarized the same reasoning in one line about S3 storage plus Lake Formation fine-grained access.No commenter defended S3 access policies or Apache Ranger, which is consistent with the requirement wording — the vote is unanimous here, and the technical reasoning independently supports option D.
Official Reference
Exam Strategy
When a stem lists multiple heterogeneous query engines (Athena, Redshift Spectrum, Hive on EMR) plus row/column restrictions plus 'least operational overhead', scan for the single managed governance layer that all three engines honor — that is Lake Formation. Eliminate options that govern only one engine or that require you to operate the policy server yourself.
Frequently Asked Questions
Why can't S3 access policies enforce column-level or row-level access?
S3 bucket and IAM policies only grant or deny access to buckets, prefixes, and objects. They have no notion of columns or row filters, so they cannot satisfy a per-team row/column requirement.
Why is Apache Ranger on Amazon EMR not the least-overhead choice here?
Ranger requires you to run and maintain the Ranger admin server and EMR plugins, and it does not govern Athena or Redshift Spectrum queries. Lake Formation centralizes the same row/column policies across all three engines with no servers to manage.
Related Analysis
Practice All DEA-C01 Questions
Access 100 questions with complete answers and detailed explanations.
View Full DEA-C01 Practice Test →