AWS Certified DevOps Engineer Professional DOP-C02 (DOP-C02) — Questions 1–75

18600 requests. The AWS CLI command retrieves the RequestCount metric with a period of 300 seconds (5-minute intervals). Each datapoint's Sum value represents the total number of requests received in that 5-minute window.

To find the total requests for the entire hour, sum all 12 datapoints. The exhibit shows datapoints like 1500, 2000, ... 1800, and their total is 18600. Option B (3500) is incorrect because it only sums two datapoints instead of all twelve.

Option C (36000) is incorrect because it likely multiplies a single datapoint by 12 without considering the actual values. Option D is incorrect because the total is determinable by summing the datapoints.

To ensure resilience to Availability Zone failures, the company should spread tasks across multiple AZs (Option A) so that if one AZ fails, the tasks in other AZs continue to serve traffic. Additionally, enabling Service Auto Scaling (Option B) helps maintain the desired task count across AZs by automatically replacing tasks in failed AZs. Option C is incorrect because a single Network Load Balancer can route traffic across all AZs; placing one per AZ is unnecessary and adds complexity.

Option D is irrelevant since placement groups apply to EC2 instances, not Fargate tasks. Option E is the opposite of resilience—placing all tasks in one AZ creates a single point of failure.

Container Insights for Amazon ECS with Fargate collects CPU, memory, and other metrics, while ServiceLens integrates CloudWatch metrics with AWS X-Ray traces to provide end-to-end visibility. This correlation allows the engineer to identify high CPU usage and its impact on request latency. Option A is incorrect because CloudWatch Logs Insights only analyzes log data, not metrics or traces.

Option C is incorrect because CloudWatch Synthetics canaries monitor endpoint availability and performance from outside, but do not provide internal CPU metrics. Option D is incorrect because setting up a Prometheus server on an EC2 instance adds operational overhead and does not integrate with ECS Fargate natively; Container Insights and ServiceLens are the recommended AWS-native solution.

AWS Systems Manager Parameter Store supports secure string parameters that are encrypted at rest using AWS KMS. It integrates with EC2 instances via the SSM Agent for secure retrieval in transit, making it ideal for sensitive configuration values like database passwords. Option A is correct.

Option B (CloudFormation template parameters) are not designed for storing secrets and are passed at stack creation time, not dynamic retrieval. Option C (DynamoDB with encryption) is a NoSQL database, not a configuration store. Option D (S3 with SSE) is object storage, not optimized for parameter management or EC2 integration.

The correct solution is to use a blue/green deployment with CodeDeploy and automatic rollback enabled. In a blue/green deployment, a new Auto Scaling group (green) is created alongside the existing one (blue). Traffic is shifted to the green group only after all health checks pass.

If health checks fail, the deployment is automatically rolled back by terminating the green group, ensuring no traffic is routed to unhealthy instances. This prevents any outage. Option B (in-place deployment with rollback) updates instances in place, which can cause downtime if instances fail health checks, as the Auto Scaling group replaces them sequentially, potentially routing traffic to unhealthy instances.

Option A (manual approval) slows down deployment and does not automate rollback based on health checks. Option D (increasing health check grace period) only delays detection of failures and does not prevent traffic from being routed to unhealthy instances.

AWS OpsWorks allows you to define custom Chef recipes that run during specific lifecycle events (e.g., Setup) on new instances. By adding a custom recipe to the layer's configuration, you can automate the installation of a custom agent. Option B is incorrect because the layer's built-in configuration is for default OpsWorks settings, not custom agent installation.

Option C is incorrect because custom JSON passes attribute data to recipes but does not execute installation commands directly. Option D is incorrect because storing scripts in a cookbook repository does not automatically run them; you must assign the recipe to the layer's lifecycle events.

Sticky sessions rely on the instance ID to route requests. During a deployment, Auto Scaling launches new instances and terminates old ones. The target group's deregistration delay controls how long the ALB waits before forcibly closing connections to deregistering instances.

If this delay is too short, in-flight requests and sessions are abruptly terminated, causing users to lose their sessions. Options A, B, and D are incorrect: lifecycle hooks (A) are for custom actions, not directly related to session loss; stickiness duration (B) affects how long a session sticks to an instance but does not cause loss during deployment; and health check interval (D) affects availability but not session persistence.

The most likely cause is that the website is fronted by Amazon CloudFront, which caches the old content. Even though the 'aws s3 sync' command successfully updates the objects in the S3 bucket, CloudFront continues to serve the cached version until the cache TTL expires or a cache invalidation is performed. Option A is incorrect because the CodeBuild project must have write permissions to the S3 bucket for the sync command to succeed; if it lacked permissions, the sync would fail.

