DOP-C02 Security and Compliance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Use AWS Organizations and AWS IAM Identity Center (AWS SSO) to manage users centrally.

  Why this is correct

  AWS IAM Identity Center (formerly AWS SSO) integrates natively with AWS Organizations, providing a single place to manage users and groups and then assign them access across multiple AWS accounts. It uses permission sets to define IAM policies that are applied consistently to accounts, and it issues short-term AWS credentials, eliminating the need to create and rotate IAM users. This is the only option that genuinely centralizes user management while preserving fine-grained, auditable access control.

• ✗

  Create the same IAM users in each account with identical permissions.

  Why it's wrong here

  Recreating identical IAM users in every account duplicates identity data and introduces operational drift. Each duplicate user must receive its own set of access keys, password policy, and MFA devices, and if one account is updated, the others are easily forgotten, creating security and access inconsistencies. It also brings a proliferation of long-lived credentials and increases the blast radius of a compromised password, so it is neither scalable nor secure.

• ✗

  Create IAM roles in each account and allow cross-account access from a central account.

  Why it's wrong here

  While cross-account roles with a central account can simplify the access path, the central account still needs its own IAM users or identity source to authenticate the principals. User creation, deletion, password management, and MFA must be handled separately for every identity in the central account, and users cannot be governed uniformly across accounts without a centralized identity service. This approach centralizes access paths but not user management, leaving the original problem unsolved.

• ✗

  Use IAM federation with an external identity provider and assign permissions based on SAML attributes.

  Why it's wrong here

  IAM federation with an external identity provider authenticates users against an IdP you already control, but it does not create or manage IAM users inside AWS. SAML attributes can map to IAM roles for dynamic permission assignment, yet user lifecycle, group membership, and attribute governance remain external responsibilities. Because the federation setup only grants access based on attributes, it lacks a central place within AWS to administer users and does not centralize IAM user management itself.

Go deeper

Related to this question