Identity And Access Governance — AWS Solutions Architect Pro (SAP-C02)
'Corporate Directory' Maps to IAM Identity Center, Not IAM Users
'Corporate directory,' 'employees should use existing credentials,' and 'integrate with the company identity provider' all point to IAM Identity Center with an external IdP via SAML 2.0 or OIDC. Creating individual IAM users with long-lived access keys is the wrong answer for any workforce identity scenario at enterprise scale. Cross-account roles with external trust policies apply when the scenario specifies time-limited access for contractors or third-party partners. 'Joiners, movers, leavers' language signals that the identity lifecycle must be managed centrally, not by manually creating and rotating IAM credentials across individual accounts.
What This Pattern Tests
The exam presents access control scenarios and tests precise IAM mechanism selection. IAM roles with trust policies for cross-account access (no long-lived credentials). Identity Center (SSO) with permission sets for human access across multiple accounts. Permission boundaries to allow admins to create roles that cannot exceed a privilege ceiling. Resource-based policies on S3 buckets and KMS keys for cross-account resource sharing without assuming roles. The trap is creating IAM users with access keys for applications (use roles) or granting AdministratorAccess when a scoped policy suffices.
Decision Axis
Access pattern (service-to-service vs. human vs. cross-account vs. delegated admin) determines the IAM mechanism.
Associated Traps
More Top Traps on This Exam
Decision Rules
Whether to federate human identity at the organization level using IAM Identity Center permission sets (single control plane, unified audit trail, automatic propagation) or retain per-account SAML IAM role federation (distributed, operationally familiar, but ungovernable at 50-account scale when both centralized auditing and same-day policy propagation are explicit compliance constraints).
Domain Coverage
Difficulty Breakdown