Option B is incorrect because the S3 bucket is already configured for static website hosting (implied by the website being accessible). Option D is incorrect because the bucket policy does not affect the ability to serve updated objects; public access is likely already granted for the website to be served. Therefore, the caching behavior of CloudFront is the reason the website shows old content.

Fargate tasks require network connectivity to pull container images from ECR (or Docker Hub) and to send logs to CloudWatch. Without a route to a NAT Gateway (for private subnets) or an Internet Gateway (for public subnets), the task cannot pull the image and fails to start. Option B is incorrect: while the image must exist, the immediate symptom of tasks failing to start when the image is missing would be an 'image not found' error, not a generic failure; the security group already allows inbound traffic on port 8080, but outbound connectivity is the issue.

Option C is incorrect: insufficient CPU/memory would cause tasks to enter a 'CPU exhausted' or 'memory exhausted' state, not prevent them from starting entirely. Option D is incorrect: the security group allows inbound traffic, but the issue is about egress connectivity for the task to reach the image registry.

The deregistration delay setting controls how long the ALB continues to send requests to an instance that is being deregistered. If this delay is too long, the ALB may route traffic to an instance that has already stopped accepting connections, resulting in 503 errors even though the health checks pass. Option A is incorrect because a missing security group rule would prevent any traffic from reaching the ALB, causing connection timeouts rather than 503 errors.

Option B is incorrect because the instance health checks are passing (as stated), so the health check path must be correct. Option D is incorrect because disabling cross-zone load balancing affects traffic distribution but does not cause 503 errors.

The cache is configured to store the Maven local repository at '/root/.m2', but Maven by default stores dependencies in the home directory of the user running the build (e.g., '/root/.m2'). However, the build may be running as a different user or Maven may be configured to use a different local repository path (e.g., via settings.xml or the 'maven.repo.local' property). If the dependencies are not being written to '/root/.m2', the cache will not capture them, and dependencies will be re-downloaded.

Option A is incorrect because the cache is being downloaded and uploaded, but the issue is that the cache does not contain the dependencies. Option B is incorrect because S3 bucket region does not prevent cache download/upload, and logs show cache is being transferred. Option C is incorrect because the buildspec includes the cache section correctly, as shown by the cache operations in logs.

To scale an ECS service based on a custom metric like active user sessions, you can publish the metric to Amazon CloudWatch and then create a target tracking scaling policy in Application Auto Scaling for the ECS service. Application Auto Scaling uses the CloudWatch metric to automatically adjust the desired count. Option A is incorrect because AWS Auto Scaling is for EC2 Auto Scaling, not for ECS services; Application Auto Scaling is the correct service.

Option B is incorrect because manual adjustment based on a dashboard does not provide automated scaling. Option D is incorrect because while a Lambda function could be used to update the desired count, it introduces unnecessary complexity and is not the recommended approach; using Application Auto Scaling with CloudWatch is the standard solution.

503 errors often indicate that the ALB cannot establish a connection to the targets. The most common cause is that the security groups attached to the EC2 instances are not allowing inbound traffic from the ALB on the listener port. Option A is incorrect because AWS Shield Advanced is a DDoS protection service; the ALB being healthy in logs suggests no DDoS attack is causing the 503 errors.

Option B is incorrect because an expired SSL certificate would cause different errors (e.g., 502 or handshake failures), not 503. Option D is incorrect because checking health check settings is a valid troubleshooting step, but since the engineer already verified the ALB is healthy in access logs (meaning the ALB itself is operational), the immediate next step should be to verify security groups, which are a common cause of connectivity issues.

The most likely cause is that the application is caching the secret and not refreshing it after rotation. By default, the AWS SDK for Secrets Manager caches secrets in memory for a configurable TTL (default 1 hour). Even though the secret is rotated in Secrets Manager, the application will continue to use the cached old secret until the cache expires or is explicitly refreshed.

Option A is incorrect because the IAM role has the required permission (secretsmanager:GetSecretValue) and listing secrets is not necessary for retrieval. Option B is unlikely because the application would fail immediately if using the wrong secret ID, not only after rotation. Option C is about the rotation Lambda function, but the application's failure to connect after rotation does not indicate the Lambda function itself is failing; rotation may have succeeded but the application is not fetching the new version.

When an ALB is used with Lambda, the ALB invokes a specific Lambda function version or alias. If the deployment updates the Lambda function but the ALB target group alias is not updated atomically, or if connection draining keeps old connections active, some requests may still be routed to the old version. This can cause users to see the old application for several minutes.

