DOP-C02 practice questions and answers

Correct answer: B — Use AWS CodeDeploy with an ECS blue/green deployment group, a canary or linear traffic-shifting configuration, and a CloudWatch alarm registered on the deployment group for automatic rollback.

CodeDeploy blue/green for ECS creates a replacement task set, runs it behind a test listener, shifts production traffic in canary or linear steps, and rolls back automatically when an associated CloudWatch alarm goes into ALARM. Rolling updates replace tasks in place with no traffic-shifting control and no alarm-driven rollback. Manual target group weights and operator-reported errors fail the 'automatic, within minutes' requirement. CloudFormation rollback only triggers when the stack update itself fails — a healthy deploy that returns 5xx to users is a successful stack update as far as CloudFormation is concerned.

Correct answer: A, B, C — In Account T, create a customer managed AWS KMS key whose key policy allows the pipeline service role and Account P to use it, and an artifact S3 bucket whose policy grants Account P read access. · In Account P, create a cross-account IAM role that Account T can assume, and add sts:AssumeRole for that role to the pipeline service role in Account T. · In Account P, create a CloudFormation service role with the permissions needed by the resources in the stack, and reference the Account P resources in the pipeline's deploy action in Account T.

Cross-account CodePipeline has three moving parts. First, artifacts live in the pipeline account and are encrypted with a customer managed KMS key — an AWS managed key cannot be shared across accounts, which is why option F fails. Second, the pipeline assumes a role that exists in the target account, so the role lives in Account P and the AssumeRole permission lives on the pipeline role in Account T. Third, CloudFormation acts inside the target account, so the service role for the stack must exist in Account P; a role in Account T cannot be passed to CloudFormation in Account P.

Correct answer: A — Configure the CodeBuild project with the VPC, private subnets and a security group allowed by the database, and add VPC endpoints for S3, ECR API, ECR Docker and CloudWatch Logs.

A CodeBuild project can be attached to your VPC, which places the build ENI in your subnets so it can reach the database privately. Without internet access, the build still needs to reach AWS services, and that is what the gateway endpoint for S3 and the interface endpoints for ECR and CloudWatch Logs provide. CodeBuild does not publish stable public IP ranges you can allow-list per project, spinning up EC2 instances rebuilds a service you already have, and you cannot peer with the CodeBuild service VPC.

Correct answer: A — Define the function in AWS SAM with AutoPublishAlias and a CodeDeploy canary DeploymentPreference, add PreTraffic and PostTraffic hook functions, and attach CloudWatch alarms to the deployment.

SAM's DeploymentPreference wires the function alias to CodeDeploy, which shifts alias weights in canary or linear steps, runs the PreTraffic and PostTraffic hooks, and rolls back automatically when a listed CloudWatch alarm fires. Emailing the on-call engineer keeps a human in the rollback path. A second stage plus a CloudFront origin swap is an all-or-nothing cutover with a slow DNS/cache tail. CloudFormation change sets have no traffic hooks at all — that option only sounds plausible.

Correct answer: A — Use CloudFormation StackSets with service-managed permissions, target the Workloads OU, enable automatic deployment, and list the four Regions.

Service-managed StackSets integrate with Organizations: you target an OU, and automatic deployment creates stack instances in accounts that join it and removes them from accounts that leave. Self-managed permissions require you to create the administration and execution roles per account, which is the manual work being avoided. There is no --regions parameter on create-stack — it takes a single --region. Change sets preview updates to one stack; they do not deploy across accounts.

Correct answer: A, B — The Config rule calls the CloudFormation DetectStackDrift API, and the rule defaults to NON_COMPLIANT when those calls are throttled. · CloudFormation does not support drift detection for custom resources.

Two separate things are happening. The Config rule depends on DetectStackDrift, and when those API calls are throttled the rule falls back to NON_COMPLIANT even though the stack is genuinely in sync. Separately, custom resources are not a supported resource type for drift detection, so no amount of configuration will produce drift results for them. A permissions problem produces a different, explicit message about the CloudFormation role. It is true that drift only covers explicitly set properties, but that does not bring unsupported resource types into scope, and treating the finding as noise to ignore hides real throttling.

Correct answer: A — DeletionPolicy: Retain and UpdateReplacePolicy: Retain on both resources.

DeletionPolicy covers stack deletion and UpdateReplacePolicy covers the case where an update would replace a resource — you need both attributes to protect data through either path. Snapshot is valid for RDS but not for S3 buckets, and it still removes the live resource. CreationPolicy waits for signals during creation and has nothing to do with deletion. Termination protection blocks deleting the whole stack but does nothing about a replacement during an update.

