AWS Certified DevOps Engineer Professional DOP-C02 (DOP-C02) — Questions 451–525

(ECS deployment circuit breaker) is correct because it automatically detects failed deployments (e.g., health check failures) and triggers a rollback to the previous version. With a 200% percent start rolling update, the new version starts before the old is stopped; if health checks fail, the circuit breaker initiates a rollback. Option B (ECS service auto recovery) recovers from underlying infrastructure failures, not deployment failures.

Option C (ECS managed scaling) adjusts desired count based on load, not deployment health. Option D (CloudWatch alarm actions) can trigger rollback events but is not an ECS built-in feature; it requires custom automation. Therefore, the correct ECS feature for automatic rollback is the deployment circuit breaker.

S3 Versioning is the primary feature that protects against accidental deletion and overwrite by preserving all versions of objects. When versioning is enabled, deleted objects are replaced with a delete marker and previous versions can be restored. MFA Delete (option D) is an additional security feature that requires multi-factor authentication for versioning operations, but versioning itself is the foundational protection.

Option A (cross-region replication) is used for geographic redundancy and compliance, not for protecting against accidental deletions. Option B (bucket policy denying DeleteObject) would prevent deletions but does not protect against overwrites (PutObject) and can be overly restrictive; also, it may not allow legitimate deletions if not carefully scoped. Therefore, enabling S3 Versioning is the correct and most straightforward solution.

Options A, B, and E are correct. Option A creates a new launch configuration with the patched AMI, ensuring that new instances launched from it are patched. Option B updates the Auto Scaling group to use the new launch configuration, causing the group to replace existing instances with patched ones (via instance refresh or scale-in/out).

Option E uses an AWS Systems Manager Maintenance Window to apply patches to existing instances, which is necessary if you want to patch instances without replacing them entirely. Option C (CodeDeploy) is not appropriate for OS patching; it is used for application deployments. Option D (CloudWatch Events) could be used to automate the process but is not a required step for the core solution.

The correct first step is to enable and analyze ALB access logs (Option A). ALB access logs contain detailed information about each HTTP request, including the response status code (e.g., 503), target response time, and the specific target that handled the request. By filtering for 503 errors and correlating with high target response times, the engineer can identify whether the errors are caused by slow or failing targets.

Option B (increasing desired capacity) does not address the root cause and may not help if the issue stems from target health or configuration. Option C (disabling connection draining) can worsen the problem by abruptly terminating in-flight requests, increasing errors. Option D (reviewing CloudTrail logs) is not useful because CloudTrail captures API changes, not HTTP-level errors.

The condition 'kms:GrantIsForAWSResource' restricts the permission to requests that come from AWS services that integrate with KMS (e.g., S3, Lambda) rather than direct API calls from the role. As a result, when the IAM role 'AdminRole' attempts to call kms:Decrypt directly, it receives an access denied error. Option C is correct.

Option A is incorrect because 'kms:Decrypt' is the correct action; wildcards are not needed. Option B is incorrect because the resource can be '*' in a key policy since the policy is attached to the key itself, scoping it automatically. Option D is incorrect because the principal ARN is correctly specified as the IAM role in the account.

CloudWatch Synthetics canaries automatically log execution details, including errors, to CloudWatch Logs. Reviewing these logs provides specific error information, such as 'ClientError' details. Option C is correct because each canary runs as an AWS Lambda function, and the Lambda function's CloudWatch Logs contain runtime logs, including any exceptions or errors thrown during execution.

Option A is incorrect because while adding logging could be a long-term improvement, the question asks for diagnostic actions; the canary already logs to CloudWatch Logs, so modifying the script is not necessary for diagnosis. Option D is incorrect because CloudWatch metrics provide aggregate statistics (e.g., success/failure rates) but not detailed error codes or messages. Option E is incorrect because CloudTrail records API calls to create, start, or stop canaries, not the execution details of individual canary runs.

