Least-overhead row- and column-level access for a multi-engine S3 data lake?

DEA-C01 By islever Editorial Last updated Oct 17, 2026

Apply authorization mechanisms. Understand data privacy and governance.

Short answer

D Store the lake in Amazon S3 and use AWS Lake Formation for row- and column-level access control across Athena, Redshift Spectrum, and Hive on EMR.

Question

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?

Use Amazon S3 for data lake storage. Use S3 access policies to restrict data access by rows and columns. Provide data access through Amazon S3.
Use Amazon S3 for data lake storage. Use Apache Ranger through Amazon EMR to restrict data access by rows and columns. Provide data access by using Apache Pig.
Use Amazon Redshift for data lake storage. Use Redshift security policies to restrict data access by rows and columns. Provide data access by using Apache Spark and Amazon Athena federated queries.
Use Amazon S3 for data lake storage. Use AWS Lake Formation to restrict data access by rows and columns. Provide data access through AWS Lake Formation. Correct Answer

Key Takeaways

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.

Common mistake: 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.

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

These links open the official vendor documentation in a new tab.

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.

More DEA-C01 FAQ →

Community Votes

100%

100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 4 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 4

Felix_G 👍 4

Option D is the best solution to meet the requirements with the least operational overhead. Using Amazon S3 for storage and AWS Lake Formation for access control and data access delivers the following advantages: S3 provides a highly durable, available, and scalable data lake storage layer Lake Formation enables fine-grained access control down to column and row-level Integrates natively with Athena, Redshift Spectrum, and EMR for simplified data access Fully managed service minimizes admin overhead vs self-managing Ranger or piecemeal solutions
rralucard_ 👍 4 Answered D

https://docs.aws.amazon.com/lake-formation/latest/dg/cbac-tutorial.html Option D, using Amazon S3 for data lake storage and AWS Lake Formation for access control, is the most suitable solution. It meets the requirements for row-level and column-level access control and integrates well with Amazon Athena, Amazon Redshift Spectrum, and Apache Hive on EMR, all with lower operational overhead compared to the other options.
Shanmahi 👍 1 Answered D

Using Amazon S3 for storage and AWS Lake Formation for fine-grained access control like row-level or column-level access.
cas_tori 👍 3 Answered D

this id D

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Practice All DEA-C01 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DEA-C01 Practice Test →

← Back to DEA-C01 Study Guide