Correct answer: A — Add an Aurora Replica in another Availability Zone and point the application at the cluster endpoint, and put Amazon RDS Proxy in front of the cluster.

The instance endpoint always points at one specific instance, so it cannot follow a failover. Adding a replica in a second AZ gives Aurora somewhere to fail over to, and the cluster endpoint always resolves to the current writer. RDS Proxy holds a warm connection pool and keeps client connections open during the failover, which is exactly what an app that churns short-lived connections needs. A bigger instance does not survive a failover, snapshot restore is measured in minutes to hours, and the reader endpoint cannot accept writes.

Correct answer: A — Add an Auto Scaling lifecycle hook for instance termination that puts the instance in Terminating:Wait, run the final upload from a script or SSM Automation, then call CompleteLifecycleAction.

A termination lifecycle hook pauses the instance in Terminating:Wait, which is the supported window for flushing logs, draining connections or deregistering. The hook completes when your automation calls CompleteLifecycleAction or the timeout expires. Scale-in protection blocks scale-in entirely rather than making it safe. The health check grace period only delays health checks after launch. The termination policy chooses which instance goes, not how long it takes to go.

Correct answer: A — Create a metric filter on the log group that matches CRITICAL, publish it as a custom metric, and create a CloudWatch alarm on that metric with an Amazon SNS topic the security team subscribes to.

Metric filters turn matching log lines into a numeric metric that a standard CloudWatch alarm can watch, and the alarm action publishes to SNS — no servers, no code. Metric streams carry metrics, not log events, so they cannot search log text for a keyword. Lambda Insights is performance monitoring for Lambda functions and has no log-keyword alerting. Flow logs describe network traffic and say nothing about appliance severity levels.

Correct answer: A — Configure CloudWatch cross-account observability: set up a monitoring account and link the source accounts so their logs, metrics and traces are visible centrally.

Cross-account observability is built for exactly this: link source accounts to a monitoring account and engineers query logs, metrics and X-Ray traces across all of them from one console, with no pipeline to run. Firehose to S3 plus Athena works but is a data pipeline you now own, and it loses the live console experience. Role switching keeps the per-account clicking. Daily exports are far too slow for incident response.

Correct answer: A — Create an Amazon EventBridge rule matching GuardDuty findings with severity 7.0 or higher that starts an AWS Step Functions workflow to replace the instance's security groups with a quarantine group, create EBS snapshots, and publish to Amazon SNS.

GuardDuty publishes findings as EventBridge events, and an EventBridge rule can filter on severity and invoke Step Functions or Lambda — that gives you an ordered, retryable workflow for quarantine, snapshot and notify. GuardDuty has no built-in auto-remediation actions to switch on. An alarm on finding counts notifies but never isolates anything. Polling GetFindings adds delay and duplicate-handling logic for an event source that already pushes.

Correct answer: A — Enable the AWS Config managed rule s3-bucket-public-read-prohibited and attach an automatic remediation action that runs the AWS-DisableS3BucketPublicReadWrite Systems Manager Automation runbook.

A Config managed rule detects the non-compliant bucket, and Config remediation runs an SSM Automation runbook to fix it, with the compliance timeline and Automation execution history serving as the audit record. A nightly job leaves buckets exposed for up to a day. An SCP denying PutBucketAcl outright blocks legitimate work and does nothing about buckets that are already public. Access logging records reads; it does not fix permissions.

Correct answer: A — Enable Amazon Inspector for EC2 and ECR scanning with the SSM Agent installed on instances, and install the CloudWatch agent to ship the operating system authentication logs to CloudWatch Logs.

Amazon Inspector is the vulnerability management service: it scans EC2 instances (using the SSM Agent for inventory) and ECR images continuously, and reports network reachability. Sign-in activity lives in the OS logs, so the CloudWatch agent is what gets it into CloudWatch Logs — CloudTrail records AWS API calls, not SSH logins. GuardDuty is threat detection, not vulnerability scanning. Config rules check configuration, flow logs show traffic not identities, and ECR basic scanning covers only OS packages in images.

Correct answer: A — Store the credential in AWS Secrets Manager with rotation enabled, reference it in the buildspec with the secrets-manager environment variable type, and grant the CodeBuild service role secretsmanager:GetSecretValue and kms:Decrypt.

CodeBuild resolves environment variables of type SECRETS_MANAGER at build time and masks them in logs, and Secrets Manager rotation replaces the value on a schedule with no change to the buildspec. A PLAINTEXT variable is exactly what the requirement forbids, and private logs do not remove the value from the build definition. Committing secrets to Git leaves them in history forever. Fetching from S3 is a hand-rolled secret store with no rotation and no log masking.