Using a customer-managed KMS key with a cross-account key policy allows encrypting artifacts in CodePipeline's artifact store, ensuring that only authorized accounts can decrypt them, meeting the requirement for encrypted artifacts and least privilege. Option B is correct because storing database credentials in AWS Secrets Manager and retrieving them in CodeBuild using the secrets manager action avoids hardcoded credentials and provides secure, rotating credentials. Option E is correct because configuring CodePipeline to assume an IAM role in the target account using a trust policy enables cross-account deployment with least privilege, as the pipeline assumes a role with only necessary permissions.

Option C is incorrect because while SSM Parameter Store can store credentials, Secrets Manager is specifically designed for secrets management with automatic rotation and is more appropriate for database credentials. Option D is incorrect because CodeCommit with pull request approval rules is a source control practice, not directly addressing the security requirements of no hardcoded credentials, least privilege cross-account access, or encrypted artifacts.

Conditional writes prevent overwriting data unless a specified condition is met, thereby reducing write conflicts by ensuring that updates are only applied when the data is in a known state. Application-level conflict resolution allows the application to handle conflicts when they occur, using custom logic to merge or resolve differences, which reduces the impact of conflicts on the database. Option D (increasing write capacity) does not reduce conflicts; it only increases throughput capacity.

Option A (reducing read capacity) is unrelated to write conflicts. Option B (DynamoDB Streams with last writer wins) is the default behavior and does not reduce conflicts; it may cause data loss.

The SSM Agent requires outbound internet connectivity to the Systems Manager endpoints (or AWS PrivateLink if configured) to communicate with the service. If the patch window or a security group change blocks this connectivity, instances become unreachable despite the agent logs showing no errors. Option A is wrong because restarting the agent does not help if the issue is network connectivity.

Option B is wrong because the patch baseline association defines which patches to apply, not connectivity. Option C is wrong because IAM permissions are likely correct since the agent logs show no errors; the issue is network-related, not permissions.

The issue is memory pressure, not CPU. Adding a target tracking scaling policy based on average memory utilization with a target value of 75% will cause the ECS service to automatically scale out when memory utilization exceeds the target, preventing performance degradation due to high memory usage. Option B (decreasing CPU target to 50%) is incorrect because CPU utilization was not the bottleneck.

Option C (increasing minimum tasks to 5) provides static capacity but does not dynamically respond to memory spikes, leading to wasted resources or insufficient scaling. Option D (increasing task memory limit) is a static change that may help temporarily but does not provide dynamic scaling; auto scaling based on memory is the recommended approach.

The deployment failed due to a script error in the BeforeInstall lifecycle event. The root cause is the script itself, so fixing the script error in the revision and redeploying addresses the issue permanently. Option A is wrong because setting 'ignoreScriptFailure' to true would mask the error and could lead to application issues.

Option B is wrong because manually running the script on an instance does not fix the underlying issue in the revision, and the deployment will fail again. Option D is wrong because changing the deployment configuration to 'AllAtOnce' does not fix the script error and may cause more instances to fail simultaneously.

Options B and D are correct. Option B: CodeBuild can run unit tests on feature branches before merging, ensuring code quality. Option D: Separate pipelines for develop and master branches allow different deployment behaviors (e.g., non-prod vs. prod).

Option A is wrong because disabling automatic triggers on the master branch would prevent automated deployments when changes are merged, which is contrary to GitFlow where master deployments are desired. Option C is wrong because a single pipeline for all branches reduces flexibility and can cause unintended deployments. Option E is wrong because CodePipeline does not natively support pull request triggers; use CodeBuild or other services for that.

A NAT gateway deployed in a public subnet allows instances in private subnets to initiate outbound traffic to the internet while preventing inbound connections from the internet. This matches the requirement for downloading patches without direct accessibility. Option B is correct.

