How to Separate Athena Query Access and Query History?

DEA-C01 By islever Editorial Last updated

Apply authorization mechanisms. Analyze data by using AWS services.

Short answer

B Create an Athena workgroup per use case and use tag-based IAM policies to isolate query processes and query history.

Question

A company uses Amazon Athena for one-time queries against data that is in Amazon S3. The company has several use cases. The company must implement permission controls to separate query processes and access to query history among users, teams, and applications that are in the same AWS account. Which solution will meet these requirements?
  1. Create an S3 bucket for each use case. Create an S3 bucket policy that grants permissions to appropriate individual IAM users. Apply the S3 bucket policy to the S3 bucket.
  2. Create an Athena workgroup for each use case. Apply tags to the workgroup. Create an IAM policy that uses the tags to apply appropriate permissions to the workgroup. Correct Answer
  3. Create an IAM role for each use case. Assign appropriate permissions to the role for each use case. Associate the role with Athena.
  4. Create an AWS Glue Data Catalog resource policy that grants permissions to appropriate individual IAM users for each use case. Apply the resource policy to the specific tables that Athena uses.

Key Takeaways

This question tests that Athena workgroups—not IAM roles, S3 bucket policies, or Glue Data Catalog resource policies—are the isolation boundary for query processes and query history; the trap is assuming a per-use-case IAM role is enough.

Athena workgroups isolate query execution and query history across users, teams, and applications in a single AWS account. The correct solution (B) creates one workgroup per use case and uses tag-based IAM policies to grant access to the right workgroup.

Common mistake: A common wrong answer is C: creating an IAM role per use case feels like least privilege, but an IAM role does not create an Athena workgroup boundary or separate query history.

Expert Analysis

Why the Answer Is Correct

Athena workgroups are the native AWS mechanism for isolating query execution, query history, and per-workgroup settings such as data-usage controls and query result locations. Creating a workgroup per use case gives each team or application its own query history boundary inside the same AWS account. Tags on the workgroup then let a single IAM policy grant Allow or Deny permissions scoped to the matching workgroup, which directly satisfies the requirement to separate query processes and query-history access. Option B is therefore the only choice that uses the Athena-level isolation boundary the question is asking for. This matches the AWS guidance for user-created workgroups.

Why the Other Options Are Wrong

Option A applies an S3 bucket policy to grant individual IAM users access to data, but S3 policies control object access, not Athena query processes or query history, and per-user bucket policies are brittle at team scale. Option C creates an IAM role per use case and associates it with Athena, which controls which AWS API actions a principal can call but does not create a workgroup boundary, so users still share query history and workgroup settings. Option D applies an AWS Glue Data Catalog resource policy to tables, which governs metadata and table access rather than the Athena query history that must be separated among users, teams, and applications in one account. None of these alternatives provides the workgroup-level isolation that the scenario requires.

Community Comment Notes

Multiple learners converge on B: milofficial notes the item was reused from the old Data Analytics Specialty and points to the AWS user-created-workgroups documentation. TonyStark0122 explains that "Athena workgroups allow you to isolate and manage different workloads" and lists permissions and query-history control as the key benefits. k350Secops calls out C as the confusing distractor, saying it "would not provide the necessary isolation and access control" for query processes and history. dev_vicente adds simply that B is more granular, and every recorded vote in the thread selects B.

Official Reference

https://docs.aws.amazon.com/athena/latest/ug/user-created-workgroups.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

When a DEA-C01 question mentions separating Athena query history or per-team query controls in one account, look for workgroups plus tag-based IAM policies. Eliminate options that only control S3 objects, Glue table metadata, or IAM roles, because they never partition the query history that Athena keeps at the workgroup level.

Frequently Asked Questions

Why can't separate IAM roles per use case isolate Athena query history?

IAM roles control which AWS API actions a principal can call, but they do not partition Athena's workgroup-level query history or enforce per-workgroup query limits.

What do tags on an Athena workgroup enable in IAM policies?

Tags let an IAM policy scope Allow or Deny statements to specific workgroups, so users in one account can only run queries and view history for their own use case.

More DEA-C01 FAQ →

Community Votes

B
100%

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

Discussion 6 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 6

  1. milofficial 👍 17 Answered B
    Haha they copied this from the old DA Specialty. It's B https://docs.aws.amazon.com/athena/latest/ug/user-created-workgroups.html
  2. TonyStark0122 👍 14
    B. Create an Athena workgroup for each use case. Apply tags to the workgroup. Create an IAM policy that uses the tags to apply appropriate permissions to the workgroup. Explanation: Athena workgroups allow you to isolate and manage different workloads, users, and permissions. By creating a separate workgroup for each use case, you can control access to query history, manage permissions, and enforce resource usage limits independently for each workload. Applying tags to workgroups allows you to categorize and organize them based on the use case, which simplifies policy management.
  3. k350Secops 👍 2 Answered B
    The only other answer that's confusing is C But its not the one. Creating separate IAM roles for each use case and associating them with Athena would not provide the necessary isolation and access control for query processes and query history.
  4. Manohar24 👍 2 Answered B
    B is correct.
  5. dev_vicente 👍 1 Answered B
    B is more granular
Show 1 more comment
  1. Scotty_Nguyen 👍 1 Answered B
    B is correct

Reader comments & corrections

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

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Amazon Redshift Compound Sort Key Query Optimization

S-grade

Secure Redshift Spectrum Access with VPC Endpoints

S-grade

Athena Federated Query for Multi-Source Iceberg Pipelines

S-grade

Reclaiming Storage in Amazon Redshift Materialized Views

S-grade

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