DVA-C02 Federated Access and App Authorization Guide

This lesson covers the identity and permission logic that AWS expects application developers to get right. The exam often mixes user login, token-based access, IAM roles, signed AWS requests, and record-level authorization into one scenario so that weak candidates confuse authentication with authorization.

Bearer token: Token presented by the client to prove authenticated access, where possession of the token is enough to use it.

Federated access: Access model where an external or managed identity provider authenticates the user and the application trusts that identity assertion.

What AWS is really testing here

AWS wants you to distinguish:

• user authentication from service-to-service authentication
• identity-provider flows from raw IAM user credential use
• broad allow patterns from least-privilege role assumptions
• application-level authorization from simple login success
• request signing from human sign-in

Choose the right auth lane

Authentication and authorization are different questions

    flowchart TD
	    A["User or workload needs access"] --> B{"Who is calling?"}
	    B -->|"Human user"| C["Use identity provider or federated login"]
	    B -->|"AWS-hosted workload"| D["Assume IAM role with temporary credentials"]
	    C --> E["Authenticate successfully"]
	    D --> F["Sign AWS requests correctly"]
	    E --> G["Apply application-level authorization"]
	    F --> G

Strong answers usually split the problem into:

• Who is this?
• How does this caller prove identity?
• What is this caller allowed to do?

If an answer only solves the first question, it often misses the real control.

Roles beat long-term app secrets

For developer questions, DVA-C02 strongly prefers temporary credentials through roles over embedding static access keys in config or source. If the stem says an application on AWS needs to call another AWS service, the stronger default is usually an assumed role or service role with the narrowest needed permissions.

Small Python example using the normal runtime credential chain:

1import boto3
2
3s3 = boto3.client("s3")
4
5def list_user_exports(bucket: str, prefix: str) -> list[str]:
6    response = s3.list_objects_v2(Bucket=bucket, Prefix=prefix)
7    return [obj["Key"] for obj in response.get("Contents", [])]

The point is not the boto3 syntax itself. The point is that the code relies on the runtime role instead of embedded long-term access keys.

Fine-grained authorization still belongs in the app

Authentication only proves identity. Authorization decides what that identity may do. DVA-C02 uses this distinction constantly in multi-tenant or user-specific access questions. A valid bearer token does not automatically mean the user should see every record.

If the app trusts a caller-supplied tenantId without checking it against trusted identity context, the failure is usually authorization logic, not login logic.

Cross-service authentication in microservices

Current Domain 2 explicitly includes cross-service authentication patterns. Keep the main lesson simple:

• each workload should use its own runtime role when possible
• downstream AWS API calls should be signed with the right principal
• one microservice authenticating a user does not automatically authorize another microservice to return every dataset

If the scenario involves several services inside one application, do not flatten everything into “the app is already authenticated.”

Common traps

Decision order that usually wins

1. Separate identity proof, runtime AWS access, and application authorization.
2. If AWS-hosted code needs to call AWS services, think IAM role with temporary credentials.
3. If users are authenticated but can see the wrong records, stay in the authorization and tenant-scoping lane.
4. Keep authentication and authorization distinct because DVA-C02 tests that boundary repeatedly.
5. Prefer the narrowest role or policy that still lets the app function safely.

Quiz