Amazon SOA-C02: Security, Identity, and Compliance — Study Guide

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Part of the AWS SysOps Administrator Associate SOA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

This domain covers the identity, encryption, secrets, and auditing primitives that underpin secure and compliant AWS operations. It focuses on granting the right access (principle of least privilege), protecting data through key management and encryption, and creating immutable audit trails for continuous compliance. Day-to-day SysOps responsibilities include designing IAM roles and trust boundaries, operating KMS keys and secrets, and using AWS Config and CloudTrail to detect drift and policy violations.

IAM, roles, policies, and federation

IAM governance should start with role separation and least privilege: use separate roles for administration, logging, and application workloads; avoid attaching broad policies like AdministratorAccess to long-lived principals. Create roles with a trust policy (console or CLI: aws iam create-role –role-name AppRole –assume-role-policy-document file://trust.json) and attach permission policies using aws iam put-role-policy or managed policies. Use permission boundaries and IAM Conditions (aws:SourceIp, aws:RequestedRegion) to limit where and how privileges can be exercised.

For identity federation, prefer SAML/OIDC to issue temporary credentials via STS. For SAML, configure an identity provider in IAM and use aws sts assume-role-with-saml –role-arn arn:aws:iam::123456789012:role/SAMLRole –principal-arn arn:aws:iam::123456789012:saml-provider/IdP. For OIDC (Cognito, Auth0, or other providers), create an IAM OIDC provider and map claims to roles; web identity federation uses aws sts assume-role-with-web-identity. Choose federated roles when users are external or when central directory services manage authentication; use AWS IAM Identity Center (SSO) for centralized enterprise access and session management.

KMS, key management, and encryption

KMS is the central service for key lifecycle and access control. Choose between AWS-managed keys (simplicity), AWS-owned keys, and customer-managed CMKs (fine-grained control). Create CMKs with aws kms create-key –description “CMK for prod” and enable automatic rotation with aws kms enable-key-rotation –key-id alias/ProdKey. Use key policies to define who can manage keys and use grants for temporary access delegation (aws kms create-grant) rather than broad IAM policies.

Decision criteria: use CMKs when auditing and key lifecycle control (rotation, deletion windows) are required; use AWS-managed keys for automatic convenience in many managed services. Protect keys by enforcing IAM policies + key policies, restrict use via kms:ViaService or KMS grants for cross-account use, and avoid scheduling immediate deletion—use a minimum pending window. Monitor KMS usage with CloudTrail logs for Encrypt/Decrypt and GenerateDataKey operations to detect anomalous usage.

Secrets management and parameter stores

Use AWS Secrets Manager for credential rotation and lifecycle automation, and Systems Manager Parameter Store (SecureString) for simpler secrets where rotation is manual. Create secrets via aws secretsmanager create-secret –name prod/db –secret-string ‘{“username”:“app”,“password”:"…"}’ and enable rotation specifying a Lambda function for automatic rotation. For Parameter Store use aws ssm put-parameter –name /prod/db/password –value “…” –type SecureString –key-id alias/ProdKey.

Decision points:

• Secrets Manager: built-in rotation, secret versions, replication, and integrated console rotation templates; higher cost but better for DB credentials and API keys.
• Parameter Store SecureString: free tier for basic secret storage, use KMS CMK for encryption and IAM policies for access. Always restrict access to secrets via least-privilege IAM policies and prefer role-based access (EC2/ECS/Lambda execution roles) rather than embedding long-lived credentials in code or environment variables.

AWS Config, auditing, and compliance monitoring

AWS Config provides continuous resource recording, change history, and rule evaluation. Enable a recorder and delivery channel (console or aws configservice start-configuration-recorder) and create managed or custom rules with aws configservice put-config-rule. Combine Config with CloudTrail (aws cloudtrail create-trail –name audit –s3-bucket audit-bucket) and CloudWatch Alarms for near-real-time detection and remediation (use Config remediation actions or Systems Manager Automation documents).

Design decisions: use Config managed rules for standard checks (S3 bucket public-read, root account MFA) and custom rules (Lambda) for domain-specific controls. Ensure multi-region aggregation of Config data into an aggregator and enable multi-account recording via AWS Organizations. Keep an immutable audit trail by sending CloudTrail logs to a central encrypted S3 bucket (SSE-KMS) and enable CloudTrail Insights for anomalous API activity.

Data protection, encryption in transit and at rest

Encryption should be applied in layers: at rest using KMS-backed encryption for EBS, RDS, S3 (SSE-S3, SSE-KMS, or SSE-C) and in transit using TLS for application traffic (use ACM for public/private certificates and attach to ALB/NLB listeners: aws elbv2 create-listener –load-balancer-arn … –protocol HTTPS –port 443 –certificates CertificateArn=arn:aws:acm:…). Use client-side encryption where additional control is required and consider envelope encryption with GenerateDataKey when encrypting large data outside KMS quotas.

Apply these decision criteria:

• Use SSE-KMS for S3 objects when you need audit and key access controls; SSE-S3 is fine for basic server-side encryption.
• Use KMS CMKs for EBS and RDS when you need key rotation and cross-account access control.
• Always enforce TLS for service endpoints; use HSTS and strong ciphers in load balancers. Use VPC endpoints and IAM policies to reduce public exposure of data-plane APIs.

Common Pitfalls and Decision Criteria

• Overusing the root account or storing root credentials: instead, create administrator roles with MFA and use AWS SSO or IAM roles for daily tasks; lock root credentials in a secure vault and enable MFA.
• Relying on long-lived access keys: rotate keys regularly or eliminate them in favor of temporary credentials via STS and role chaining (EC2/ECS/Lambda roles).
• Not rotating or improperly protecting KMS keys and secrets: enable automatic rotation for CMKs where appropriate, use Secrets Manager rotation for DB credentials, and monitor key usage via CloudTrail.
• Relying on default S3 permissions or ACLs: enforce bucket policies, block public access, and use SSE-KMS for sensitive data; validate with AWS Config rules.
• Misusing key policies vs IAM policies: manage key administration in the KMS key policy and grant usage through grants or IAM when appropriate; avoid granting Decrypt broadly.
• Forgetting centralized logging and multi-region aggregation: set up CloudTrail multi-region trails and Config aggregators for cross-account compliance.

Practical Problem: Use-Case Scenario

AcmeFin, a fintech firm, needs to secure production databases and APIs while providing contractors temporary access and maintaining auditability for compliance audits.

1. Create separate IAM roles for admin, app, and contractor access; enforce MFA and use IAM Identity Center for SAML-based federation for contractors.
2. Encrypt RDS and EBS with a customer-managed CMK (aws kms create-key), enable key rotation, and restrict key usage via a strict key policy allowing only DB and audit roles.
3. Store DB credentials in AWS Secrets Manager with automated rotation using the provided Lambda rotation template.
4. Enable CloudTrail (multi-region) and AWS Config recorder, send logs to a central SSE-KMS encrypted S3 bucket, and create Config rules for public S3 and unencrypted resources.
5. Use ALB with ACM-issued certificates for HTTPS, and place APIs behind WAF and VPC endpoints where appropriate.

This approach enforces least privilege via role separation, automates credential and key rotation to reduce blast radius, and centralizes logs and Config evaluations so auditors can verify controls while operations retain safe, temporary access patterns.

← Deployment · All domains · Networking and Content Delivery →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Amazon →