DEA-C01 Authorization, Least Privilege and Lake Formation Guide

This lesson is about who is allowed to do what. DEA-C01 expects you to move beyond “just give broad access” and toward custom policies, role-based decisions, tag-based or attribute-based access, and data-lake authorization through Lake Formation.

Authorization: Decision about what an already identified principal is allowed to do.

Lake Formation grant: Permission model for governed data-lake resources such as databases, tables, and columns.

Least privilege: Grant only the actions and resources needed for the specific workload or user.

What AWS is really testing here

AWS wants you to separate:

• authentication from authorization
• broad IAM access from targeted least-privilege design
• lake governance from generic object-store access
• data-lake permission scope from infrastructure-admin scope

DEA-C01 often hides the right answer behind “the user can already sign in.” The real question is usually which layer should grant the data access and how narrow that grant should be.

Authorization chooser

IAM and Lake Formation are not interchangeable

Control-stack mental model

    flowchart LR
	  A["Principal"] --> B["IAM role or policy"]
	  B --> C{"Needs governed lake data?"}
	  C -->|Yes| D["Lake Formation grants"]
	  C -->|No| E["Other AWS service access"]
	  D --> F["Databases, tables, columns"]

The key thing to notice is that IAM and Lake Formation do different jobs. IAM can allow the principal into the AWS control plane, while Lake Formation can further govern which data resources are actually visible and usable.

IAM versus Lake Formation

How strong DEA-C01 answers usually reason

1. Ask whether the problem is baseline AWS access or governed lake-data access.
2. Use custom IAM policies when managed policies are too broad.
3. Use Lake Formation when the scope is governed databases, tables, or columns.
4. Keep least privilege as the default, even when broader access would be faster.
5. Avoid assuming that successful authentication means the user should automatically see all data.

Decision order that usually wins

When authorization answers overlap, use this order:

1. Decide whether the issue is baseline AWS access, governed lake access, or scope reduction.
2. If the role needs broad AWS service permissions, stay in the IAM lane.
3. If the question is about databases, tables, or columns in the lake, move to Lake Formation.
4. If managed policies are close but still too broad, prefer a custom least-privilege policy.
5. Assume authentication success is only the beginning, not the end of data authorization design.

Least-privilege thinking for data teams

Common tie-breaks

Common traps

Harder scenario question

A data engineering team can already authenticate into AWS, but analysts should only query specific governed datasets and should not receive broad lake-wide access. What is the strongest reading first?

• A. Give the analyst role administrator access
• B. Keep the IAM role narrow and use Lake Formation grants for the governed datasets
• C. Move the data to Route 53
• D. Disable logging so policy evaluation is simpler

Correct answer: B. DEA-C01 expects layered authorization, where IAM stays narrow and Lake Formation grants govern access to the actual lake resources.

Quiz