Option A is wrong because Lambda versions are immutable, so gradual rollout is not related. Option B is wrong because Lambda@Edge is not used in this setup (the application runs behind an ALB, not CloudFront). Option C is wrong because CloudFront is not mentioned in the architecture—the traffic goes directly from ALB to Lambda.

CloudTrail can stream logs to CloudWatch Logs, where a metric filter can be configured to match the 'CreateAccessKey' API call. This metric filter triggers a CloudWatch Alarm, which publishes to an SNS topic for immediate notification, providing minimal latency. Option B is incorrect because S3 event notifications on the CloudTrail bucket notify on object creation, but CloudTrail delivers log files in batches (e.g., every 5 minutes), causing delays beyond the required minimal latency.

Option C is incorrect because while Amazon EventBridge can match CloudTrail events in near real-time, the question's intended solution (and the one that best fits 'minimal latency') is the metric filter + alarm pattern; however, EventBridge is a valid alternative, but the correct answer as per options is A. Option D is incorrect because polling the CloudTrail API every minute is inefficient, introduces latency, and does not provide real-time alerting.

503 errors from an ALB typically indicate that the target group has no healthy instances, or all instances are marked unhealthy. However, the question says instances are healthy according to health checks, so the issue might be that the ALB itself is at capacity (e.g., surge queue full). The most common cause when health checks are passing but 503s persist is that the ALB's connection surge queue is full, often due to too many connections or slow targets.

Option A is wrong because an ALB with no listeners would return 502 or 504, not 503. Option B is wrong because security group rules usually cause timeouts, not 503. Option C is wrong because 503 is not a typical throttling response; throttling returns 429.

Attaching a deny-all policy (e.g., AWSDenyAll) to the IAM user immediately revokes all permissions, including existing sessions, without risk of breaking dependencies. Deleting the user (B) may fail if the user is referenced by resources or logs, and it does not block existing sessions immediately. Disabling signing certificates (C) only affects programmatic access via CLI/SDK, leaving console sessions active.

Rotating access keys (D) invalidates old keys but does not affect existing sessions that already have credentials; sessions remain active until they expire. Therefore, the first action should be to apply a deny-all policy to instantly block all actions.

Options B and E are correct. Option B: Sending logs to Amazon S3 and using Athena for ad-hoc queries allows centralized log storage and analysis across all tiers (ALB, EC2, RDS). Option E: Deploying the unified CloudWatch agent on EC2 instances collects system and application logs, sending them to CloudWatch Logs for centralized monitoring.

Option A is wrong because CloudTrail only records API calls, not application logs. Option C is wrong because AWS Config monitors resource configuration changes, not operational logs. Option D is wrong because VPC Flow Logs capture only network traffic metadata, not application logs.

Using Fn::ImportValue to import exported outputs from the VPC stack ensures that the application stack always gets the latest security group ID. When the VPC stack is updated, it exports the new security group ID, and the application stack automatically references the updated value during its next update. Option B (Fn::GetAtt) is incorrect because it can only reference resources within the same stack or directly from nested stacks (if the master template uses Fn::GetAtt to access outputs of nested stacks), but in this scenario, the stacks are separate nested stacks managed by the master template, and cross-stack references are best handled via exports/imports.

Option C (hardcoding) is error-prone and not scalable. Option D is incorrect because CloudFormation does not automatically update nested stacks; the master template must be updated to trigger updates to dependent stacks, and using exports/imports ensures proper dependency resolution.

AWS Organizations with IAM Identity Center (AWS SSO) enables centralized user management and single sign-on across multiple AWS accounts, eliminating the need to manage individual IAM users in each account. Option B is incorrect because creating the same IAM users in each account leads to duplication and inconsistent permissions. Option C is incorrect because cross-account roles still require local IAM users or federated identities to assume those roles, and do not provide centralized user management.

Option D is incorrect because IAM federation with an external IdP centralizes authentication but does not inherently manage users across accounts unless combined with AWS Organizations and IAM Identity Center.

Switching to a load-balanced, auto-scaled environment with a minimum of 2 instances across 2 Availability Zones improves availability and resilience by distributing traffic and providing failover capacity. Option D is correct because enabling Multi-AZ for RDS provides a standby replica in a different Availability Zone, ensuring automatic failover and high availability for the database. Option E is correct because Amazon RDS Proxy manages database connections efficiently, reducing connection overhead and improving scalability during traffic spikes.

Option A (ElastiCache) is an additional cost that may not be necessary if caching is not a primary concern; the focus should be on core resilience first. Option B (dedicated instances) adds unnecessary cost and does not directly address high availability or resilience.

