Validates advanced DevOps skills including continuous delivery, automation, and security governance on AWS.
AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeCommit, CI/CD Pipelines, Amazon ECR
AWS CloudFormation, AWS CDK, AWS Systems Manager, AWS OpsWorks, Amazon EC2 Image Builder, AWS Service Catalog
Multi-AZ & Multi-Region Design, Auto Scaling, Amazon Route 53 Failover, AWS Backup, RTO & RPO Strategies, Disaster Recovery Patterns
Amazon CloudWatch, AWS CloudTrail, Amazon EventBridge, AWS X-Ray, Amazon OpenSearch Service, VPC Flow Logs
Amazon EventBridge Rules, AWS Lambda Auto-Remediation, AWS Systems Manager Automation, Amazon SNS Notifications, AWS Health Dashboard, Amazon GuardDuty Response
AWS IAM, SCPs & Permission Boundaries, AWS KMS & Secrets Manager, AWS Config Rules, AWS Security Hub, Amazon Inspector, AWS CloudTrail Governance
Try real exam-style questions from the free sample set. Each answer comes with a full explanation.
A media startup manually deploys and operates several monolithic applications on EC2 instances.
With each deployment, operations engineers directly access servers to install packages and modify configuration files, and manual rollbacks take several hours when deployments fail. Management is requiring the applications to be containerized to ensure deployment consistency and to build an automated CI/CD pipeline from build through testing to production deployment upon code changes. At the same time, since the operations team has limited staff, the management burden of container orchestration infrastructure must be minimized.
What is the MOST appropriate container-based CI/CD modernization approach that meets these requirements while minimizing operational overhead?
Answer: C. ECS Fargate + CodePipeline + CodeBuild
To select the correct answer, you first need to understand the difference in operational overhead between ECS Fargate, ECS EC2, and EKS. The key requirements in this scenario are 'containerization', 'automated CI/CD from build to production deployment', and 'minimizing the management burden of container orchestration infrastructure'. The ECS Fargate + CodePipeline + CodeBuild combination has Fargate fully delegating EC2 instance provisioning, patching, and scaling to AWS, CodePipeline orchestrating the pipeline from code commit through build, test, and deployment, and CodeBuild building Docker images and pushing to ECR in a serverless build environment.
ECS Fargate is a serverless container execution mode where AWS fully manages the underlying EC2 instances needed to run containers — you only specify the vCPU (0.25–16 vCPU) and memory (512MB–120GB) combination in the task definition, and a dedicated isolated environment is automatically provisioned. CodePipeline defines Source → Build → Test → Deploy stages and integrates with CodeBuild, ECR, and ECS at each stage. CodeBuild uses commands in buildspec.yml to build images and push to ECR, and integrating CodeDeploy blue/green deployment with ECS services automates traffic shifting and rollback.
Option 1's ECS EC2 requires directly managing EC2 instance clusters, generating additional operational overhead for AMI patching and instance scaling policy management. Option 2's EKS + Jenkins + Helm creates management burdens across three layers — EKS cluster node groups, Jenkins master/agent servers, and Helm charts — making it the MOST distant from the 'minimize operational burden' requirement. Option 4's Lambda container images are unsuitable for long-running monolithic web applications due to the 15-minute maximum execution time limit and 10GB image size limit. When 'containerization + CI/CD automation + minimize management overhead' appear together in an exam question, select Fargate + CodePipeline + CodeBuild first.
An online education company operates a web application in an Auto Scaling group managed by CloudFormation.
Whenever a new AMI is released, the launch template must be updated and existing instances must be replaced. However, if too many instances are terminated simultaneously during the replacement process, service capacity becomes insufficient and user response times increase sharply. The operations team wants to gradually replace instances while always maintaining the minimum number of healthy instances during CloudFormation stack updates, and this process must be performed automatically without manual intervention.
What is the MOST appropriate CloudFormation-based update strategy that meets this requirement?
Answer: B. AutoScalingRollingUpdate
The MOST critical requirements in this scenario are 'during CloudFormation stack updates', 'gradual instance replacement', 'maintaining a minimum number of healthy instances', and 'automated without manual intervention'. The CloudFormation AutoScalingRollingUpdate policy is defined under the UpdatePolicy attribute, allowing declarative specification of MaxBatchSize for the maximum number of instances to replace at once and MinInstancesInService for the minimum number of healthy instances to maintain during replacement. As a CloudFormation native feature, gradual replacement is performed automatically through stack updates alone, without additional tools.
The AutoScalingRollingUpdate policy has three key parameters. MaxBatchSize controls the maximum number of instances replaced simultaneously, MinInstancesInService specifies the minimum number of instances that must remain in service during replacement, and setting WaitOnResourceSignals to true causes CloudFormation to wait until cfn-signal is received from new instances before proceeding to the next batch. CloudFormation automatically adjusts the replacement pace to prevent the instance count from dropping below MinInstancesInService while replacing instances in batches sequentially.
When 'CloudFormation', 'gradual instance replacement', and 'maintaining minimum healthy instances' appear together in an exam question, select AutoScalingRollingUpdate first. AutoScalingReplacingUpdate replaces the entire existing group with a new group, requiring twice the capacity during replacement, which is not 'gradual replacement'. CloudFormation StackSets specializes in multi-account and multi-region deployments and is unrelated to replacing instances within an Auto Scaling group in a single stack.
A fintech company runs a web application with multiple EC2 instances behind an ALB.
The application depends on a backend database and an external payment API. Recently, even when database connection failures occur, the ALB default TCP health check judges instances as healthy, causing error responses to reach users. The operations team wants to implement a health check that reflects not only the instance itself but also the connectivity status of critical dependent services for that instance, so traffic to the instance is automatically blocked when dependent services fail.
Which approach best meets this requirement while minimizing changes to existing infrastructure?
Answer: C. ALB HTTP deep health check endpoint
To select the correct answer, you first need to understand the difference between ALB's TCP health check and HTTP health check. A TCP health check only verifies whether a port is open, so if the application process is alive despite a database connection failure, the instance is judged as healthy. The ALB HTTP deep health check evaluates instance health based on the HTTP response code from a specific path implemented by the application. When the /health endpoint confirms database and payment API connectivity and returns 503 on failure, ALB automatically removes the instance from the target group. Since only the health check method in the Target Group needs to be switched to HTTP and a /health endpoint added to the application without changing existing ALB infrastructure, it meets the 'minimize changes to existing infrastructure' requirement.
The ALB HTTP health check configures path, healthy HTTP status code range, interval, healthy/unhealthy thresholds, and timeout in Target Group settings. Setting the healthy threshold to 2-3 prevents false positives from transient connection instability, and instances reaching the unhealthy threshold are automatically removed from the Target Group. After health checks recover to the healthy threshold, instances are automatically re-added, implementing a self-healing mechanism.
On the exam, it is easy to confuse this with Route 53 Failover (Option 1). Route 53 performs DNS-level failover, which cannot granularly control traffic at the individual instance level, and DNS TTL makes immediate blocking difficult. CloudWatch Alarm + Auto Scaling replacement (Option 2) replaces unhealthy instances with new ones, taking minutes, and new instances will experience the same problem as long as the dependent service failure persists. When you see requirements for 'ALB-based + dependent service status detection + immediate blocking,' the HTTP deep health check endpoint is the key pattern.
A financial institution is operating a CI/CD pipeline using CodePipeline and CodeBuild.
During the build stage, the CodeBuild project needs to download third-party library archives from a specific S3 bucket, but the security team requires strict enforcement of the principle of least privilege so that the build environment cannot access other S3 buckets or AWS resources. Additionally, storing long-term credentials in the build environment is prohibited by audit policy.
Which approach BEST meets these requirements while configuring CodeBuild to securely access the specific S3 bucket?
Answer: C. CodeBuild Service Role with Least Privilege
A financial institution's CodeBuild project needs to access a specific S3 bucket under two critical constraints: the principle of least privilege that blocks access to all resources other than the specific bucket, and an audit policy prohibiting storage of long-term credentials in the build environment. Option 3's approach of granting a minimum privilege IAM policy to the CodeBuild Service Role satisfies both conditions simultaneously. CodeBuild automatically receives temporary credentials from AWS STS using the permissions of the designated Service Role during build execution, so long-term credentials are never stored in the build environment.
The CodeBuild Service Role is an IAM role where AWS STS (Security Token Service) dynamically issues temporary credentials during build execution, allowing CodeBuild to access AWS resources. By restricting the Resource field in the IAM policy to a specific S3 bucket ARN (arn:aws:s3:::my-libs-bucket/*) and granting only s3:GetObject permission, access to all other S3 buckets and AWS resources is blocked. Temporary credentials are valid only for the build session and automatically expire after build completion, minimizing leakage risk.
On the exam, CodeBuild access to AWS resources is always resolved with Service Role + IAM policy. When 'least privilege' and 'no long-term credentials' appear together, the Service Role is the only correct answer. Environment variable Access Keys violate long-term credential storage, and credentials stored in Secrets Manager are still long-term credentials and do not fully satisfy the audit policy.
A large e-commerce company operates hundreds of EC2 instances.
A regular cost review reports that a significant number of instances are over-provisioned with average CPU utilization below 5%. The operations team manually analyzes CloudWatch metrics for each instance to determine appropriate instance types, but this process takes weeks due to the large number of instances. Management requires that instance sizing recommendations aligned with workload characteristics be automatically derived for cost reduction and must be applicable without performance degradation.
Which approach best meets this requirement while minimizing operational overhead?
Answer: B. AWS Compute Optimizer recommendations
AWS Compute Optimizer simultaneously meets three requirements in this scenario: automation, sizing without performance risk, and minimal operational overhead. Compute Optimizer uses machine learning to analyze CloudWatch metrics (CPU utilization, network I/O, disk I/O, memory — CloudWatch agent required) and automatically derives optimal instance type recommendations and performance risk levels (low, medium, high) for each instance. Without manually analyzing hundreds of instances over weeks, you can immediately see the status of the entire organization and precisely identify instances that can be downsized without performance degradation.
Compute Optimizer analyzes a minimum of 14 days of metrics and can extend to up to 93 days with the Enhanced Infrastructure Metrics option to capture periodic workload patterns. Recommendation results provide current type, recommended type, estimated cost savings, and performance risk level per instance, classified into four grades: over-provisioned, optimal, under-provisioned, and insufficient data. Organization-wide opt-in through AWS Organizations enables centralized recommendation management even in multi-account environments.
On the exam, you must distinguish Trusted Advisor (Option 3) and Cost Explorer Rightsizing (Option 4). Trusted Advisor uses simple threshold rules based on 14-day average CPU below 10% and does not recommend specific replacement instance types, requiring Business or higher Support plans. Cost Explorer Rightsizing performs cost-centered analysis with less sophisticated performance risk classification. When you see the keyword combination 'large-scale EC2 + ML-based automatic sizing + performance risk classification + minimal operations,' Compute Optimizer is the correct answer.
The AWS Certified DevOps Engineer - Professional (DOP-C02) exam consists of 75 questions with a 180-minute time limit.
The passing score for the DOP-C02 exam is 750 out of 1000.
The DOP-C02 sample set (20 questions with full explanations) is free. The full bank of 280+ questions is available with a CloudMasterIT subscription.
The DOP-C02 certification is valid for 3 years after passing. Recertification is required after that.