Data Security and Governance
Authentication and Workload Identity
CoreEstablish network reachability, workload identity, credential rotation, role trust, endpoint and resource policy boundaries, service ownership, and SageMaker Unified Studio domains and projects.
Aligned to AWS Certified Data Engineer - Associate (DEA-C01) Version 1.1, verified August 25, 2026.
Why this matters
A data job can fail before authorization is evaluated: the network path may be closed, a role may not trust the service, or a credential may be stale. Authentication and reachability must be diagnosed at their actual layer.
Must Know
- A security group permits network traffic; it does not grant AWS API or database privileges. Prefer an exact source security group, protocol, and port over a broad internet CIDR.
- An IAM role needs both a trust policy that allows the intended service or principal to assume it and permission policies for allowed actions.
- Attach the workload role to Lambda, Glue, API Gateway integration, CloudFormation, or other execution surface instead of embedding long-term user keys.
- Use Secrets Manager for managed credential storage and rotation when the database or application integration supports the rotation workflow; retrieve the current value at runtime.
- PrivateLink or a VPC endpoint provides private connectivity, while endpoint and resource policies can further restrict principals and resources. Private networking alone is not authorization.
- Managed services reduce selected infrastructure operations but the customer still owns data, identities, configuration, access, and workload correctness.
- SageMaker Unified Studio uses domains, domain units, and projects to organize teams, assets, and governed work; membership and subscription workflows still control access.
Compare and Distinguish
- Security group versus IAM policy versus database grant: reachability, AWS authorization, and database authority are cumulative layers.
- Role trust policy versus permission policy: who may assume the role differs from what an assumed role may do.
- Private endpoint versus endpoint policy: path differs from allowed API resources and principals.
- Managed versus unmanaged service: operational responsibility differs, not data ownership.
Scenario examples
- A private Glue job reaches an RDS database after the database security group allows the Glue connection security group and the job retrieves an authorized secret.
- A Lambda role trusts Lambda and grants only needed S3 and Glue actions.
- Two business areas use separate domain units and governed project subscriptions instead of one global shared project.
Exam traps
- Opening a database to the internet to solve a role problem.
- Attaching permissions to a role whose trust policy does not allow the workload to assume it.
- Assuming private connectivity authorizes every bucket.
- Treating managed as meaning AWS owns customer data and policies.
Key takeaways
- Diagnose network, identity, and authorization separately.
- Use temporary workload roles and rotated secrets.
- Apply policies at every relevant boundary without widening scope.
How it works
- The workload reaches an endpoint, assumes or receives its identity, and presents the resulting credentials to each protected service.
- Every hop evaluates its own network, trust, IAM, resource, database, or data-governance control.
When to use it
- Use workload roles for Lambda, Glue, and other execution surfaces instead of long-lived user keys.
- Use Secrets Manager when application credentials need managed retrieval and rotation, and PrivateLink when the supported service needs a private path.
Security and governance implications
- Limit role trust to intended services or principals and scope permissions to the specific actions and resources required.
- Rotate stored credentials without code changes and verify clients retrieve the current value rather than caching an obsolete secret.
Common failure modes and diagnosis
- Trace a connection in order through DNS and route, security group, endpoint policy, role trust, IAM permission, secret, and data grant.
- For access lost after rotation, compare secret version, client refresh behavior, database credential state, and execution-role access.
More detail
- 4.1.1: Update VPC security groups.
- 4.1.2: Create and update IAM groups, roles, endpoints, and services.
- 4.1.3: Create and rotate credentials for password management (for example, AWS Secrets Manager).
- 4.1.4: Set up IAM roles for access (for example, AWS Lambda, Amazon API Gateway, AWS CLI, AWS CloudFormation).
- 4.1.5: Apply IAM policies to roles, endpoints, and services (for example, S3 Access Points, AWS PrivateLink).
- 4.1.6: Describe the differences between managed services and unmanaged services.
- 4.1.7: Use domain, domain units, and projects for SageMaker Unified Studio.
Ready for the quiz?
- Which principal is connecting, how does it assume or obtain its identity, and which separate layer authorizes the requested action?
- Is the failure caused by routing, a security group, role trust, role permissions, a secret, or a database or data grant?
Related objectives
- D4.1 — Task 4.1: Apply authentication mechanisms
- 4.1.1 — Update VPC security groups.
- 4.1.2 — Create and update IAM groups, roles, endpoints, and services.
- 4.1.3 — Create and rotate credentials for password management (for example, AWS Secrets Manager).
- 4.1.4 — Set up IAM roles for access (for example, AWS Lambda, Amazon API Gateway, AWS CLI, AWS CloudFormation).
- 4.1.5 — Apply IAM policies to roles, endpoints, and services (for example, S3 Access Points, AWS PrivateLink).
- 4.1.6 — Describe the differences between managed services and unmanaged services.
- 4.1.7 — Use domain, domain units, and projects for SageMaker Unified Studio.