Introduction
Security and Compliance is one of the heaviest-weighted domains on the AWS Certified DevOps Engineer – Professional (DOP-C02) exam at roughly 17% of your score, and it’s also where the questions stop being about a single service and start being about systems. The exam doesn’t ask “what does GuardDuty do?” — it asks “a finding appears, you have hundreds of accounts, and nothing should require a human to click a button; what do you wire together?” That shift from knowing services to automating controls across an organization is the whole point of this domain.
This guide walks through every concept DOP-C02 tests in the Security and Compliance domain from a DevOps engineer’s perspective: managing identity at scale, building automated detective controls, responding to findings without humans in the loop, protecting secrets and data, and proving compliance continuously. Each section includes the patterns and trade-offs the exam expects you to recognize instantly, plus CLI and policy snippets you can adapt.
If you haven’t mapped the whole exam yet, start with the AWS DevOps Engineer Professional exam guide, which covers all six domains and the logistics. This article is the security deep dive.
What “Security and Compliance” Actually Tests
The domain breaks into a handful of recurring themes. Recognizing which theme a scenario belongs to is half the battle:
| Theme | What the exam wants you to automate |
|---|---|
| IAM at scale | Cross-account access, federation, permission boundaries, SCPs |
| Detective controls | AWS Config rules, Security Hub, GuardDuty, Inspector, Macie |
| Automated remediation | EventBridge → Lambda / SSM Automation, Config remediation |
| Secrets & credentials | Secrets Manager rotation, Parameter Store, KMS |
| Data protection | Encryption at rest/in transit, KMS key policies, ACM |
| Compliance reporting | Config conformance packs, Audit Manager, CloudTrail |
The unifying principle across all of them: manual security doesn’t scale, so every control should be defined as code, evaluated continuously, and remediated automatically. If an answer option requires a person to notice something, it’s usually the wrong one.
Identity and Access Management at Scale
A single account with a handful of IAM users is easy. DOP-C02 assumes you operate dozens or hundreds of accounts under AWS Organizations, and the questions reflect that.
Roles Over Long-Lived Keys
The exam’s default-correct answer for “how should an application or pipeline authenticate” is almost always IAM roles with temporary credentials, never long-lived access keys. For workloads:
- EC2 / ECS / EKS → instance profiles or IRSA (IAM Roles for Service Accounts) so credentials are vended automatically and rotated by AWS.
- CI/CD outside AWS (e.g. a self-hosted runner) → OIDC federation so the pipeline assumes a role with a short-lived token instead of storing keys.
- Cross-account access → an IAM role in the target account with a trust policy naming the source account/principal, assumed via
sts:AssumeRole.
Permission Boundaries vs. SCPs
This distinction is a classic trap. Both limit permissions, but at different layers:
| Control | Scope | Use case |
|---|---|---|
| Service Control Policy (SCP) | Whole account or OU (via Organizations) | Guardrail: “no one in this OU can disable CloudTrail or leave us-east-1” |
| Permission boundary | A single IAM principal | ”This role the dev team can create can never grant more than these permissions” |
The mental model: SCPs set the maximum permissions for an account; permission boundaries set the maximum for an identity. A permission boundary is especially powerful for delegated administration — you let developers create roles, but a boundary guarantees those roles can’t escalate beyond what you allow. Effective permissions are always the intersection of the identity policy, any permission boundary, and any applicable SCP.
// SCP that prevents anyone in an OU from disabling guardrails
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyDisablingGuardrails",
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"config:DeleteConfigurationRecorder",
"guardduty:DeleteDetector"
],
"Resource": "*"
}]
}Centralized Identity
For human access at scale, the exam favors AWS IAM Identity Center (formerly AWS SSO) federated to an external IdP, with permission sets mapped to roles across accounts — not IAM users created per account. If a scenario mentions “hundreds of developers” and “a corporate directory,” reach for federation.
Automated Detective Controls
Detective controls answer “is anything wrong right now?” DOP-C02 expects you to know which service detects what, and how to aggregate findings across an organization.
AWS Config: Configuration Compliance
AWS Config records the configuration state of your resources over time and evaluates them against Config rules. This is the workhorse for “ensure every resource conforms to policy.”
- Managed rules cover common requirements (
s3-bucket-server-side-encryption-enabled,restricted-ssh,rds-storage-encrypted). - Custom rules run a Lambda function or a Guard policy for organization-specific checks.
- Conformance packs bundle many rules (and their remediations) into a single deployable, versioned artifact — the exam’s answer for “deploy a consistent compliance baseline across all accounts.”
# Deploy a conformance pack across the organization
aws configservice put-organization-conformance-pack \
--organization-conformance-pack-name "cis-baseline" \
--template-s3-uri "s3://my-compliance-bucket/cis-conformance-pack.yaml"Security Hub: The Aggregator
AWS Security Hub is the single pane of glass. It ingests findings from GuardDuty, Inspector, Macie, and Config, normalizes them into the AWS Security Finding Format (ASFF), and runs automated standards checks (CIS, AWS Foundational Security Best Practices, PCI DSS). When a question asks “how do I see all security findings across all accounts and Regions in one place,” the answer is Security Hub with a delegated administrator account.
GuardDuty, Inspector, and Macie
Know exactly what each one watches — the exam loves to swap them:
| Service | Detects | Data source |
|---|---|---|
| GuardDuty | Threats & malicious behavior | VPC Flow Logs, DNS logs, CloudTrail, EKS audit logs |
| Inspector | Software vulnerabilities (CVEs) & unintended network exposure | EC2, ECR images, Lambda |
| Macie | Sensitive data (PII) in S3 | S3 object content |
| Config | Resource configuration drift from policy | Resource configuration history |
The one-line discriminator: GuardDuty = behavior/threats, Inspector = vulnerabilities/CVEs, Macie = sensitive data in S3, Config = configuration compliance.
Event-Driven Auto-Remediation
This is the most DevOps-flavored part of the domain and the highest-yield pattern to internalize. The exam repeatedly describes a finding and asks how to remediate it with zero human intervention. There are two canonical pipelines:
Pattern 1: EventBridge → Lambda / SSM Automation
Almost every security service emits findings as events. EventBridge matches them and triggers a remediation:
// EventBridge rule: catch a GuardDuty finding above severity 7
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": { "severity": [{ "numeric": [">=", 7] }] }
}The target is typically:
- An SSM Automation runbook for predefined remediation (isolate an instance, revoke a security group rule, disable an access key).
- A Lambda function for custom logic.
- An SNS topic to notify, often in addition to remediating.
Pattern 2: AWS Config Remediation
Config rules can attach an automatic remediation action (an SSM Automation document) that fires the moment a resource is found non-compliant — e.g. a rule that detects a public S3 bucket and a remediation that re-applies BlockPublicAccess.
aws configservice put-remediation-configurations \
--remediation-configurations '[{
"ConfigRuleName": "s3-bucket-public-read-prohibited",
"TargetType": "SSM_DOCUMENT",
"TargetId": "AWS-DisableS3BucketPublicReadWrite",
"Automatic": true,
"MaximumAutomaticAttempts": 3,
"RetryAttemptSeconds": 60
}]'Exam discriminator: if the trigger is a threat or behavioral finding (GuardDuty, Security Hub), think EventBridge → SSM/Lambda. If the trigger is configuration non-compliance, think Config rule with automatic remediation. Both ultimately call SSM Automation runbooks — which is why SSM Automation is the connective tissue of this whole domain.
This pattern is the security sibling of the incident-response work covered in the AWS incident response and auto-remediation guide — same EventBridge-driven plumbing, applied to security findings instead of operational alarms.
Secrets and Credential Management
Hard-coded credentials are an automatic wrong answer. The exam wants managed, rotated, audited secrets.
| Service | Best for | Rotation |
|---|---|---|
| Secrets Manager | DB passwords, API keys, anything needing rotation | Built-in automatic rotation via Lambda |
| SSM Parameter Store | Config values and secrets (SecureString) | No native rotation; cheaper |
The decision rule: need automatic rotation or cross-account secret sharing → Secrets Manager. Just need cheap encrypted config → Parameter Store (SecureString backed by KMS). Both integrate with KMS for encryption and with IAM for access control, and both keep secrets out of your code and your pipeline logs.
# Enable 30-day automatic rotation on a database secret
aws secretsmanager rotate-secret \
--secret-id prod/db/credentials \
--rotation-lambda-arn arn:aws:lambda:us-east-1:111122223333:function:SecretsRotation \
--rotation-rules '{"AutomaticallyAfterDays": 30}'Data Protection: Encryption Everywhere
DOP-C02 expects encryption to be the default, enforced by automation rather than hoped for.
- At rest — KMS-backed encryption on S3, EBS, RDS, DynamoDB. Use customer managed keys (CMKs) when you need control over the key policy, rotation, and cross-account grants; AWS managed keys when you don’t.
- In transit — TLS everywhere, with certificates from AWS Certificate Manager (ACM), which auto-renews them so nothing expires silently.
- Enforcement — a Config rule (
encrypted-volumes,s3-bucket-server-side-encryption-enabled) detects unencrypted resources, and an SCP can outright deny creating them. Detection + prevention together is the strongest answer.
Key policies are the most-missed detail: for a CMK, the key policy is the root of trust. An IAM policy alone cannot grant access to a KMS key unless the key policy delegates to IAM ("Principal": {"AWS": "arn:aws:iam::ACCOUNT:root"}). Expect at least one question that hinges on this.
Continuous Compliance and Auditing
The final theme is proving compliance over time, not just at a point in time.
- AWS Config conformance packs give you a deployable, version-controlled compliance baseline and a dashboard of compliant/non-compliant resources across the organization.
- AWS Audit Manager continuously collects evidence and maps it to frameworks (CIS, PCI DSS, HIPAA, SOC 2), automating the audit-prep grind.
- CloudTrail is the non-negotiable foundation — an organization trail logging all management (and optionally data) events to a centralized, locked-down S3 bucket. The exam expects CloudTrail to be on, organization-wide, and protected from tampering (hence the SCP earlier that denies
StopLogging). - CloudTrail Lake or sending logs to CloudWatch Logs / Athena enables querying for forensic and compliance investigations.
Defining all of this as code — conformance packs, Config rules, SCPs, key policies — is itself a DOP-C02 theme. The AWS CloudFormation guide for DevOps covers the IaC patterns that keep these guardrails reproducible and drift-free across accounts.
Exam Tips and Common Traps
- Prefer roles and federation over IAM users and long-lived keys — almost always the correct answer for workloads and humans alike.
- SCP = account-level maximum; permission boundary = identity-level maximum. Effective permissions are the intersection.
- GuardDuty detects threats, Inspector finds CVEs, Macie finds PII, Config checks configuration. Don’t mix them up.
- Behavioral finding → EventBridge → SSM/Lambda. Config non-compliance → Config auto-remediation. Both lean on SSM Automation runbooks.
- Security Hub is the aggregator (delegated admin + ASFF), not a detector itself.
- Secrets Manager for rotation; Parameter Store SecureString for cheap encrypted config.
- A KMS key policy is the root of trust — IAM alone can’t grant key access without it.
- CloudTrail must be organization-wide and tamper-proof, enforced with an SCP.
- Detection + prevention beats detection alone — pair a Config rule with an SCP deny.
Practice Until the Patterns Are Automatic
This domain rewards recognition speed. On exam day you won’t have time to reason from first principles about whether a scenario calls for an SCP or a permission boundary, or whether GuardDuty or Inspector is the right detector — you need to read the scenario and know. That fluency only comes from working through enough scenario questions that the patterns become reflexive.
Build that instinct with realistic, scenario-based practice. Sailor.sh’s AWS Certified DevOps Engineer Professional (DOP-C02) Mock Exam Bundle includes eight full-length 75-question exams with 180-minute timing that mirror the real exam, plus detailed explanations across all six domains — including the IAM-at-scale, detective-control, and auto-remediation scenarios this guide covered. Working through them is the fastest way to close the gap between “I understand this concept” and “I can pick the right answer under pressure.”
To structure your prep, the AWS DevOps Engineer Professional study plan sequences the domains week by week, and the free DOP-C02 practice questions let you self-check before committing to a full mock. For the detective and response side of operations, the monitoring and observability guide pairs naturally with this security domain.
Frequently Asked Questions
What percentage of the DOP-C02 exam is Security and Compliance?
The Security and Compliance domain accounts for roughly 17% of the AWS Certified DevOps Engineer – Professional (DOP-C02) exam, making it one of the most heavily weighted domains alongside SDLC Automation. It emphasizes automating security controls at organizational scale rather than configuring a single service in isolation.
What is the difference between a Service Control Policy and a permission boundary?
A Service Control Policy (SCP) is applied through AWS Organizations to an entire account or organizational unit and sets the maximum permissions available to everyone in that account. A permission boundary is attached to a single IAM user or role and sets the maximum permissions for that identity. A principal’s effective permissions are the intersection of its identity-based policy, its permission boundary, and any SCP. SCPs are account-wide guardrails; permission boundaries are per-identity guardrails, often used for delegated role creation.
How do you automatically remediate security findings on AWS?
There are two canonical patterns. For threat or behavioral findings (GuardDuty, Security Hub), an EventBridge rule matches the finding and triggers an SSM Automation runbook or a Lambda function to remediate — for example, isolating an instance or revoking a security group rule. For configuration non-compliance, an AWS Config rule with an attached automatic remediation action (an SSM document) fixes the resource the moment it drifts out of compliance. Both ultimately invoke SSM Automation runbooks.
When should I use AWS Secrets Manager versus SSM Parameter Store?
Use Secrets Manager when you need built-in automatic rotation (for example, database credentials), cross-account secret sharing, or generated secrets. Use SSM Parameter Store (with SecureString parameters) for cheaper encrypted configuration values and secrets that don’t require native rotation. Both encrypt data with KMS and control access with IAM, and both keep credentials out of source code and pipeline logs.
What is the difference between GuardDuty, Inspector, and Macie?
GuardDuty is a threat-detection service that analyzes VPC Flow Logs, DNS logs, CloudTrail, and EKS audit logs for malicious or anomalous behavior. Amazon Inspector scans EC2 instances, ECR container images, and Lambda functions for software vulnerabilities (CVEs) and unintended network exposure. Amazon Macie discovers and classifies sensitive data such as PII in S3. They are complementary: behavior, vulnerabilities, and sensitive data, respectively — and Security Hub aggregates all of their findings.
How does AWS Config help with compliance?
AWS Config continuously records the configuration state of your resources and evaluates them against Config rules (managed or custom). Non-compliant resources can trigger automatic remediation via SSM Automation. Conformance packs bundle many rules and remediations into a single versioned, deployable artifact that you can roll out across an entire organization, giving you a consistent compliance baseline and a dashboard of compliant versus non-compliant resources over time.
Conclusion
Security and Compliance on DOP-C02 rewards one mindset above all: manual security doesn’t scale, so every control must be code that evaluates and remediates itself. Keep the IAM-at-scale distinctions sharp (roles over keys, SCPs versus permission boundaries, centralized federation), know exactly which detective service watches what, and be fluent in the two auto-remediation pipelines — EventBridge-driven for findings, Config-driven for drift. Layer on rotated secrets, enforced encryption with KMS key policies as the root of trust, and tamper-proof organization-wide CloudTrail, and this domain shifts from “intimidating” to “pattern recognition.”
From here, round out your DOP-C02 prep with the resilient cloud solutions guide and the incident response and auto-remediation guide — resilience, security, and response are the three sides of operating at scale. Then put it all under timed pressure with full mock exams until the patterns are second nature.