PCAM study materials
PCAM study resources

PCAM: Security, Identity, and Compliance

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

All guide sections

Security, Identity, and Compliance

Security, Identity, and Compliance

This domain tests identity as the primary control plane, encryption and key custody, guardrails versus approval gates, and how you produce audit evidence without rebuilding controls per workload. Expect scenarios about a compromised credential, a public bucket, or an auditor asking who accessed what and when.

Identity fundamentals

  • Federate human access through the corporate identity provider using SAML 2.0 or OIDC. Per-person cloud accounts create an offboarding problem you will lose.
  • Authorize with roles bound at the highest sensible scope; keep break-glass identities separate, monitored, and time-limited.
  • Workloads must not hold static keys. Use workload identity federation or service-account impersonation so pipelines and pods receive short-lived credentials scoped by repository, branch, or namespace claims.
  • Require MFA for all human access and conditional access for privileged roles.

Guardrails beat gates

  • Organization policies and service control policies deny forbidden states - public storage, unapproved regions, disabled audit logging - regardless of who is deploying.
  • Layer the controls: preventive (deny at the API), detective (configuration scanning, CSPM), responsive (automated remediation).
  • Encryption at rest by default, with customer-managed keys where regulation requires you to hold custody; TLS 1.2 or later in transit; rotate keys and separate key administration from data access.
  • Map controls once to a framework (SOC 2, ISO 27001, PCI DSS, HIPAA) and inherit them: an org-level control satisfies every workload beneath it.
  • Ship admin and data-access audit logs to a separate, restricted account with retention lock so a compromised workload cannot delete its own evidence.

Worked example

A CI/CD pipeline must deploy to production with no stored credentials. Create a workload identity pool that trusts the CI provider's OIDC issuer, restrict trust to a specific repository and branch claim, map it to a role holding only deploy permissions, and cap session duration at one hour. Delete any service-account JSON keys. Result: there is no long-lived secret to leak, and revocation becomes a claim change instead of rotating keys across dozens of pipelines.

Traps that cost marks

  • Using a shared admin identity for automation, destroying attribution and rotation.
  • Treating network segmentation as a substitute for authorization.
  • Granting broad editor/owner roles because fine-grained roles take longer to model.
  • Enabling logging but storing it where the compromised principal can delete it.