While preparing for the AWS SAP-C02, many candidates get confused by identity federation architectures for multi-account environments. In the real world, this is fundamentally a decision about centralized identity management vs. operational complexity vs. TCO. Let’s drill into a simulated scenario.
The Scenario #
GlobalManufacture Corp operates a hybrid cloud infrastructure with 47 AWS accounts organized under AWS Organizations. Their 12,000 employees authenticate against an on-premises Microsoft Active Directory deployment running on Windows Server 2019. The IT infrastructure team has established AWS Site-to-Site VPN connectivity between their primary datacenter and all production AWS VPCs.
The CISO has mandated a modernization initiative with the following requirements:
- Employees must use their existing AD credentials to access AWS resources
- Access control must be based on AD security groups and user attributes
- The identity source of truth must remain on-premises (regulatory constraint)
- Permission management must scale across all 47 accounts without creating duplicate IAM users
- Conditional access policies must be enforceable based on department and role attributes
Key Requirements #
Design a centralized identity federation solution that meets security compliance, minimizes operational overhead for the 8-person cloud platform team, and provides the lowest 3-year TCO.
The Options #
-
A) Deploy AWS IAM Identity Center (successor to AWS SSO), integrate it with on-premises Active Directory using SAML 2.0 federation; enable automatic user provisioning via SCIM v2.0 protocol; implement Attribute-Based Access Control (ABAC) for granting access to AWS accounts.
-
B) Deploy AWS IAM Identity Center, configure it to use IAM Identity Center’s internal directory as the identity source; enable automatic provisioning via SCIM v2.0 protocol; grant access to AWS accounts through IAM Identity Center permission sets.
-
C) In a central AWS account, configure AWS IAM with a SAML 2.0 identity provider; create individual IAM users mapped to federated identities; grant permissions based on corresponding AD groups; enable cross-account access through IAM user credentials.
-
D) In a central AWS account, configure AWS IAM with an OpenID Connect (OIDC) identity provider; create IAM roles that map to AD security groups; grant federated access to the central account; enable cross-account access through AssumeRole with IAM roles.
Correct Answer #
Option A.
The Architect’s Analysis #
Correct Answer #
Option A is the optimal solution.
Step-by-Step Winning Logic #
AWS IAM Identity Center (formerly AWS SSO) is purpose-built for multi-account access management in AWS Organizations environments. Here’s why Option A represents the best trade-off:
-
Native Integration with AWS Organizations: IAM Identity Center automatically discovers all accounts in the organization, eliminating the need to configure cross-account trust relationships manually (which Option D requires for 47 accounts = 94+ hours of engineering work).
-
SAML 2.0 Federation Preserves Identity Authority: Connecting to on-premises AD via SAML maintains AD as the authoritative source while enabling federated authentication, satisfying the regulatory constraint.
-
SCIM Automation Reduces Operational Toil: SCIM v2.0 enables automatic user/group synchronization from AD to IAM Identity Center, eliminating manual provisioning overhead (estimated 15 hours/month saved).
-
ABAC Provides Fine-Grained, Scalable Access Control: Using AD attributes (department, role, cost center) in permission sets enables dynamic access control without creating account-specific IAM roles. This scales linearly regardless of account count.
-
Zero Licensing Cost: IAM Identity Center is included with AWS Organizations at no charge, unlike third-party SSO solutions ($8-15/user/month = $96K-180K annually for 12,000 users).
The Traps (Distractor Analysis) #
Why not Option B?
- Violates the identity authority constraint: This option suggests using IAM Identity Center’s internal directory as the identity source, which would require duplicating all 12,000 users from AD into AWS. The requirement explicitly states “user identity must be managed in a single location” (on-premises AD).
- Operational overhead: Maintaining two identity sources creates synchronization complexity and violates the single source of truth principle.
- Compliance risk: Regulatory frameworks often mandate on-premises identity control for certain industries.
Why not Option C?
- Security anti-pattern: Creating IAM users mapped to federated identities contradicts the entire purpose of federation. This creates permanent credentials that must be rotated, violating the principle of temporary security credentials.
- Doesn’t scale: Managing 12,000 IAM users across 47 accounts = 564,000 potential user objects. This approach violates IAM service quotas (5,000 users per account) and best practices.
- Audit nightmare: Cross-account access via IAM users (instead of federation) creates fragmented CloudTrail logs, making identity-based auditing nearly impossible.
- Cost: Estimated 240 hours of manual provisioning work quarterly = $28,800/year in labor.
Why not Option D?
- OIDC is for web identity federation: OpenID Connect is designed for consumer identity providers (Google, Facebook) or custom JWT-based systems, not for enterprise Active Directory integration. AD natively supports SAML 2.0, not OIDC.
- Lacks SCIM support: OIDC-based federation requires custom user provisioning logic, while SAML + IAM Identity Center provides native SCIM integration.
- Complex cross-account implementation: You’d need to configure trust relationships and AssumeRole policies in all 47 accounts manually, with no centralized permission management.
- No ABAC support: Standard OIDC federation with IAM doesn’t support the attribute-based access control required for the conditional access policy requirement.
The Architect Blueprint #
Diagram Note: User authenticates against on-premises AD, receives a SAML assertion, which IAM Identity Center validates to grant temporary AWS credentials via permission sets that are automatically assigned to all organization accounts.
The Decision Matrix #
| Option | Est. Complexity | Est. 3-Year TCO | Pros | Cons |
|---|---|---|---|---|
| A: IAM Identity Center + SAML + SCIM | Low (Managed service, native integration) | $42K ($0 licensing + $42K labor: initial setup 80hrs @ $175/hr) | ✅ Purpose-built for AWS Orgs ✅ Zero licensing cost ✅ SCIM auto-provisioning ✅ Native ABAC support ✅ Centralized audit trail ✅ Temporary credentials only |
⚠️ Requires AD FS or equivalent SAML IdP ⚠️ Initial learning curve for ABAC policies |
| B: IAM Identity Center + Internal Directory | Medium (Dual identity management) | $312K ($270K sync labor + $42K setup) | ✅ No on-prem dependency ✅ Simple initial setup |
❌ Violates single identity source requirement ❌ Dual user management overhead ❌ Compliance risk ❌ No real-time AD attribute sync |
| C: SAML IdP + IAM Users | Very High (Manual, anti-pattern) | $421K ($86K setup + $335K ongoing user mgmt) | ⚠️ Familiar IAM user model | ❌ Security anti-pattern (static credentials) ❌ Violates IAM service quotas ❌ Massive operational overhead ❌ Fragmented audit logs ❌ Poor cross-account UX |
| D: OIDC + Cross-Account Roles | High (Custom development) | $583K ($92K setup + $491K custom dev/ops) | ✅ Temporary credentials ⚠️ Modern protocol |
❌ OIDC incompatible with AD natively ❌ No SCIM support ❌ Manual cross-account config (47 accounts) ❌ No centralized permission management ❌ Custom attribute mapping required |
Cost Assumptions:
- Labor rate: $175/hr (blended cloud architect + DevOps rate)
- IAM Identity Center: $0 (included with AWS Organizations)
- Option B sync labor: 20 hrs/month × 36 months × $175/hr = $126K (user provisioning/deprovisioning)
- Option C user management: 45 hrs/month × 36 months × $175/hr (manual role assignments across accounts)
- Option D custom development: 1,200 hrs initial + 600 hrs/year maintenance
Real-World Practitioner Insight #
Exam Rule #
For the SAP-C02 exam: When you see AWS Organizations + on-premises Active Directory + multi-account access, the answer is almost always AWS IAM Identity Center with SAML federation. If SCIM is mentioned alongside the need for automatic provisioning, that confirms it.
Keyword triggers:
- “AWS Organizations” + “centralized access” = IAM Identity Center
- “On-premises AD” + “single identity source” = SAML (not OIDC)
- “Automatic provisioning” + “AD” = SCIM v2.0
- “Attribute-based access” = ABAC via IAM Identity Center permission sets
Real World #
In production environments, I typically see three additional considerations not mentioned in certification scenarios:
-
Hybrid Directory Strategy: Many enterprises use Azure AD Connect to sync on-prem AD to Azure AD, then federate Azure AD with AWS IAM Identity Center via SAML. This provides a cloud-based identity control plane while maintaining on-prem AD as the source of truth. It also enables conditional access policies based on device compliance.
-
Permission Set Versioning: In the real world, we version permission sets in Git and deploy them via Infrastructure as Code (Terraform or CDK). The exam assumes you’ll use the console, but for 47 accounts, IaC is non-negotiable.
-
Break-Glass Access: Production implementations always include an emergency access mechanism (local IAM users with MFA in a sealed envelope) for scenarios where AD or the VPN connection fails. The exam rarely tests this operational reality.
-
Cost Optimization: For very large organizations (>50K users), some teams implement Just-In-Time (JIT) access using IAM Identity Center’s API + ServiceNow integration, which can reduce license costs for third-party PAM solutions by 60-70%.