AWS Credential Architecture: IAM, Secrets Manager, and KMS Across SAP and DOP

Three services, four checkpoints, two cert flavors.

§ IFrame

Tuesday's cert slot pairs the Solutions Architect Professional (SAP-C02) and the DevOps Engineer Professional (DOP-C02). Both credentials examine deep AWS competence. Both expect the candidate to design and operate systems where many services collaborate under explicit security boundaries. Neither examines those boundaries in isolation.

The boundaries are credentials. Every AWS service call is authenticated by a principal, authorized by a policy, and (where the data involved is sensitive) encrypted by a KMS key. The three primitives (IAM principals, IAM policies, KMS keys) compose into the credential architecture that the rest of the platform uses without thinking about. The SAP and DOP exams test the candidate's ability to think about it.

This lesson treats the three primitives once, then pivots to each cert's emphasis. SAP-flavor takes up cross-account architecture, organizational policy boundaries, federated access, and the architectural decisions about which workloads share KMS keys and which do not. DOP-flavor takes up the lifecycle operations: how secrets rotate, how CI/CD assumes roles without static keys, how credentials are injected at deployment time, how usage is audited across the fleet.

The unified Vertex AI lesson from Monday established the pattern for combined-cert days: treat the platform once, pivot the per-cert emphasis. Today's lesson follows the same shape. AWS credential architecture is the shared platform; SAP's architecture lens and DOP's lifecycle lens are the two pivots.

§ IIDomain Foundations

Three services carry the bulk of AWS credential architecture. Name them; reason about them after.

The three compose as one architecture. A principal authenticates via IAM. The principal's policy grants permission to fetch a secret from Secrets Manager. Secrets Manager returns the secret after using a KMS key to decrypt it. The KMS key's own policy grants the principal permission to use it for decryption. Four checks pass before the secret reaches the principal: IAM authentication, IAM authorization for Secrets Manager, KMS key policy for decryption, and the network path's TLS handshake.

The exam tests whether the candidate can walk a request through those four checks and identify which one fails in a given scenario. The four-check walk is the foundation skill both certs assume.

§ IIISAP-C02 Flavor — Architecture Decisions

The Solutions Architect Professional examines design decisions at scale. The credential-architecture decisions that matter most concern multi-account topology, federated access, cross-account resource sharing, and KMS key topology.

AWS Organizations and Service Control Policies

A production AWS deployment runs across many accounts, not one. AWS Organizations is the management primitive: it groups accounts into Organizational Units (OUs), applies Service Control Policies (SCPs) at the OU level, and provides consolidated billing. SCPs are guardrails: they restrict what IAM permissions an account's principals can hold regardless of what IAM policies the account-level administrators write. The classic SAP scenario asks the candidate to enforce a fleet-wide rule like no public S3 buckets or no IAM users in production accounts without depending on account-level policy correctness; the answer is an SCP at the production OU that denies the relevant actions.

IAM Identity Center and federated access

Enterprise AWS deployments do not provision IAM users. They federate identity from an upstream identity provider (Okta, Azure AD, Google Workspace) through IAM Identity Center, which then provisions short-lived role-assumption sessions into the appropriate accounts. The candidate must understand the trust chain: the IdP authenticates the user, IAM Identity Center maps the authenticated identity to permission sets, the permission sets become IAM roles in the target accounts, and the user receives temporary STS credentials to assume the role. The SAP exam tests the candidate's ability to design this chain for compliance, audit, and least-privilege.

Cross-account role assumption

Workloads in one account often need to access resources in another. The canonical pattern is cross-account role assumption: a role in the resource-owning account has a trust policy permitting assumption by principals from the workload account, and the workload's IAM policy grants the matching sts:AssumeRole action. The two-sided trust check prevents either side from granting access unilaterally. SAP scenarios often present a candidate with a failing cross-account access pattern and ask which side of the trust the problem sits on.

KMS key topology decisions

A KMS key is region-scoped, account-owned, and replicable in limited ways via multi-region keys. The architectural decisions are: which keys are shared across accounts (data lake keys for cross-account analytics), which are isolated per account (production database keys), which use AWS-managed keys (default, no per-key management overhead), and which use customer-managed keys (required for SCP-enforced encryption policies, custom rotation cadences, or cross-account access). A backup workflow that restores into a different account requires a multi-region customer-managed key with a key policy that names the restore account as a permitted principal.

§ IVDOP-C02 Flavor — Lifecycle Operations

The DevOps Engineer Professional examines the lifecycle. Credentials, in the DOP lens, are things that get created, rotated, injected into deployments, revoked, and audited.

Secrets Manager rotation lifecycles

Native rotation handles the database case: a Lambda function provided by Secrets Manager generates a new password, applies it to the upstream database (RDS, DocumentDB, Redshift, or a self-managed PostgreSQL via the multi-user rotation pattern), and updates the secret's current version. Consumers refetch and receive the new value. Custom rotation handles non-database secrets via operator-provided Lambdas. The DOP exam tests the candidate's ability to design rotation Lambdas, configure rotation schedules, and handle the dual-credential pattern that keeps the prior version valid during the rotation window.

OIDC trust for CI/CD systems

