I85PREP
⌘ K
CCAS study materials
CCAS study resources

CCAS: Identity, Authentication, and Access Management for Cloud Applications

CCAS · Work through your exam, one topic at a time.

All guide sections

Identity, Authentication, and Access Management for Cloud Applications

This domain tests whether you can separate authentication from authorization and design least-privilege access for three populations: workforce users, workloads, and customers. Most exam items hinge on choosing short-lived, federated credentials over static secrets and on scoping policy to specific resources rather than whole accounts.

Core rules

  • Keep the three identity types distinct. Workforce identity federates to the enterprise IdP via SAML 2.0 or OIDC with MFA, ideally phishing-resistant (FIDO2/passkeys). Workload identity uses roles, service accounts, or OIDC workload identity federation. Customer identity (CIAM) supports self-service registration with adaptive risk signals.
  • Prefer short-lived credentials: STS tokens, instance profiles, and federation with subject and audience conditions. Long-lived access keys are the recurring root cause of cloud breaches.
  • Layer authorization. RBAC gives coarse role assignment; ABAC and policy-as-code give attribute-level decisions. Permission boundaries, service control policies, and organization policies cap the maximum privilege any principal can hold.
  • Protect privileged access: no daily use of root/global admin, hardware MFA on break-glass accounts, just-in-time elevation with approval, and alerting on every break-glass use.
  • Write trust policies narrowly. Specify the exact principal, add conditions such as an ExternalId or source-account constraint, and never trust an entire account with root unless conditions restrict who can assume.

Worked example

A CI/CD pipeline in account A deploys into account B. The naive setup puts access keys in the repository. The correct setup gives the pipeline a role in account A via OIDC federation from the CI platform (scoped to repository and branch), and account B's deployment role trusts only that pipeline role ARN with an ExternalId condition. If instead B's trust policy lists account A's root with no conditions, any principal in A - including a compromised developer role - can assume the deployment role. That is the confused-deputy pattern and a direct lateral-movement path.

Traps

Confusing roles with policies (a role is an identity, a policy is a document attached to it); assuming IdP MFA covers programmatic access; using * in the resource element; leaving departed users in group mappings; and treating OAuth scopes as sufficient authorization for object-level access.