Option A is incorrect because a VPN connection provides access to an on-premises network, not general internet access. Option C is incorrect because a bastion host provides SSH/RDP access to instances, not outbound internet connectivity for patch downloads. Option D is incorrect because attaching an internet gateway and adding a route to the private subnet route table would make the instances directly accessible from the internet, violating the requirement.

To enable caching for the Maven local repository in AWS CodeBuild, two steps are required: (1) Add a `cache` section in the buildspec file specifying the paths to cache (e.g., ~/.m2) — this is option D. (2) Create an S3 bucket to store the cache and configure the CodeBuild project to use that bucket for caching — this is option E. Option A (setting MAVEN_OPTS) is not necessary because the default Maven repository path is already ~/.m2. Option B (uploading as a build artifact) is for saving output artifacts, not for caching.

Option C ('Local cache' mode) is a different feature used for Docker layer caching, not for Maven dependencies. Therefore, options D and E are correct.

Options B and E are correct. To restrict KMS key usage to within the VPC, you first create a VPC endpoint for AWS KMS (Option E) to allow private connectivity. Then, you modify the KMS key policy to include a condition that requires the request to originate from that VPC endpoint, using the kms:ViaService condition key (Option B).

Option A is wrong because security groups do not apply to KMS keys; they are used for EC2 instances and network interfaces. Option C is wrong because S3 bucket policies cannot restrict which KMS key is used for encryption; they can only restrict S3 actions. Option D is wrong because service control policies (SCPs) apply at the organizational level and cannot restrict KMS key usage to a specific VPC; key policies are the correct mechanism.

The correct approach is to use a custom Chef recipe and run it on the layer using OpsWorks 'Run Command'. This allows applying configuration changes to all instances in the layer without downtime, as OpsWorks executes the recipe on each instance without requiring instance recreation. Option B is incorrect because Auto Scaling lifecycle hooks are used to execute actions during instance launch or termination, not for runtime configuration updates.

Option C is incorrect because cloning a layer creates a new layer and does not apply changes to existing instances; switching traffic would involve additional steps and potential downtime. Option D is incorrect because manually SSHing into each instance is error-prone, not scalable, and violates best practices for configuration management.

Encryption at rest for Amazon RDS is enabled by turning on RDS encryption when creating the instance. Encryption in transit is achieved by enforcing SSL/TLS connections for client connections to the database. Option C correctly combines both: enabling RDS encryption for at-rest security and enforcing SSL for in-transit security.

Option A (AWS Certificate Manager) provides certificates but does not directly encrypt the RDS instance. Option B (private subnet with VPC peering) addresses network isolation, not encryption. Option D (client-side encryption with KMS) encrypts data before insertion but does not use RDS encryption and is not a standard RDS feature.

The CreationPolicy attribute can be added to a resource to ensure that CloudFormation waits for a specified number of success signals before considering the resource created. When a stack update causes a resource replacement, CloudFormation creates the new resource, waits for the creation signals (if a CreationPolicy is defined), and only then deletes the old resource. This ensures the new resource is fully operational and tested before replacement.

The other options are incorrect: UpdatePolicy with AutoScalingRollingUpdate is for updating instances in an Auto Scaling group without full replacement; DeletionPolicy Retain keeps the old resource but does not manage creation; DependsOn controls creation order but does not wait for testing signals.

The CloudTrail log entry shows a PutBucketPolicy action that sets a bucket policy with principal '*', granting public read access to all objects in the bucket. This is a security concern because the bucket becomes publicly accessible, allowing anyone on the internet to read objects. Option A is correct because the bucket policy makes the bucket publicly accessible.

Option B is incorrect because the bucket policy does not grant the root user full access; it grants public access. Option C is incorrect because the action is performed by an IAM user (the user field shows 'arn:aws:iam::123456789012:user/admin'), not the root user. Option D is incorrect because the policy allows all principals (public) to read objects, not just authenticated users.

