Exam Context #
- Exam: AWS SAP-C02
- Scenario Category: Identity & Access Management
- Decision Focus: Centralized identity federation vs distributed IAM management
The SAP-C02 exam tests your ability to design enterprise-scale identity architectures that integrate with existing corporate identity systems. These scenarios require understanding federation protocols, IAM Identity Center capabilities, and the trade-offs between different identity integration patterns.
👉🏻 Read more pillar articles at Pillars
| Exam Aspect | Details |
|---|---|
| Question Frequency | 8-12% of exam content |
| Primary Services | IAM Identity Center, IAM Identity Providers, STS |
| Common Scenarios | Multi-account SSO, workforce federation, application identity |
| Key Protocols | SAML 2.0, OIDC, OAuth 2.0 |
| Integration Points | Active Directory, Okta, Azure AD, Ping Identity |
Why SAP-C02 Tests Identity Federation #
Enterprise identity management is foundational to AWS security architecture. Organizations cannot effectively manage AWS access through individual IAM users—the scale makes this approach operationally unsustainable and security-risky. SAP-C02 tests identity federation because it represents how real enterprises manage AWS access.
| Challenge | Single-Account IAM Users | Federated Identity |
|---|---|---|
| User Lifecycle | Manual creation/deletion per account | Automatic via IdP sync |
| Password Management | Per-account credentials | Single corporate credential |
| MFA Enforcement | Per-account configuration | Centralized IdP policy |
| Access Revocation | Must update each account | Single IdP action |
| Audit Trail | Distributed across accounts | Centralized identity logs |
| Compliance | Difficult to demonstrate | Clear identity governance |
Typical enterprise contexts in SAP questions include:
Workforce identity consolidation where organizations with existing identity providers (Active Directory, Okta, Azure AD) need to extend corporate identity to AWS access. These scenarios test whether you understand the integration patterns and protocol choices.
Multi-account access management where users need access to multiple AWS accounts with different permission levels. These questions probe understanding of IAM Identity Center’s permission set model versus per-account federation.
Compliance and audit requirements where organizations must demonstrate identity governance for regulatory compliance. These scenarios test whether you can design identity architectures that provide clear audit trails and access certification.
Merger and acquisition integration where organizations must rapidly integrate acquired company identities into existing AWS governance. These questions test understanding of identity source options and migration patterns.
Core Identity Federation Concepts #
Federation Protocols #
AWS supports multiple federation protocols, each with specific use cases and characteristics:
| Protocol | Primary Use Case | Token Type | AWS Integration |
|---|---|---|---|
| SAML 2.0 | Workforce SSO | XML Assertion | IAM Identity Provider, Identity Center |
| OIDC | Modern applications, CI/CD | JWT | IAM Identity Provider, Cognito |
| OAuth 2.0 | API authorization | Access Token | Cognito, API Gateway |
| Custom Identity Broker | Legacy systems | STS Credentials | AssumeRole, GetFederationToken |
SAML 2.0 remains the dominant protocol for workforce federation. It provides mature tooling, broad identity provider support, and well-understood security characteristics. SAP scenarios involving corporate user access to AWS typically assume SAML federation.
OIDC is increasingly common for modern applications and CI/CD pipelines. GitHub Actions, GitLab CI, and other platforms use OIDC to obtain AWS credentials without storing long-term secrets. SAP scenarios involving automated deployments often feature OIDC federation.
Custom identity brokers are legacy patterns that should be recognized but not recommended for new implementations. These involve custom code that authenticates users and calls STS to obtain credentials. Modern scenarios should use standard protocols.
IAM Identity Center Architecture #
IAM Identity Center (formerly AWS SSO) provides centralized identity management for AWS Organizations:
| Component | Purpose | Configuration Scope |
|---|---|---|
| Identity Source | Where users are defined | Organization-wide |
| Permission Sets | What access users receive | Applied per account |
| Account Assignments | Which users access which accounts | Per account/group |
| Access Portal | User interface for account access | Organization-wide |
| MFA Settings | Multi-factor authentication requirements | Organization-wide |
Identity sources determine where user identities are managed. Options include:
- Identity Center directory: Built-in directory for organizations without existing IdP
- Active Directory: Direct connection to on-premises or AWS Managed AD
- External identity provider: SAML 2.0 federation with providers like Okta, Azure AD, or Ping
Permission sets define the IAM permissions users receive when accessing accounts. Permission sets are templates—they create IAM roles in target accounts when assigned. A single permission set can be assigned to multiple accounts, ensuring consistent permissions.
Account assignments connect users or groups to accounts with specific permission sets. This three-way relationship (identity → account → permission set) provides flexible access management.
Direct IAM Federation #
For scenarios not involving IAM Identity Center, direct IAM federation uses IAM identity providers:
| Federation Type | IAM Resource | Trust Relationship | Use Case |
|---|---|---|---|
| SAML Federation | SAML Provider | IAM Role trusts SAML provider | Workforce access without Identity Center |
| OIDC Federation | OIDC Provider | IAM Role trusts OIDC provider | CI/CD, mobile apps, web identity |
| Cross-Account | None (AWS account) | IAM Role trusts another account | Service-to-service access |
Direct federation is appropriate when:
- Organization does not use AWS Organizations
- Single-account access is sufficient
- Specific trust relationships are required that Identity Center cannot express
- Application workloads need AWS access (not workforce users)
Common SAP Exam Traps #
Confusing Identity Center with Cognito #
SAP scenarios may present identity requirements that could involve either IAM Identity Center or Amazon Cognito. The distinction is critical:
| Aspect | IAM Identity Center | Amazon Cognito |
|---|---|---|
| Primary Users | Workforce (employees) | Application users (customers) |
| Scale | Thousands of users | Millions of users |
| Integration | AWS Console, CLI, APIs | Custom applications |
| Identity Source | Corporate IdP | Social, SAML, user pools |
| Billing Model | Free | Per-MAU pricing |
| Account Scope | Multi-account | Single application |
The trap is selecting Cognito for workforce scenarios or Identity Center for customer-facing applications. Read scenarios carefully to identify whether users are employees or customers.
Assuming SAML is Always Required #
Modern scenarios increasingly use OIDC, particularly for:
| Scenario | Recommended Protocol | Rationale |
|---|---|---|
| GitHub Actions deploying to AWS | OIDC | Native support, no stored secrets |
| GitLab CI/CD pipelines | OIDC | Native support, short-lived credentials |
| Kubernetes service accounts | OIDC (IRSA) | Pod-level identity without node credentials |
| Mobile applications | OIDC | Modern protocol, better mobile support |
| Traditional workforce SSO | SAML | Mature tooling, broad IdP support |
The trap is selecting SAML-based solutions for CI/CD scenarios when OIDC provides better security (no stored credentials) and simpler implementation.
Overlooking Permission Set Limitations #
Permission sets have characteristics that affect architectural decisions:
| Limitation | Impact | Workaround |
|---|---|---|
| Maximum 20 permission sets per account assignment | May need multiple assignments for complex access | Group users by access pattern |
| Session duration maximum 12 hours | Long-running processes may need credential refresh | Use IAM roles for long processes |
| Permission set changes require reprovisioning | Updates are not instant | Plan for propagation delay |
| Customer managed policies limited to 10 per permission set | Complex permissions may exceed limit | Use inline policies or consolidate |
The trap is designing permission sets that exceed these limits or assuming permission set changes take effect immediately.
Misunderstanding Identity Source Constraints #
IAM Identity Center supports only one identity source at a time:
| Identity Source | Can Coexist With | Migration Path |
|---|---|---|
| Identity Center Directory | None | Export users, import to new source |
| Active Directory | None | Change source, reassign users |
| External IdP | None | Change source, reassign users |
The trap is designing architectures that assume multiple identity sources can be connected simultaneously. Scenarios involving multiple identity providers require either:
- Consolidating identities in a single IdP before connecting to Identity Center
- Using direct IAM federation for some user populations
- Implementing identity broker patterns
Decision Framework (Architect View) #
Selecting Identity Architecture #
The primary decision is whether to use IAM Identity Center or direct federation:
Selecting Identity Source #
When using IAM Identity Center, identity source selection follows this logic:
| Scenario | Recommended Source | Rationale |
|---|---|---|
| Existing Okta/Azure AD/Ping | External IdP with SCIM | Leverage existing investment, automatic sync |
| Existing on-premises AD | AD Connector | Direct integration, no sync required |
| Existing AWS Managed AD | AWS Managed AD | Native integration |
| No existing IdP, small org | Identity Center Directory | Simplest option |
| No existing IdP, large org | Consider external IdP | Better scalability, features |
Permission Set Design #
Permission sets should follow least-privilege principles while remaining manageable:
| Permission Set Pattern | Use Case | Example |
|---|---|---|
| Job Function | Role-based access | Developer, DBA, NetworkAdmin |
| Environment-Specific | Different access per environment | ProdReadOnly, DevFullAccess |
| Service-Specific | Access to specific services | S3Admin, EC2Operator |
| Temporary Elevated | Break-glass access | EmergencyAdmin |
Integration Patterns #
Active Directory Integration #
Organizations with Active Directory have multiple integration options:
| Integration Method | Architecture | Latency | Management |
|---|---|---|---|
| AD Connector | Proxy to on-premises AD | Network dependent | Minimal |
| AWS Managed AD | Full AD in AWS | Low | AWS managed |
| AD on EC2 | Self-managed AD in AWS | Low | Self-managed |
| Azure AD via SAML | Federation to Azure AD | Internet dependent | Azure managed |
SCIM Provisioning #
System for Cross-domain Identity Management (SCIM) automates user provisioning:
| SCIM Capability | Benefit | Consideration |
|---|---|---|
| Automatic user creation | No manual provisioning | IdP must support SCIM |
| Automatic user deactivation | Immediate access revocation | Sync frequency matters |
| Group synchronization | Consistent group membership | Group mapping required |
| Attribute mapping | Consistent user attributes | Attribute schema alignment |
CI/CD Pipeline Integration #
Modern CI/CD pipelines should use OIDC federation rather than stored credentials:
Advanced Patterns #
Attribute-Based Access Control (ABAC) #
IAM Identity Center supports ABAC through attribute propagation:
| Attribute Source | Propagation Method | Use Case |
|---|---|---|
| IdP attributes | SAML assertions | Department-based access |
| Identity Center attributes | Session tags | Cost center tagging |
| Group membership | Group-based assignments | Role-based access |
Emergency Access Patterns #
Break-glass procedures require special consideration:
| Pattern | Implementation | Audit |
|---|---|---|
| Emergency permission set | Separate high-privilege permission set | CloudTrail + alerts |
| Root account access | Secured root credentials | Root activity monitoring |
| Cross-account emergency role | Pre-provisioned emergency roles | Assume role logging |
| Temporary access elevation | Just-in-time access requests | Approval workflow logs |
Multi-Region Considerations #
IAM Identity Center has regional deployment considerations:
| Aspect | Behavior | Implication |
|---|---|---|
| Home Region | Single region deployment | All management in home region |
| Access Portal | Global endpoint | Users access from anywhere |
| Permission Sets | Deployed to all enabled regions | Consistent access globally |
| Failover | No automatic failover | Plan for regional outage |
Real-World Mapping #
In enterprise environments, identity architecture decisions reflect organizational context:
| Organization Type | Typical Pattern | Key Considerations |
|---|---|---|
| Enterprise with Okta | External IdP + SCIM | Leverage existing investment |
| Microsoft shop | Azure AD or AD Connector | Align with Microsoft ecosystem |
| Startup | Identity Center Directory | Simplicity, grow into IdP later |
| Regulated industry | External IdP + strong MFA | Compliance requirements |
| Acquisition scenario | Phased integration | Multiple identity sources temporarily |
SAP-C02 Takeaway Rules #
IF the scenario describes workforce users needing access to multiple AWS accounts, THEN IAM Identity Center is the appropriate solution—it provides centralized management with permission sets.
IF the scenario describes customer-facing application users, THEN Amazon Cognito is appropriate—IAM Identity Center is not designed for application user management.
IF the scenario involves CI/CD pipelines needing AWS access, THEN OIDC federation is preferred over stored credentials—it provides better security with no secret management.
IF the scenario mentions existing Active Directory, THEN evaluate AD Connector for direct integration or external IdP if Azure AD sync is in place.
IF the scenario requires immediate access revocation when employees leave, THEN SCIM provisioning with external IdP provides automatic deactivation.
IF the scenario involves a single AWS account without Organizations, THEN direct IAM federation may be simpler than deploying IAM Identity Center.
IF the scenario mentions multiple identity providers that must coexist, THEN recognize that Identity Center supports only one identity source—consolidate identities upstream in a single IdP or use direct IAM federation for separate user populations.
IF the scenario requires attribute-based access control across accounts, THEN IAM Identity Center with session tags enables ABAC—attributes from the IdP can be propagated to IAM sessions.
IF the scenario describes emergency or break-glass access requirements, THEN design separate emergency permission sets with enhanced monitoring—do not rely solely on regular access paths.
IF the scenario involves compliance requirements for access certification, THEN IAM Identity Center with external IdP provides the clearest audit trail—identity lifecycle is managed in the IdP with SCIM sync.
IF the scenario mentions Kubernetes workloads needing AWS access, THEN IAM Roles for Service Accounts (IRSA) using OIDC federation is the appropriate pattern—not IAM Identity Center.
IF the scenario requires different permission levels in different accounts for the same user, THEN multiple account assignments with different permission sets solve this—one user can have different access per account.
IF the scenario asks about session duration for federated users, THEN remember the maximum is 12 hours for Identity Center—longer processes need alternative credential mechanisms.
Summary #
Identity federation is foundational to enterprise AWS architecture. SAP-C02 tests your ability to select appropriate identity patterns based on user type, organizational structure, and operational requirements. The key distinctions to master are:
- IAM Identity Center for workforce access to multiple AWS accounts
- Amazon Cognito for customer-facing application authentication
- OIDC federation for modern CI/CD and workload identity
- Direct IAM federation for single-account or specialized scenarios
Understanding these patterns and their appropriate use cases will enable you to quickly identify correct answers in identity-focused SAP-C02 questions.