AWS Certified DevOps Engineer - Professional (DOP-C02): Automation, Resiliency, and Security Study Guide
Skills in:
AWS Certified DevOps Engineer - Professional (DOP-C02): Automation, Resiliency, and Security
This study guide covers core domains of the DOP-C02 exam, focusing on event-driven architectures, multi-region resiliency, advanced security controls, and infrastructure automation.
Learning Objectives
By the end of this module, you should be able to:
- Configure and manage AWS agents (SSM, CloudWatch) for hybrid and cloud-native monitoring.
- Design event-driven, asynchronous workflows using EventBridge, Lambda, and SQS.
- Implement complex auto-scaling solutions for compute, storage, and container-based workloads.
- Enforce security at scale using Service Control Policies (SCPs), Permissions Boundaries, and automated remediation.
- Apply deployment strategies (Blue/Green, Canary) to ensure zero-downtime updates.
Key Terms & Glossary
- Service Control Policy (SCP): A type of organization policy used to manage permissions in your organization, offering central control over the maximum available permissions for all accounts.
- RTO (Recovery Time Objective): The maximum acceptable amount of time that a service can be down after a failure.
- RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time (e.g., "we can lose 15 minutes of data").
- Drift Detection: A feature of CloudFormation that identifies when a stack's actual configuration differs from its expected template configuration.
- Canary Deployment: A deployment strategy where a small percentage of traffic is shifted to a new version of the application to test stability before a full rollout.
The "Big Idea"
At the Professional level, DevOps on AWS isn't just about scripts; it's about Autonomous Governance. The goal is to build systems that not only deploy code automatically but also monitor their own health, scale based on predictive metrics, and self-remediate security or configuration drift without human intervention.
Formula / Concept Box
| Concept | Metric / Rule | Key Consideration |
|---|---|---|
| Availability | Focus on reducing Mean Time To Repair (MTTR). | |
| RTO vs RPO | , | Lower targets significantly increase cost and complexity. |
| Scaling Policy | Target Tracking vs. Step Scaling | Target Tracking is preferred for simpler, metric-based stability. |
| IAM Hierarchy | SCP > Permissions Boundary > Identity Policy | The effective permission is the intersection of all three. |
Hierarchical Outline
- I. Monitoring and Logging
- Custom Metrics: Using CloudWatch Agent to collect memory and disk stats (not available by default).
- Log Processing: Using CloudWatch Log Subscriptions to stream data to Kinesis or OpenSearch.
- II. Event and Incident Response
- Asynchronous Patterns: Triggering Lambda functions via S3 Event Notifications for log processing.
- Remediation: Using AWS Config Rules to trigger SSM Automation documents for non-compliant resources.
- III. Resilient Infrastructure
- Multi-Region Failover: Implementing Route 53 Health Checks with failover routing policies.
- Database Resiliency: Global Tables for DynamoDB and Cross-Region Read Replicas for RDS.
- IV. Security and Compliance
- Identity at Scale: Using IAM Identity Center for federation and Secrets Manager for automated credential rotation.
- Defense in Depth: Layering WAF, Shield, and Network Firewall with automated Security Hub findings.
Visual Anchors
Event-Driven Remediation Workflow
High Availability Architecture (Multi-AZ)
Definition-Example Pairs
- Metric Filter: A pattern used to search and match terms in log groups and turn them into numerical CloudWatch metrics.
- Example: Creating a metric for "404 Errors" by scanning Apache access logs for the "404" string.
- StackSet: A CloudFormation feature that allows you to create, update, or delete stacks across multiple AWS accounts and regions with a single operation.
- Example: Deploying a standard IAM Role and VPC configuration to 50 child accounts in an AWS Organization.
- Permissions Boundary: A managed policy that sets the maximum permissions that an identity-based policy can grant to an IAM entity.
- Example: Giving a developer the ability to create IAM roles, but using a boundary to ensure those roles cannot touch the Billing or Security logs.
Worked Examples
Example 1: Automated Remediation of Public S3 Buckets
Scenario: A company wants to ensure no S3 buckets are ever public.
- Detection: Enable AWS Config rule
s3-bucket-public-read-prohibited. - Trigger: Link the rule to an Amazon EventBridge event pattern for "Non-compliant" findings.
- Action: The EventBridge event triggers an SSM Automation document (
AWS-ConfigureS3BucketPublicAccessBlock). - Verification: The bucket is updated to "Block Public Access," and a message is sent to an SNS topic for the security team.
Example 2: Blue/Green Deployment with CodeDeploy
Scenario: Update an application on EC2 with zero downtime.
- Setup: Create a new "Green" Auto Scaling Group with the updated code version.
- Routing: CodeDeploy shifts 10% of traffic from the "Blue" (original) group to the "Green" group via the Load Balancer.
- Health Check: Monitor CloudWatch Alarms. If 5xx errors increase, CodeDeploy automatically rolls back (switches 100% traffic back to Blue).
- Completion: If stable, 100% of traffic moves to Green, and the Blue group is terminated after a timeout.
Checkpoint Questions
- What is the difference between a CloudWatch Alarm and a CloudWatch Metric Filter?
- In a multi-region disaster recovery scenario, which routing policy in Route 53 is most appropriate for high availability?
- How does AWS Secrets Manager differ from Systems Manager Parameter Store regarding sensitive data?
- What IAM entity is used to centrally restrict services at the account level within an Organization?
Muddy Points & Cross-Refs
- OpsWorks vs. SSM: Use SSM State Manager and Patch Manager for almost all modern requirements. OpsWorks (Chef/Puppet) is generally reserved for legacy configuration management or specific third-party integration needs.
- Kinesis Data Streams vs. Firehose: Remember that Streams is for real-time processing (requires a consumer app), while Firehose is for loading data into destinations like S3 or Redshift (near real-time).
- Deep Dive: See "AWS Whitepaper: Reliability Pillar" for detailed RTO/RPO architecture patterns.
Comparison Tables
Deployment Strategies
| Feature | In-Place | Blue/Green | Canary |
|---|---|---|---|
| Downtime | Brief service interruption | Zero | Zero |
| Risk | High (Rollback is slow) | Low (Fast rollback) | Lowest (Limited blast radius) |
| Cost | Low (No extra resources) | High (Double resources) | Medium (Incremental scaling) |
AWS Monitoring Tools
| Service | Primary Use Case | Key Strength |
|---|---|---|
| CloudWatch | Metrics, Alarms, Logs | Native integration with most services |
| AWS Config | Resource inventory and compliance | Tracks configuration changes over time |
| CloudTrail | API auditing | Records "Who did what, when, and from where" |
| X-Ray | Distributed tracing | Identifies bottlenecks in microservices/Lambda |