Cloud Security Fundamentals and Governance
The shared responsibility split
IBM secures facilities, hypervisors, the network fabric, and the managed-service platform itself. You own identity configuration, network rules, key custody, data classification, and workload hardening. A managed database does not transfer responsibility for who holds Administrator on it.
Account structure is a governance boundary
An IBM Cloud account is the billing and IAM boundary. Resource groups inside the account organize resources for access control and quota; a policy scoped to a resource group covers every resource placed in it. Legacy Cloud Foundry orgs and spaces use a separate role model and do not map to IAM roles. Tags support inventory and cost reporting, not authorization decisions.
Controls to layer, not substitute
Least privilege through access groups; separation of duties between key custodians and platform administrators; encryption in transit and at rest with customer-managed keys; context-based restrictions that limit API access to defined network zones; Security and Compliance Center scans to produce evidence against a chosen profile.
Worked example
A team must isolate dev from prod. Create two resource groups. Federate the corporate IdP and map IdP groups to access groups instead of writing per-user policies. Grant Editor on the dev group and Viewer on prod. Add a context-based restriction so prod's API endpoint is reachable only from the corporate network zone. Run a Security and Compliance Center scan to prove no bucket is public.
Traps that cost marks
A resource group is an access-control and quota boundary, not a network boundary. Editor cannot grant access, so candidates over-grant Administrator to fix a permissions error. IBM's certifications cover IBM's platform, never your configuration. Cloud Foundry space roles are not IAM service roles.