Options A, B, and E are correct. Option B: Enabling CloudTrail in the management account with an organization trail captures all API activity across accounts. Option A: Creating a CloudWatch Logs metric filter on the organization's CloudTrail log group for 'CreateUser' events captures the specific event.

Option E: Setting a CloudWatch alarm on the metric sends notifications via SNS. Option C is wrong because configuring an S3 bucket with event notifications does not directly enable centralized monitoring and alerting for IAM user creation. Option D is wrong because AWS Config rules are used for resource configuration compliance, not for real-time API call monitoring like IAM user creation.

CodeBuild can assume an IAM service role with a policy that grants pull access to the ECR repository. This is the most secure approach because it avoids static credentials and leverages AWS identity and access management. Option A is wrong: a VPC endpoint provides private network connectivity to ECR but does not grant access; IAM permissions are still required.

Option B is wrong: storing ECR credentials in Parameter Store introduces static credentials that must be managed and rotated, making it less secure than using an IAM role. Option D is wrong: using the AWS CLI to retrieve an authorization token requires managing temporary credentials and is more complex; the service role approach is simpler and more secure.

AWS X-Ray provides end-to-end tracing for requests, allowing you to identify performance bottlenecks and errors in Lambda functions. Option D is correct because Lambda automatically sends logs to CloudWatch Logs, which capture application output, errors, and custom logging. Option A is incorrect: VPC Flow Logs monitor network traffic at the VPC level, not Lambda function internals.

Option B is incorrect: AWS Config evaluates resource configurations for compliance, not for function monitoring. Option E is incorrect: The CloudWatch Agent is for EC2 or on-premises servers; Lambda already integrates with CloudWatch Logs natively.

Amazon ElastiCache for Redis provides a highly available, scalable, and low-latency in-memory data store ideal for session state management in a containerized environment. It supports replication and automatic failover, ensuring resilience. Option B (Amazon EFS) is a file storage service with higher latency and not designed for sub-millisecond session retrieval.

Option C (ephemeral storage on the container instance) is not durable; data is lost when the container stops or fails. Option D (Amazon S3) is object storage with higher latency and not optimized for frequent read/write operations required for session state.

Amazon CloudWatch Events can be configured to send a notification (e.g., via SNS or email) to the security team before the scheduled annual key rotation date, ensuring awareness of the rotation. Option B is incorrect because S3 bucket policies cannot enforce KMS key rotation; key rotation is a property of the KMS key itself. Option C is correct because enabling automatic key rotation on a symmetric KMS key causes AWS KMS to rotate the backing key annually, meeting the requirement for automated rotation.

Option D is incorrect because there is no `kms:RotateKeyOnDemand` action; automatic rotation does not require a specific key policy action, and manual rotation uses `ScheduleKeyDeletion` or creating new keys. Option E is correct because creating a new KMS key each year and updating the application to use the new key is a valid manual approach to ensure annual key rotation, fulfilling the security team's requirement to rotate keys every year.

Route 53 health checks are configured to check the ALB endpoint. During a regional outage, if the ALB itself remains healthy (e.g., the outage only affected the instances but not the ALB), the health check passes, so Route 53 does not trigger failover. This leads to users experiencing downtime because the instances behind the ALB are unhealthy, but Route 53 still directs traffic to the primary region.

Option B is incorrect because failover with Route 53 is automatic when a health check fails; no manual intervention is required. Option C is incorrect because Route 53 health checks do not need to check instance IPs; checking the ALB is sufficient for failover as long as the ALB's health reflects instance health, but in this case it doesn't. Option D is incorrect because Route 53 can failover to a different region when the primary endpoint becomes unhealthy, but the condition for failover (health check failure) was not met.

Omit the BucketName property so CloudFormation generates a unique name. Amazon S3 bucket names must be globally unique across all AWS accounts. If you specify a custom BucketName, you must ensure its uniqueness yourself, which is error-prone.

