What's changed: In-scope coverage (fix): added AWS WAF (L7 web protection; SQLi/XSS/rate-limit via IaC) to the Network Firewall block (closes an Axis-B textbook gap)
6.1Identity and Secrets Management
Understand authorization for pipelines and runtimes—IAM roles, temporary credentials, Secrets Manager/Parameter Store, and OIDC federation. Eliminate long-lived keys and run securely with least privilege.
DevOps automation wields powerful permissions. Avoid long-lived keys; operate safely with roles, temporary credentials, and secrets management.
6.1.1Authorization and secrets
- IAM roles + temporary credentials: services run via roles; never embed long-lived keys.
- Secrets Manager: store DB passwords/API keys with automatic rotation.
- Parameter Store (SecureString): centralize settings and light secrets (KMS-encrypted).
- OIDC federation: external CI (e.g., GitHub Actions) assumes roles without keys.
Common on DOP-C02: services use IAM roles + temporary credentials (no long-lived keys), secrets needing rotation = Secrets Manager, settings/light secrets = Parameter Store (SecureString), keyless authz from external CI = OIDC federation. From GitHub Actions to AWS, assume a role via OIDC.
DOP-C02 probes how to grant automation’s powerful permissions safely without long-lived keys. AWS services (CodeBuild/CodePipeline/Lambda/EC2/ECS tasks) get a service role / instance profile / task role and run with STS temporary credentials. Cross-account deploys AssumeRole from the CI/CD account into each environment account’s role, restricting the assumer via a trust policy. From external CI (e.g., GitHub Actions), use OIDC federation—register an IAM OIDC identity provider, condition the trust policy on sub (repo/branch), and assume a role without storing long-lived keys in GitHub. Split secrets: DB credentials needing rotation = Secrets Manager (Lambda rotation, RDS integration), settings/hierarchical params = Parameter Store (SecureString is KMS-encrypted). Have CodeBuild/CodePipeline reference secret ARNs in environment variables rather than holding plaintext values. Design permissions with least privilege, capping delegated permissions with a Permissions Boundary and org-wide guardrails with SCPs. Not embedding keys in code, not logging secrets, and rotating regularly are the operational disciplines that underpin DevOps security.
| Subject | Authz/storage method | Key point |
|---|---|---|
| AWS services | IAM role + temporary creds | No long-lived keys; least privilege |
| External CI (GitHub, etc.) | OIDC federation | Keyless role assumption; scope by sub |
| Secrets needing rotation | Secrets Manager | Auto-rotation; RDS integration |
| Settings / light secrets | Parameter Store (SecureString) | KMS-encrypted; hierarchical; cheap |
6.1.2Multi-account/app identity management (IAM Identity Center, Cognito, Directory Service)
These services manage user/device identity for organizations and apps. Choose based on the target (cross-account AWS vs app users vs existing AD integration). IAM Identity Center (formerly AWS SSO) provides centralized single sign-on (SSO) to multiple AWS accounts and business apps within an organization. Define permission sets and deploy them across accounts; federate with existing IdPs (Active Directory, Okta, etc.) via SAML 2.0 / SCIM. The typical DevOps use case is "developers log in once and switch between environments (dev/staging/prod) in the console or CLI." Cognito (Amazon Cognito) handles authentication and authorization for web/mobile apps. User pools are a directory managing sign-up, sign-in, MFA, and password reset, and issue JWT tokens. Identity pools (Federated Identities) grant temporary AWS credentials to users authenticated by a user pool or external IdP (Google, Facebook, SAML), allowing direct access to S3, DynamoDB, etc. Directory Service (AWS Directory Service) is a managed directory service. AWS Managed Microsoft AD provides a fully functional Active Directory as a managed service, used for EC2 domain joins and IAM Identity Center integration. AD Connector is a proxy to an on-premises AD—no cloud directory, reusing your existing AD. Simple AD is a lightweight Samba-based directory.
| Service | Target users / use case | Typical selection criteria |
|---|---|---|
| IAM Identity Center | Employee SSO across AWS accounts | Centrally deploy permission sets to multiple org accounts |
| Cognito user pool | End-user auth for web/mobile apps | App-specific sign-up/sign-in with MFA |
| Cognito identity pool | Grant AWS temp creds to authenticated users | Allow client-side direct access to S3/DynamoDB |
| Managed Microsoft AD | Full AD (EC2 domain join, Group Policy) | Extend on-prem AD to cloud or build new AD |
| AD Connector | Proxy to existing on-prem AD | Leverage existing AD without cloud replication |
Distinguish: "employees SSO into multiple AWS accounts = IAM Identity Center (permission sets)", "web/mobile app user auth = Cognito (user pool = authentication / identity pool = AWS credentials)", "EC2 domain join or existing AD integration = Directory Service (Managed Microsoft AD for full AD, AD Connector for existing on-prem AD)". The split—IAM Identity Center for internal employees vs Cognito for external app users—is a common exam topic.
Scenario: Deploy from GitHub Actions to a production AWS account without storing long-lived keys in GitHub Secrets. → Register the GitHub OIDC identity provider in AWS and scope the deploy role’s trust policy by sub (e.g., repo:org/app:ref:refs/heads/main). The workflow assumes the role via AssumeRoleWithWebIdentity and deploys with short-lived temporary credentials—no persistent keys stored on the GitHub side.
FAQ: Secrets Manager or Parameter Store? For serious secrets needing automatic rotation, RDS integration, or cross-account sharing, use Secrets Manager. For rotation-free settings or light secrets, Parameter Store (SecureString) is cheaper and simpler (standard tier has a free allowance). Parameter Store can reference Secrets Manager secrets, so the two can be combined.
Exam trap: "Issue IAM user access keys and store them in GitHub Secrets to simplify CI/CD" is wrong—long-lived keys are a high-leak-risk anti-pattern. The answer is going keyless with OIDC federation. Also, writing secrets in plaintext in buildspec or environment variables is wrong—reference ARNs and fetch at runtime.
6.1.3Section summary
- Authz = IAM roles + temporary credentials / OIDC (external CI)
- Secrets = Secrets Manager (rotation) / Parameter Store (SecureString)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. CodeBuild accesses S3/ECR during builds. How should credentials be handled?
Q2. You want to securely manage a DB password with periodic automatic rotation. What?
Q3. Deploying from GitHub Actions to AWS, you do not want to store long-lived keys in GitHub. What?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.