Security And Governance Boundary — AWS DevOps Engineer (DOP-C02)
GuardDuty Detects — It Doesn't Enforce
Security Hub aggregates findings. GuardDuty detects threat behavior. IAM enforces access decisions at the resource level. IAM Identity Center governs federated human access across accounts. Each operates at a different layer of the security stack. Scenarios that mix detection language with enforcement language are testing whether you respect that boundary. An answer that routes GuardDuty findings into an automated remediation Lambda isn't wrong — but it only satisfies enforcement if the scenario asks for automated response, not just visibility.
What This Pattern Tests
The exam describes a security requirement and tests which access control layer applies. IAM policies attach to principals (users, roles). Resource policies attach to resources (S3 bucket policies, KMS key policies). SCPs restrict what an entire AWS account can do. Permission boundaries cap what an IAM entity can be granted. The trap is applying EC2-level security group thinking to Lambda (which uses IAM execution roles), or writing an IAM policy when an SCP is needed for account-wide restriction. S3 Block Public Access, VPC endpoint policies, and Organizations tag policies each add another control plane the exam expects you to distinguish.
Decision Axis
Control scope determines the mechanism: principal-level (IAM), resource-level (resource policies), account-level (SCPs), or network-level (security groups, NACLs).
Associated Traps
More Top Traps on This Exam
Decision Rules
Whether the identity governance architecture must include all three layers—SCP deny guardrails, IAM Identity Center permission sets for grant scoping, and Secrets Manager automated rotation—or whether a near-right design using IAM Identity Center plus per-account IAM roles with manual or Lambda-triggered rotation satisfies the stated constraints.
Whether to satisfy a single-account PCI-DSS encryption-at-rest and key-rotation requirement using AWS KMS automatic rotation plus AWS Config managed rules, or to overscope the solution by deploying organization-wide controls (SCPs, Security Hub aggregation, CloudHSM clusters) that exceed the stated compliance boundary and introduce unjustified operational complexity.
Whether a purpose-built CloudTrail organization trail → CloudWatch Logs metric filter → EventBridge alert chain satisfies the continuous-audit-trail and detection-latency-sla constraints, or whether enabling AWS Security Hub with GuardDuty is warranted — recognizing that the latter occupies the aggregation-and-finding-correlation layer, not the direct API-call audit and sub-5-minute alert layer.
Whether the least-privilege and credential-rotation-automation constraints are fully satisfied by layering IAM Identity Center permission sets (grant scoping), Organizations SCPs (deny guardrails), and Secrets Manager native rotation (automated lifecycle) — versus oversolving with a custom Lambda-backed credential vending machine or per-account IAM boundary policies that add operational complexity without closing any gap the managed services leave open.
When the compliance boundary is a single AWS account and the regulation mandates annual key rotation, AWS Config (kms-key-rotation-enabled managed rule) plus KMS automatic rotation is the least-overhead solution that satisfies the requirement; choosing CloudHSM with BYOK and custom Lambda rotation, or organization-wide Security Hub aggregation, overreaches the stated single-account boundary and introduces hardware HSM or cross-account operational complexity that the regulation does not require.
Whether a targeted CloudTrail management-event stream with a CloudWatch Logs metric filter and alarm satisfies the detection-latency SLA within the stated single-account scope, or whether the solution must expand to a GuardDuty plus Security Hub finding pipeline that is architecturally designed for multi-source threat aggregation and exceeds the stated boundary.
Domain Coverage
Difficulty Breakdown