By omitting BucketName, CloudFormation automatically generates a unique name that includes a random suffix, guaranteeing global uniqueness. Option A (DeletionPolicy) controls what happens when the stack is deleted, not naming. Option B (setting BucketName to a unique value via parameter) still requires manual uniqueness and is not a property that ensures uniqueness automatically.

Option C (UpdateReplacePolicy) controls replacement behavior on updates, not naming. Therefore, omitting BucketName is the simplest way to ensure a unique name.

The error 'CREATE_FAILED - S3 bucket already exists' despite using a unique bucket name indicates that the bucket name was previously used and is still in a deletion state. S3 bucket names are globally unique and cannot be reused immediately after deletion; there is a waiting period for the name to be released. Option B is correct because the bucket name is not yet available.

Option A is incorrect because the IAM user likely has sufficient permissions if the bucket creation fails only during update. Option C is incorrect because the region would not cause this specific error. Option D is incorrect because the resource type is appropriate.

The alarm is configured with EvaluationPeriods=1, meaning it requires only one high datapoint to trigger ALARM. The CPU spiked to 100% at 09:55, causing the alarm to enter ALARM state. Even though CPU utilization has since dropped to 10%, the alarm remains in ALARM until it evaluates a sufficient number of low datapoints to transition to OK.

Since only one high datapoint was needed to trigger, only one low datapoint is needed to return to OK, but the alarm may not have evaluated the latest low datapoint yet, or the alarm's state transition period may not have elapsed. Option A is wrong because the metric exists and is being emitted. Option B is wrong because the threshold is set to 90%, which is appropriate.

Option D is wrong because the CPUUtilization metric is being emitted, as evidenced by the spike.

Options B, D, and E are correct. An SCP can centrally deny s3:PutBucketAcl actions that make buckets public, preventing public access across all accounts (B). AWS Config with the managed rule 's3-bucket-public-read-prohibited' can detect publicly accessible buckets across accounts when using an aggregator (D).

CloudWatch Events (now Amazon EventBridge) can trigger a Lambda function to automatically remediate non-compliant buckets, such as applying a bucket policy or ACL change (E). Option A (Trusted Advisor) is per-account and only alerts, not remediates; Option C (manual review) is not scalable for multiple accounts.

Options B, C, and E are correct. To set up centralized logging across multiple AWS accounts using AWS Organizations: B) Create an S3 bucket in the central logging account with a bucket policy that allows cross-account writes from other accounts. C) Enable AWS CloudTrail in each account and configure it to deliver logs to the centralized S3 bucket.

This captures API activity. E) Configure Amazon CloudWatch Logs subscription filters in each account to stream logs (e.g., from applications or services) to the centralized S3 bucket via Kinesis Data Firehose. Option A (VPC Flow Logs) is not required for all accounts—it can be selectively enabled.

Option D (Kinesis Data Streams) is not necessary; logs can be delivered directly to S3 via Firehose or CloudTrail.

Registering EC2 instances in a second Availability Zone with the NLB target group allows NLB to route traffic to healthy instances across zones, providing high availability during a zone outage. Option A is incorrect because using a larger instance type and enabling detailed CloudWatch monitoring does not add redundancy across zones. Option B is incorrect because replacing NLB with an ALB still requires multi-AZ configuration to achieve high availability; cross-zone load balancing is already available on NLB.

Option C is incorrect because scheduled scaling does not protect against zone failures; it only adjusts capacity predictably.

RDS Proxy helps minimize write outages during failover by managing database connections efficiently. It maintains connection pools and automatically routes connections to the new primary after failover, reducing the outage window from seconds to sub-second. Option A (increasing instance class) does not affect failover time because failover duration is dominated by DNS propagation and database recovery, not instance size.

Option C (Route 53 weighted record with health checks) is not suitable because Multi-AZ failover already handles DNS updates automatically, and using a weighted record with health checks would require additional complexity and still involve DNS propagation delays. Option D (using read replica endpoint for writes) is invalid because read replicas do not accept write operations; they are read-only.