A GitHub Actions workflow or a GitLab CI pipeline needs to deploy to AWS. The legacy pattern provisioned a long-lived IAM user with access keys stored in the CI system's secrets. The current pattern is OIDC-based: AWS IAM trusts the CI provider's OIDC issuer, and the CI provider issues a short-lived OIDC token at job execution time that AWS exchanges for STS credentials via sts:AssumeRoleWithWebIdentity. No long-lived secret exists; the credential is born when the job starts and expires when the job ends. The DOP exam tests the candidate's ability to configure the OIDC trust relationship, scope it to specific repos or branches via the trust policy's condition keys, and audit the resulting role assumptions.

Deployment-time credential injection

Application workloads on EC2, ECS, EKS, and Lambda receive credentials through different mechanisms: EC2 via Instance Profile, ECS via Task Role, EKS via IAM Roles for Service Accounts (IRSA), Lambda via Execution Role. Each mechanism injects short-lived STS credentials into the workload without the operator having to manage long-lived keys. The DOP exam tests the candidate's ability to pick the right mechanism for the workload, configure the trust policies correctly, and troubleshoot the common failure modes.

CloudTrail audit patterns

Every AWS API call is logged to CloudTrail with the principal that made it, the source IP, the request parameters, and the response. CloudTrail data is the credential-audit ground truth. The DOP exam tests the candidate's ability to design CloudTrail trails (multi-region, multi-account via Organizations, with log-file integrity validation), to query CloudTrail data via Athena for forensic investigations, and to integrate CloudTrail events with EventBridge for real-time alerting on suspicious credential usage.

§ VWorked Scenario — Cross-Account Production Deployment

A startup runs a production workload in account A and a separate logging-and-audit account B. The workload writes application logs to a CloudWatch Logs group in account A, but the security team needs those logs delivered to a centralized S3 bucket in account B. The CI/CD pipeline (GitHub Actions) deploys the workload's Terraform configuration. The workload reads database credentials from Secrets Manager in account A. The database is RDS PostgreSQL with native Secrets Manager rotation enabled.

The credential architecture that satisfies this scenario has six pieces.

First, GitHub Actions assumes a role in account A via OIDC. The trust policy on the role names repo:hedronite/production:ref:refs/heads/main as the permitted subject; pushes to other branches cannot assume the role.

Second, the deployed workload runs on EKS and receives its IAM identity via IRSA. The IRSA role has permission to read the database secret from Secrets Manager and to write logs to CloudWatch Logs.

Third, the Secrets Manager secret is encrypted with a customer-managed KMS key in account A. The key policy grants the IRSA role permission to decrypt; no other principal in account A has decrypt permission. The rotation Lambda has its own role with permission to update the secret and the database.

Fourth, the CloudWatch Logs group in account A has a subscription filter that streams events to Kinesis Data Firehose, which delivers them to the S3 bucket in account B. The Firehose role in account A has a trust relationship with account B's KMS key, and account B's bucket policy grants the Firehose role write permission.

Fifth, an AWS Organizations SCP at the production OU denies the use of IAM users; only IAM roles are permitted. The SCP also denies KMS key creation outside the approved regions, enforcing the data-residency constraint.

Sixth, CloudTrail in account A delivers logs to the security account B's centralized trail. An EventBridge rule on the trail fires when a principal outside the approved list assumes the database-secret role; the rule notifies the security team via SNS.

§ VIPractice Questions

§ VIIConnection to Today's Ops + Dev Lessons

The Ops lesson named vaulting, rotation, scoping, and blast radius as the four primitives of secret management. AWS Secrets Manager is the managed vaulting primitive; native rotation is the managed rotation primitive; IAM policies and KMS key policies are the managed scoping primitive; SCPs, region scoping, and key isolation are the managed blast-radius controls. The cert lesson is the AWS-specific expression of the platform-agnostic principles the Ops lesson covered.

The Dev lesson covered the Rust patterns for handling secrets safely at the type level once they arrive in the application. The two layers compose here: the AWS architecture decides who can fetch the secret; the Rust application decides what happens to the secret after it is fetched. The credential leaves AWS through the SDK call, lands in the application as a String, is wrapped immediately in SecretString, used inside a scoped operation, and zeroed at drop. The vault tier and the language tier together close the entire window in which the secret might leak.

Paired Ops → Archmagus-Stack/β-Trust/Synthesis-Lessons/2026-05-26-secret-management-and-credential-lifecycle-for-multi-agent-production-systems

Paired Dev → Polyglot-Dev/Rust/2026-05-26-rusts-ownership-discipline-applied-to-secret-handling-types-that-cannot-leak

§ VIIIClosing

AWS credential architecture is three services composed at four checkpoints. The candidate who can walk a request through IAM authentication, IAM authorization, KMS key-policy decryption, and the bucket-or-resource policy check is the candidate who passes the security questions on both exams. The candidate who can design the architecture so the four checkpoints are correct by construction is the candidate who runs the platform in production.

Both certs are accreted, not crammed. Each lesson builds one piece. This lesson laid the credential ground; the Wed CKA+CKS lesson will take up Kubernetes authentication and authorization (the same shape at a different scale); the Thu AIP-C01+GH-600 lesson will take up Bedrock model access and GitHub agent authentication; the Fri Terraform synthesis will tie the week through how the IaC code provisions each of these pieces.

Examine the trust policy and the key policy in any AWS account being designed. For every cross-account access path, name the role being assumed, the principal in the trust policy that permits the assumption, the IAM policy on the assuming principal, and the KMS key policy on any encrypted resource the path touches. The path that cannot be traced through those four artifacts is the path that will fail at the worst moment.