Changing the Principal to a specific AWS account ID ensures that only that account's IAM users/roles can access the bucket, preventing public access. Option A is incorrect because AWS Organizations does not directly block public access at the bucket level; it can set service control policies but not a bucket policy. Option C is incorrect because using Principal "*" with a condition for aws:SourceIp still allows any user with that IP (including unauthenticated) to access, and it does not restrict to a specific AWS account.

Option D is incorrect because setting BlockPublicAccess to true would block all public access, including the intended access from the specific account, which is not the goal.

CloudTrail logs management events like ConsoleLogin, and a CloudWatch Events rule can match that event and trigger an SNS notification for alerting. Option E is correct because CloudTrail must be enabled to log management events (which is the default, but must be ensured). Option B is wrong because AWS Config rules evaluate resource configurations, not API calls like ConsoleLogin.

Option C is wrong because S3 event notifications are for object creation in S3, not for CloudTrail log delivery events. Option D is wrong because CloudWatch Logs Insights is a query tool for analyzing logs, not for real-time alerting; alerting requires CloudWatch Events or metric filters with alarms.

(EC2's StatusCheckFailed metric) is correct because it directly indicates whether an EC2 instance is healthy (e.g., hardware or OS issues). Option D (ALB's HealthyHostCount metric) is correct because it shows the number of registered targets that are considered healthy. Option E (RDS's DatabaseConnections metric) is correct because it can indicate if the database is overwhelmed or unavailable (e.g., reaching max connections).

Option A (RDS's ReadLatency) is incorrect because it measures performance, not health directly; a database can have high read latency but still be operational. Option B (ALB's RequestCount metric) is incorrect because it measures traffic volume, not the health of targets.

The most secure because adding a Deny statement for ec2:TerminateInstances with a condition for the user's ARN explicitly blocks the termination action, regardless of any other policies that might allow it. Option A is wrong because an SCP affects the entire account, not just the user, and may be too broad. Option B is wrong because simply modifying the policy to include ec2:StopInstances and remove ec2:TerminateInstances does not prevent termination if the user has other policies that grant ec2:TerminateInstances.

Option D is wrong because attaching a separate Deny policy is effective but less direct and more complex than adding a Deny in the same policy.

CodeBuild needs 'kms:Decrypt' permission to decrypt the artifact encrypted with AWS KMS. The error 'Access Denied' when downloading the artifact from S3 indicates that the CodeBuild service role can access the S3 bucket but cannot decrypt the KMS-encrypted object. Option A is incorrect because bucket versioning is not required for CodeBuild to retrieve artifacts; versioning is optional.

Option C is incorrect because the pipeline service role does not interact directly with the artifact download; CodeBuild uses its own role. Option D is incorrect because using the same bucket for pipeline artifacts and source artifacts is allowed and does not cause access denied errors.

AWS X-Ray provides end-to-end tracing for requests through API Gateway and Lambda, capturing error details and metadata for individual requests. This allows the team to identify specific failing requests and understand error causes. Option A is wrong because CloudWatch Logs Insights can query logs, but it lacks automated tracing and correlation for distributed requests, making it less efficient.

Option B is wrong because VPC Flow Logs capture network traffic metadata, not application-level errors. Option D is wrong because CloudTrail logs API calls at the AWS account level, not application request details.

Options C and E are correct. When a Fargate task fails with 'CannotPullContainerError: API error (500)', it typically indicates an issue with pulling the container image from Amazon ECR. The task execution IAM role (E) must have the necessary permissions (ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, ecr:BatchCheckLayerAvailability) to pull images from ECR.

Additionally, if the image resides in a private ECR repository, the repository policy (C) must allow the task execution role to perform those actions. Option A is wrong because Fargate does not support attaching EBS volumes; it stores image layers ephemerally. Option B is incorrect because the ECS service role is used for load balancer integration, not for pulling images.

Option D is incorrect because increasing task memory does not fix image pull errors; memory affects running tasks, not the pull process.

CloudTrail can deliver logs to CloudWatch Logs in near real-time. A CloudWatch Events (now Amazon EventBridge) rule can then match API calls from the compromised user and trigger a Lambda function to send an SNS notification. Option A is incorrect because AWS Config rules check configuration compliance, not real-time API calls.

Option B is incorrect because S3 event notifications are not near-real-time and are typically for object-level events, not API call monitoring. Option D is incorrect because CloudWatch Logs Insights is for querying historical logs and requires manual intervention; it does not provide near-real-time notifications.