Security, Identity, and Compliance
Domain 4 - Security, Identity, and Compliance. This domain tests least-privilege IAM, data protection, auditability, and how shared responsibility maps to compliance evidence.
IAM building blocks
IBM Cloud IAM controls access through policies. A policy combines a subject (user, service ID, access group, or trusted profile), a target (account, resource group, or resource), and a role. Platform roles govern resource lifecycle, such as Viewer, Editor, Operator, and Administrator; service roles govern data-plane actions, such as Reader, Writer, and Manager. Access groups simplify assignment; trusted profiles federate identities without long-lived keys. API keys authenticate programs and should be rotated. MFA and SSO strengthen human authentication.
Data protection and compliance
Key Protect or Hyper Protect Crypto Services manage encryption keys; Secrets Manager stores credentials; Activity Tracker records account activity; Log Analysis supports investigation. Security and Compliance Center assesses posture and gathers evidence. Compliance is shared: IBM secures the underlying cloud, while you secure configurations, identities, data, and workloads.
Worked example
A CI pipeline must read images from a registry but not delete them. Create a service ID, assign a service-level Reader role scoped to the specific resource group, store its API key in Secrets Manager, and record pipeline activity. Do not give Administrator at account level; that violates least privilege and broadens blast radius.
Traps
Platform and service roles are not interchangeable; a resource group is a management scope, not a security boundary by itself; the account owner is powerful and should not be used for daily work; and audit logs do not replace preventive controls.