DOP-C02 Security and Compliance Guide

Study DOP-C02 security and compliance for pipeline permissions, secrets, policy enforcement, and audit evidence.

Security on DOP-C02 is operational security. The exam focuses on pipeline permissions, secrets, policy enforcement, evidence, and continuous compliance controls that do not rely on one-time manual review.

What AWS is explicitly testing

As of May 11, 2026, the current AWS DOP-C02 domain page splits Security and Compliance into three task areas:

  • Task 6.1: implement techniques for identity and access management at scale
  • Task 6.2: apply automation for security controls and data protection
  • Task 6.3: implement security monitoring and auditing solutions

That split matters because many DevOps security questions sound similar on the surface. One may really be an IAM-scaling problem, another a preventive-control automation problem, and another an auditability or detection problem.

Current weight in the exam guide

AWS currently weights this domain at 17% of scored content.

Work this domain in order

Start with 6.1 IAM at Scale for DevOps because credential, role, and permission design shapes every other security control in the delivery system.

Then move through:

  1. 6.2 Automated Security Controls and Data Protection
  2. 6.3 Security Monitoring and Auditing

Fast routing inside this chapter

If the scenario is really about… Go first to…
cross-account roles, permission boundaries, secrets rotation, MFA, STS, or human vs machine access 6.1 IAM at Scale for DevOps
multi-account guardrails, WAF, Network Firewall, Macie, encryption, ACM, Control Tower, or defense in depth 6.2 Automated Security Controls and Data Protection
CloudTrail, Config, Inspector, GuardDuty, Access Analyzer, audit evidence, or security alerting 6.3 Security Monitoring and Auditing

What strong DOP-C02 answers usually do

  • scope human and machine permissions differently instead of forcing one identity pattern onto both
  • automate preventive and detective controls across accounts instead of relying on manual review
  • combine security controls in layers rather than treating one service as the whole answer
  • preserve evidence, findings, and remediation history for auditability
  • design security into the delivery system rather than bolting it on after release

Common security traps

  • using long-lived credentials where role-based or rotated access is stronger
  • choosing one enforcement service without considering the broader control stack
  • automating remediation before reliable audit or detection signals exist
  • confusing “we encrypt” with “we enforce data-protection and compliance policy”

In this section

Revised on Monday, June 15, 2026