Amazon DVA-C02: Security, IAM, KMS & Secrets Management (Cognito, Secrets Manager, SSM) — Study Guide
Part of the AWS Developer Associate DVA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
IAM, Roles, Policies and Cross-account Access
Identity and access management should be designed around least privilege, short-lived credentials, and clear separation between service and human identities. For applications running on EC2, ECS, or Lambda prefer instance/task/function roles instead of embedding access keys; the AWS SDKs automatically use the environment-provided credential provider chain and refresh temporary credentials. Cross-account access should use AWS STS AssumeRole (API: sts:AssumeRole) with an explicit role trust policy in the target account and an IAM policy in the caller account that limits which role ARNs can be assumed. When you require MFA for sensitive operations, enforce it with a condition in the role or resource policy using aws:MultiFactorAuthPresent or require sts:GetSessionToken for human users. For web or mobile clients use AssumeRoleWithWebIdentity (sts:AssumeRoleWithWebIdentity) via Cognito Identity or federated providers to avoid long-term credentials. Beware common traps: overly permissive wildcard actions/resources, relying on resource-based policies without matching principal conditions, and forgetting to include the SourceAccount or aws:SourceVpc conditions for cross-account S3 or KMS access. Use IAM policy simulator and sts:GetCallerIdentity to debug. Consider using service control policies (SCPs) at the organization level to enforce guardrails and explicit deny for risky actions like kms:CreateGrant or iam:CreateAccessKey where appropriate.
KMS, Encryption Patterns and Key Access Control
Use AWS KMS for envelope encryption: GenerateDataKey/GenerateDataKeyWithoutPlaintext to produce a data key for client-side or server-side encryption, then call Encrypt/Decrypt for small payloads or use the data key for bulk encryption. Choose the right CMK: AWS owned for convenience, AWS managed (aws/*) for service integration, or customer-managed for full control and rotation. Key policies are the primary control for KMS; attach IAM policies that allow kms:Decrypt, kms:Encrypt and use grants when you need temporary, delegated key usage for services like CloudHSM-backed operations or cross-account Lambda invocation. Include an EncryptionContext to bind ciphertext to usage context and require it via a kms:EncryptionContextEquals condition for higher assurance. Cross-account KMS usage requires explicit key policy entries granting the external principal or role and, in some cases, CreateGrant/RetireGrant permissions. For auditing and forensics, enable CloudTrail data events for KMS and S3 to capture GenerateDataKey and Decrypt calls; CloudTrail logs will include arn:aws:kms and detail about which principal used the key. Common gotchas include forgetting to allow kms:CreateGrant for services that use grants behind the scenes, failing to rotate customer-managed keys, and assuming IAM policies alone can authorize KMS operations without proper key policy entries.
Secrets Management: Secrets Manager vs Parameter Store
Secrets Manager and Systems Manager Parameter Store both provide encrypted secret storage but differ in features and cost profile: Secrets Manager supports automatic rotation (with Lambda rotation templates), built-in versioning and integrated replication, and charges per secret; Parameter Store (SecureString) is free-tier for many parameters and better for simple configuration. Access is controlled by IAM policies granting secretsmanager:GetSecretValue or ssm:GetParameter with WithDecryption=true, and the underlying KMS key must allow decrypt for the principal. Use resource-based policies on Secrets Manager for cross-account secrets, or replication with secrets replication. When using SDKs, call secretsmanager.getSecretValue({ SecretId }) or ssm.getParameter({ Name, WithDecryption: true }) and avoid logging secret values; set Lambda environment variables to use references to Secrets Manager or Parameter Store with dynamic resolution in CloudFormation or SAM, or use SDK fetch at startup. Common developer mistakes include storing secrets in plaintext in source control, relying on Lambda environment variables for very sensitive data without KMS protection, and overpermissive IAM policies such as granting secretsmanager:* to broad roles. For rotation, ensure the rotation Lambda has correct secretsmanager:RotateSecret and kms:GenerateDataKey permissions and that application code can seamlessly reinitialize connections when credentials change.
Cognito Authentication, Authorization and API Integration
Amazon Cognito provides user pools for authentication and identity pools for temporary AWS credentials. Use Cognito User Pools to manage sign-up, multi-factor authentication, and JWT issuance (ID, access, refresh tokens). Browser-based single-page apps must use app clients without a client secret and should use the hosted UI or the Amazon Cognito SDK (amazon-cognito-identity-js) implementing the SRP flow to avoid exposing passwords. Verify JWTs on the server or API Gateway by fetching the JWKS URI from the user pool and validating signature, issuer, audience (aud), and token expiry; API Gateway JWT authorizers or Lambda custom authorizers can perform this validation. For server-to-service authentication, exchange the user pool token for temporary credentials via Cognito Identity Pool with sts:AssumeRoleWithWebIdentity. Pitfalls include misconfigured callback or sign-out URLs, not validating token scopes or groups, and expecting ID tokens to be directly usable for AWS API calls (you must exchange them via identity pool). For fine-grained authorization use groups or custom claims and combine Cognito with resource-based policies and IAM condition keys such as aws:userid or cognito-identity.amazonaws.com:sub when mapping identity to AWS roles. Audit sign-in and admin actions via CloudTrail, and enable advanced security features in Cognito for compromised credential detection.
Practical Problem: Use-Case Scenario
Scenario: PixelForge, a game studio, runs a serverless backend in a single AWS account with Lambda, API Gateway, S3, DynamoDB, and Cognito user pools. Sensitive API keys and database credentials are stored for multiple deployment stages and a third‑party audit team must access subsets of production images in S3 for 1–24 hours.
Challenge: Securely provide short-lived, auditable access to production images for external auditors, ensure application secrets are rotated and accessed securely by Lambda, and enforce MFA for admin cross-account access.
Recommended Approach:
- Create a customer-managed KMS key with a key policy allowing decrypt for the PixelForge account and grants for an auditor IAM role; enable key rotation and require EncryptionContext during decrypt operations.
- Store credentials in Secrets Manager (separate secrets per stage) and attach an IAM role to Lambdas with minimal secretsmanager:GetSecretValue permission and kms:Decrypt for the KMS key; implement Lambda startup code to call secretsmanager.getSecretValue({ SecretId }) using AWS SDK.
- For auditor access, create a separate auditor AWS account role and allow sts:AssumeRole from the auditor account in a resource-based S3 bucket policy limited by aws:PrincipalArn and a time-bound, pre-configured role mapping; generate short-lived credentials via sts:AssumeRole and enforce MFA with a condition aws:MultiFactorAuthPresent when assuming the role.
- Log all access with CloudTrail (management and data events for S3 and KMS) and enable S3 object-level logging and Amazon Macie or S3 Access Logs for additional forensics; require that temporary auditor sessions use a specific EncryptionContext and tag objects/requests for traceability.
Rationale: Using Secrets Manager with KMS and short-lived STS credentials enforces least privilege, enables automated rotation, and avoids embedding secrets. Time-bound assume-role patterns with MFA and CloudTrail data events provide auditable, revocable access for third parties while preserving separation of duties.
← Deployment · All domains · Monitoring →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →