AWS Certified DevOps Engineer Professional DOP-C02 (DOP-C02) — Questions 76–150

AWS CodeDeploy with ECS blue/green deployment is the native AWS service that performs canary traffic shifting for an ECS service. It creates a replacement task set from a new task definition, shifts traffic through load balancer target group weights (for example, 10 percent initially), waits a specified interval, and then shifts the remaining traffic after validation. It also supports lifecycle hooks, CloudWatch alarm rollback, and automatic cleanup of the old task set, making it the complete answer for a canary deployment.

Run Command allows you to execute an SSM Document once on a target instance or fleet, on demand. It does not provide a scheduling feature or persistent association, so after the script finishes, there is no mechanism to automatically re-run it to handle future drift or new missing patches. While you could use EventBridge or other schedulers to invoke Run Command, State Manager natively supports recurring associations and compliance tracking, making Run Command insufficient for ongoing, monitored remediation.

Swapping environment URLs is the canonical blue/green deployment mechanism in Elastic Beanstalk. You first provision a second environment (the 'green' one) with your new version, verify it, and then use 'Swap environment URLs' in the console or the SwapEnvironmentCNAMEs API to make the original environment's URL instantly point to the new environment. This switch is atomic at the DNS/CNAME level, providing zero downtime, and you can equally quickly swap back to the old environment to roll back. Unlike other deployment methods, this keeps two distinct environments with separate instance fleets and configurations, which is the essence of blue/green.

AWS KMS encryption for artifacts ensures that every source zip, build output, and deployment package stored in CodePipeline’s artifact bucket is encrypted with a customer-managed key using SSE-KMS (envelope encryption). This gives you granular control over who can decrypt artifacts via kms:Decrypt permissions on the key, and it provides a tamper-evident audit trail of key usage through AWS CloudTrail. Unlike default AWS-managed S3 encryption, a customer-managed KMS key lets you enforce key rotation, define cross-account access rules, and revoke access immediately in response to a threat, which directly protects sensitive artifacts at rest and during transit.

Configuration files placed in the .ebextensions directory of your application source bundle are processed by Elastic Beanstalk during environment creation and every deployment, allowing you to define option settings, environment variables, packages, and custom resources declaratively. Because these files live in source control alongside your application code, every versioned build contains its exact configuration, so rolling back to a previous application version also restores the matching configuration automatically. This versioned, source-code-integrated approach is the recommended method for environment configuration.

This is correct because CodePipeline emits Amazon CloudWatch Events/EventBridge events on stage state changes, including a 'FAILED' state for a stage. A rule can filter for `detail-type: 'CodePipeline Stage Execution State Change'` with `detail.state: 'FAILED'` and trigger a Lambda function that invokes the `RetryStageExecution` API, passing the `pipelineExecutionId` and `stageName` from the event. This automates the same retry a user would otherwise click, and can include backoff logic or retry counts within the Lambda handler.

In-place deployments depend on the CodeDeploy agent polling the service on each instance; if it is absent or stopped, lifecycle events never execute, triggering the too-many-instances-failed error. Verifying the agent on every Amazon Linux 2 instance is therefore the first diagnostic step.

AWS CloudTrail records every API call made against the AWS account, including ECS, ECR, and other service actions, which is essential for auditing who did what and when. Amazon ECS logs, collected via the awslogs driver, capture container stdout/stderr for operational auditing and forensic analysis. Together they provide the necessary audit trail to verify compliance and detect unauthorized access or changes, directly addressing the requirement to capture all API calls and container logs.

An EC2 instance in a private subnet has no route to the public internet unless a NAT device or VPC endpoint is provisioned. Since no VPC endpoint for S3 is listed as existing, traffic from the instance to S3 cannot traverse the AWS backbone via the private subnet. A gateway endpoint or interface endpoint for S3 is required to establish private connectivity without leaving the AWS network, making the absent endpoint the root cause of the failure.

DynamoDB natively publishes ConsumedReadCapacityUnits and ProvisionedReadCapacityUnits to CloudWatch at a one-minute granularity. Monitoring these metrics directly gives you a continuous view of how much read capacity is being used relative to what the table has provisioned. This is the foundational data source for any read-capacity alarm or scaling policy, and it lets you detect capacity pressure before throttling begins.

The Average statistic applied to CPUUtilization with the AutoScalingGroupName dimension gives the mean CPU percentage across all instances in the group, which is exactly what the dashboard needs to assess overall load. CloudWatch computes this by taking the CPUUtilization data points from each instance and calculating the arithmetic mean over the selected period. This is the standard and CloudFormation-idiomatic approach for monitoring an Auto Scaling group's aggregate CPU usage, and it directly answers the requirement without mixing units or extrapolating to a nonsensical total.

RDS Blue/Green Deployments let you provision a staging 'green' environment that stays synchronized with the production 'blue' environment via logical replication, allowing you to change the DB instance class in the green environment with zero impact on production. After validation, you perform a switchover that flips the endpoint with minimal downtime and no data loss. Then you update the CloudFormation stack's DBInstanceClass property to match the new instance class, ensuring your infrastructure-as-code template reflects the actual state and preventing drift.

AWS CodeDeploy is the correct service for deploying the new task definition to Amazon ECS. It uses a blue/green deployment strategy when configured with the ECS deployment controller, allowing traffic to be shifted gradually from the old task set to the new one while monitoring health and supporting automatic rollbacks. CodeDeploy accepts a versioned task definition and an AppSpec file, making it the service that actually performs the deployment to ECS.

Placing an explicit Deny on ec2:TerminateInstances with a condition key like aws:PrincipalArn set to the user's ARN directly and narrowly blocks only that principal from terminating instances. This Deny overrides any Allow for the action, regardless of other policies, while leaving the user's ability to stop instances intact and preserving permissions for all other IAM principals.

This combination directly addresses a demand spike: API Gateway throttling imposes a maximum request rate per client or across the API, preventing a flood from reaching Lambda. Reserved concurrency allocates a guaranteed number of Lambda executions, insulating the function from account-level throttling and ensuring the spikes are absorbed within the reserved ceiling. DynamoDB auto scaling adjusts provisioned read/write capacity based on live utilization, so the database keeps pace without manual intervention.

Setting up a pull request approval rule in CodeCommit requires at least two approvals from IAM principals (other than the commit author) before the pull request can be merged. This is a native CodeCommit feature that enforces the two-person review rule at the source, allowing the pipeline to deploy only code that has passed the mandated review process. The approval rule can also be associated with the repository's target branch (e.g., production) and automatically applies to all PRs targeting that branch, making it the correct control to meet the requirement.

Configuring the build project to use a custom VPC is a best practice because it allows CodeBuild to securely access resources that are not publicly reachable, such as private Amazon RDS databases, internal load balancers, or AWS services via VPC endpoints. Without a VPC configuration, CodeBuild runs in AWS-managed compute and cannot resolve or connect to private IP addresses, forcing you to either expose those resources to the internet or use a NAT gateway with complex routing. By placing the build into a private subnet with proper security group rules, you can control both inbound and outbound traffic, ensuring the build only communicates with approved internal services and does not depend on the public internet.

Deleting or disabling root user access keys removes long-lived credentials that cannot be scoped by IAM policies and are frequently exposed through code commits or misconfigured tooling. Since the root user bypasses permission boundaries entirely, eliminating its programmatic keys satisfies the stem's requirement to secure the account's most privileged identity.

An organization trail in AWS CloudTrail is created once in the management account of AWS Organizations and automatically delivers management events from every member account to a single central S3 bucket, with optional CloudWatch Logs delivery for real-time monitoring. This gives a centralized, near-complete audit record of who made API calls, the service called, source IP, and timestamp across all accounts, which directly satisfies both central management and audit requirements. Because the trail is organization-scoped, it captures activity for existing and future accounts, making it the native AWS solution for cross-account audit logging.

AWS X-Ray active tracing on both API Gateway and the Lambda functions provides end-to-end request tracing that captures every segment and subsegment — including Lambda invocation details, function execution time, HTTP status codes, exceptions, and downstream AWS service calls — allowing you to pinpoint the exact component that caused the error. When active tracing is enabled, API Gateway sends trace headers to Lambda, and Lambda automatically records the function's execution, with error details visible in the X-Ray console under the service map and trace list. This lets you filter traces by HTTP 5xx status or Lambda ERROR, drill into the affected trace to see the precise failing segment, and inspect the exception stack trace or error message, directly answering where and why the API request failed. X-Ray is purpose-built for distributed serverless applications, making it the most efficient and comprehensive option for this diagnostic task.

Exporting application logs from CloudWatch Logs to Amazon S3 and applying a lifecycle policy that transitions objects to S3 Glacier Deep Archive is the most cost-efficient way to meet a 5-year retention requirement. CloudWatch Logs storage costs roughly $0.03 per GB-month, while Glacier Deep Archive costs about $0.00099 per GB-month — a savings of nearly 97%. This makes sense for rarely accessed logs where the 12-hour retrieval time of Glacier Deep Archive is acceptable for compliance audits.

Scheduled scaling pre-provisions instances at fixed times, aligning capacity with known upcoming demand, while a step scaling policy reacts to actual CPU utilization through CloudWatch alarms with defined adjustment steps (e.g., add 2 instances when CPU exceeds 80%, add 1 when it exceeds 70%). This combination ensures both proactive readiness for predictable traffic spikes and rapid reactive response to any deviation, giving the highest resilience for mixed traffic patterns.

The correct interpretation is that the system status check has failed, which indicates an AWS infrastructure-level problem with the physical host running the instance. This includes issues such as a failing disk, network connectivity loss, or hardware component degradation. Even though the instance is running and its instance status check may pass, the impaired system status means the underlying hardware is compromised and AWS may need to repair or replace the host, often requiring a stop/start or recovery action.

A permissions boundary on CrossAccountDeployRole acts as an additional filter on the role's effective permissions, and if it does not explicitly allow CodeDeploy actions, those actions are denied even when the role's permissions policy grants them. Because the effective permission is the intersection of the identity-based policy and the boundary, the boundary must include all required codedeploy:* or specific actions. Adding or updating the boundary to allow CodeDeploy actions is the correct way to restore authorization in this cross-account deployment.

Amazon ECR uses both identity-based policies (attached to the principal, typically the task execution role) and resource-based policies (attached to the repository) to control access. If the repository policy does not explicitly grant the task execution role permission to perform actions like ecr:BatchGetImage and ecr:GetDownloadUrlForLayer, the pull will be denied even if the role's IAM policy allows those actions. The default repository policy is restrictive, and an overly narrow or misconfigured repository policy will cause a 'CannotPullContainerError' during task startup. Therefore, verifying that the ECR repository policy includes an Allow statement for the task execution role is a critical step.

In the CodeBuild project configuration (or in the buildspec's timeout-in-minutes field), you can set a build timeout that applies specifically to the build used by the Test stage. When the build exceeds the configured timeout, CodeBuild automatically stops the build and the pipeline transitions to Failed, giving a proactive, stage-scoped limit without affecting the Deploy stage. This is the recommended way to prevent a test job from hanging indefinitely because the timeout is enforced by CodeBuild's execution manager.

This is the correct pattern: it explicitly denies any request where aws:SecureTransport equals false, meaning only HTTPS connections are permitted. An explicit deny overrides all other allow outcomes, so this robustly enforces TLS regardless of any other policies. The condition uses Bool, which is proper for boolean keys like aws:SecureTransport.

CloudWatch Logs metric filters evaluate log events in real time against a filter pattern and can emit a custom metric that increments for every matching event, here 'DuplicateTransaction'. This avoids changing the Lambda function or introducing additional services, and it leverages the transaction logs already being written to CloudWatch. A CloudWatch alarm can then monitor that metric over a 5-minute period and trigger when the count exceeds 10, providing an accurate and low-cost detection mechanism.

Using the AWS SDK inside the application to retrieve the secret from Secrets Manager is the correct pattern because the secret is fetched at runtime, encrypted in transit, and never written to user data, environment variables, or disk. The EC2 instance profile's IAM role gives the SDK temporary, automatically rotated credentials, so no hard-coded access keys or CLI scripts are required. This approach leverages Secrets Manager's built-in rotation, CloudTrail auditing, and fine-grained IAM policies that can limit which secrets a given instance role can read, and it lets the SDK cache the secret to minimize latency while still respecting rotation.

CloudWatch cross-account observability supports linking source accounts and Regions to a monitoring account, letting users query metrics, logs, and traces from one place while data stays in the source accounts. IAM roles control who can view the shared data, satisfying governance without copying data to a third party.

CloudFormation modules encapsulate a group of resources—such as a VPC with subnets, route tables, and gateways—so they can be referenced as a single reusable component in multiple stacks. Modules support parameters, outputs, and semantic versions, enabling centralized management and consistent configuration across accounts and regions without duplicating resource definitions. When a module is included in a stack, its resources become part of that stack's resource graph, so you can access their outputs directly in the same template, simplifying stack-level operations like changes and rollbacks.

The managed rule restricted-ssh directly evaluates security group rules for inbound TCP port 22 and determines if any rule allows access from 0.0.0.0/0 or ::/0. When the rule finds an IPv4 or IPv6 inbound rule that permits SSH from all IP addresses, it marks the security group as noncompliant; this is exactly the condition a DevOps engineer would target to detect publicly exposed SSH.

This is the correct explanation. AWS IAM policy evaluation is based on a strict rule: an explicit deny from any applicable policy always overrides any allow, regardless of statement order or the number of allows. Even though the policy contains an Allow that includes `s3:DeleteObject` on the specified bucket and objects, the explicit Deny for the same action takes precedence, resulting in the user being denied. This is fundamental to AWS's default-deny model and is non-negotiable.

This is correct. After an RDS Multi-AZ failover, the RDS-managed DNS CNAME is updated to point to the new primary instance's underlying IP address. However, if the application's DNS resolver (or the application itself) has cached the old IP address from before the failover, it will continue to try to connect to the old primary instance until the cache expires (based on the DNS TTL, which is typically 30–60 seconds for RDS). A long TTL or a resolver that ignores TTL can keep the stale IP in effect, causing errors (e.g., 'Communications link failure') even though the new primary is healthy.

The CodePipeline console provides Approve and Reject buttons for any pending manual approval action to any IAM user or role with the codepipeline:ApproveStage permission. The approval is bound to the action and its configured IAM permissions, not to the specific person who originally triggered it, so another authorized user can approve the action and immediately unblock the current pipeline execution without any code or pipeline definition changes.

This is the correct near-real-time solution. By delivering CloudTrail events to CloudWatch Logs, events are streamed continuously rather than waiting for S3 log file delivery. A CloudWatch Events (EventBridge) rule can match the specific API call from CloudTrail—filtering on the IAM user, event name, or region—and invoke a Lambda function, which publishes an SNS notification. This end-to-end path operates in seconds, giving you immediate alerting on unauthorized API calls.

CodePipeline's manual approval action is a first-class gate that pauses execution between stages; a configured principal (often a manager or lead) must explicitly approve via console, CLI, or API before the pipeline proceeds to the CloudFormation deployment stage. This enforces separation of duties, because the engineer who initiated the pipeline cannot be the sole approver unless policies allow it. It works natively with the pipeline state machine and keeps an audit trail of who approved and when.

A bug in the new release that causes errors to accumulate over time fits the exhibit's steady upward slope perfectly. For example, a memory leak, unreleased file descriptor, or growing goroutine/thread count raises resource pressure with every additional request, so failure probability increases as a function of cumulative traffic. This pattern is distinct from an immediate fault because the defect is latent, and the error rate worsens as the application's internal state becomes progressively corrupted or exhausted.

The 'aws-sdk' package is a runtime dependency, and CodeBuild's npm install phase installs only the modules declared in package.json. If it is missing from the 'dependencies' section, npm will not fetch it, so your Node.js code cannot require it regardless of the environment. Adding it there ensures it is installed with the default dependency installation step, and pinning a version avoids unexpected updates.

AWS CodePipeline is the correct choice because it natively integrates with CodeCommit as a source action and automatically starts a pipeline execution on every push to the configured branch. It can then invoke test actions (e.g., CodeBuild or third-party test tools) in a defined stage, with options for parallel actions, approvals, and rollback—making it the standard CI/CD orchestrator for this use case.

AWS CodePipeline is a fully managed continuous delivery service that orchestrates the stages required to build, test, and deploy your application automatically. It includes a native CodeCommit source action that watches the repository for new commits and completes the deployment by invoking Elastic Beanstalk as a deployment provider, which creates and deploys a new application version to the environment. The service handles sequencing, failure handling, and manual approval gates without requiring custom glue code. Therefore, CodePipeline is the correct answer because it directly integrates the version control and deployment services in a single automated pipeline.

AWS X-Ray traces requests through Lambda and downstream services, exposing latency, errors and their causal path. This gives the engineer the distributed tracing needed to pinpoint the root cause of increased error rates, which CloudWatch logs alone would require manual correlation to achieve.

The health check grace period tells Auto Scaling how long to wait after an instance launches before it starts evaluating the instance's health status. If this value is set too high, an instance that is already failing health checks will continue running without being terminated because the elapsed time since launch has not yet exceeded the grace period. Extending the grace period can therefore leave unhealthy instances in service, which matches the described issue.

AWS Secrets Manager natively supports automatic rotation of secrets using Lambda functions. It provides built-in rotation templates for databases like Amazon RDS, and you can schedule rotation every 30 days. This requires minimal development effort because the rotation logic is managed by Secrets Manager. The Lambda functions can retrieve secrets directly from Secrets Manager, and rotation is transparent. This is the most efficient solution.

Enabling local caching in the CodeBuild project and specifying /root/.m2 as the custom cache location precisely tells CodeBuild to preserve and restore the Maven local repository onto the same build agent across runs. This way, already-downloaded JARs are reused and Maven won't fetch them again, dramatically reducing build time. This is the documented approach for caching Maven dependencies with CodeBuild.

AWS CloudTrail is the correct answer because it provides a complete audit history of API activity across AWS, including actions performed on S3 buckets such as CreateBucket, PutBucketPolicy, and DeleteBucket. For every management event, CloudTrail captures the IAM user or role, the source IP address, the request parameters, and the response returned, enabling you to answer exactly who did what and when. CloudTrail can also be configured to log data events for object-level S3 operations (GetObject, PutObject) for deeper forensic analysis.

AWS Systems Manager Parameter Store with the 'parameter-store' field in buildspec is correct because CodeBuild retrieves the SecureString value during build and injects it as an environment variable without ever displaying it in the build log. The value itself is encrypted with KMS and access is controlled by IAM, so this satisfies the requirement to keep secrets out of logs without additional steps.

Amazon CloudWatch Events (now Amazon EventBridge) natively captures CodeCommit API events, including a 'Reference Created' event when a branch or tag is created. You can configure a rule that matches the repository name and reference type 'branch', then target it to the CodePipeline pipeline for automatic execution. This is the recommended push-based integration because it is serverless, near-real-time, and does not require any external endpoint or polling.

Configuring an SNS topic in the stack's notification options is the native CloudFormation mechanism for sending stack lifecycle events (e.g., CREATE_COMPLETE, UPDATE_FAILED, DELETE_IN_PROGRESS) to a pub/sub channel. You simply provide the topic ARN (up to five) when you create or update the stack, and CloudFormation publishes every stack event to it without requiring any Lambda code, custom resources, or additional infrastructure. This is the simplest and most direct way to get notified about stack changes.

CodeBuild reports a client error when it cannot retrieve source artefacts, and the build log shows an S3 access failure. Either the bucket 'my-bucket' is absent or the service role lacks s3:GetObject permission, so the build fails before compilation begins.

Creating an IAM role in the source account with read access to the bucket, and allowing users in that account to assume the role, grants cross-account access by using the role as the principal identity. This approach leverages AWS STS trusts so the bucket policy can restrict the principal to the role's ARN, ensuring only users who assume that role can list and read objects. It avoids permanent cross-account credentials and gives you central control over who may assume the role.

CodePipeline does not automatically poll an Amazon S3 source bucket for new objects unless the bucket has event notifications enabled to emit s3:ObjectCreated:* events to the pipeline. Without an Amazon CloudWatch Events rule or an S3 event notification configured to invoke the pipeline on object writes, the pipeline will only run manually or when explicitly started from the console, CLI, or SDK. This is the standard prerequisite for automatic triggering from an S3 source, and its absence explains why the pipeline remains idle after an upload.

The `ContinueUpdateRollback` API is the designed recovery action when a CloudFormation stack is stuck in the `UPDATE_ROLLBACK_FAILED` state. By invoking it with the `ResourcesToSkip` parameter, you explicitly instruct CloudFormation to skip the specific resource that caused the rollback failure, allowing the stack to return to a stable `UPDATE_COMPLETE` state. This bypasses the problematic resource without requiring manual intervention. It is the recommended and least disruptive method to recover from a failed stack update.

Amazon CloudFront with an S3 bucket as origin is the intended AWS solution for low-latency global delivery of static content. CloudFront caches objects at hundreds of edge locations, so users receive data from the nearest edge POP rather than the origin, drastically reducing latency. The S3 bucket provides durable, cost-effective storage, and CloudFront minimizes origin requests via cache hits, reducing cost. This combination also improves resilience by absorbing traffic spikes at the edge and supports features like SSL, geo-restriction, and signed URLs.

CodePipeline can be configured to automatically start an execution when a push occurs to a branch (or tag) in a CodeCommit repository. The console sets up a CloudWatch Events rule that matches actions like reference creation or update, and the pipeline's source stage polls for that event; this is a built-in, first-class trigger mechanism for Git-based sources

In CodeBuild standard images, the runtime-versions section in the buildspec.yml is required to install and set up the desired runtime, such as Node.js. Without it, the image may not have Node.js pre-installed or may not be in the PATH. The error indicates that the node command is not found, which is resolved by specifying the runtime version.

An explicit Deny in the IAM policy overrides any Allow, and it is conditioned on the absence of SSE-KMS encryption headers. Because the request specifies no server-side encryption, the Deny matches and the upload is rejected.

This command is correct because it uses `aws cloudformation describe-stacks` to retrieve the stack's metadata, then JMESPath `Stacks[0].Outputs[?OutputKey=='BucketName'].OutputValue` filters the outputs array for the output whose `OutputKey` exactly equals `BucketName` and extracts its `OutputValue`. The `--output text` renders the result as plain text (the actual bucket name). This directly matches the exhibit, which shows the stack's outputs, and is the intended way to programmatically retrieve a CloudFormation output value.

Secrets Manager natively supports automatic rotation by invoking a configurable Lambda function that updates both the database credential and the secret value. Setting the rotation interval to 30 days on the secret ensures the database password is rotated without any manual intervention or custom infrastructure. The rotation Lambda must have permission to modify the database and call the UpdateSecret API, and the interval can be adjusted to meet compliance requirements.

AWS Systems Manager State Manager creates associations that define a desired configuration state using SSM documents, and it automatically applies that state on a schedule or when an instance is launched. When a configured resource drifts from the desired state, State Manager detects and remediates it during the next association execution, and it provides compliance status for every managed instance. It is the correct service for ongoing, agent-managed configuration enforcement and drift correction.

This is the correct cause because StackSets with self-managed permissions require the administrator account to assume an IAM execution role in each target account using the sts:AssumeRole API. The target account execution role must include a trust policy that explicitly grants the administrator account (or the StackSets administration role) permission to assume it. If that trust relationship is missing or misconfigured, the administrator account receives an AccessDenied response even though the role exists and the execution role's permissions policy may be correct. Therefore, verifying the role exists is not sufficient; you must verify its trust policy.

The query filters for events containing 'ERROR' and then performs stats count(*) by bin(5m), which aggregates the matching events into consecutive 5-minute time buckets. The results are ordered by bucket timestamp in descending order and limited to 20 rows, so the output is exactly the count of ERROR messages for each of the 20 most recent 5-minute intervals. The bin(5m) function and the LIMIT clause together determine the time span and number of rows returned.

AWS CodeBuild is a fully managed build service that can execute a custom build spec in a disposable compute environment. To create a custom Elastic Beanstalk platform, CodeBuild can run the Packer templates and platform hooks that produce the platform's AMI, making it the correct AWS service for the build itself. Its ephemeral environment, clean snapshots, and retryable builds make it well suited for repeatable platform builds.

The CloudWatch agent is required to emit in-guest memory metrics. The default EC2 monitoring collects only hypervisor-level metrics such as CPU utilization, disk I/O, and network throughput; memory utilization is not visible from the hypervisor and must be reported by the agent inside the OS. If the agent is not installed or its configuration does not define memory as a collected metric, the MemoryUtilization metric will be absent, causing any alarm relying on it to remain in INSUFFICIENT_DATA and never trigger.

AWS CodeDeploy is the native AWS service for performing canary deployments on Amazon ECS. It shifts a specified percentage of production traffic to the new task set (e.g., 10% for 5 minutes) while the old version continues to serve the rest, then gradually increases the new version's traffic until 100%. CodeDeploy orchestrates the entire traffic-shifting process using the AppSpec file, target groups, and optional LifecycleEventHooks such as BeforeAllowTraffic and AfterAllowTraffic, making it the correct choice for a microservices CI/CD pipeline requiring canary releases.

Configuring target tracking scaling policies for the ECS service lets AWS automatically scale the number of tasks in response to actual load, using CloudWatch metrics such as CPUUtilization or MemoryUtilization. The policy works by maintaining a specified target value (for example, 70% CPU) and triggers scale-out or scale-in based on aggregated utilization across the service. This is the recommended pattern for handling spikes in containerized workloads on ECS, as it provides reactive, horizontal scaling without manual intervention.

Managed node groups perform health checks and can automatically replace nodes that fail them, which addresses unhealthy nodes without manual action. Pairing that with CloudWatch alarms on node condition metrics provides the alerting path, satisfying both automatic replacement and notification requirements for future incidents.

Creating a metric filter on the log group that extracts ERROR count is the first required action. A metric filter defines a pattern, such as the literal string 'ERROR', and evaluates each incoming log event against that pattern; every match increments a specified CloudWatch metric value. The filter can also output a custom value and unit, producing a metric that can be used for alarms and dashboards. This is the native CloudWatch Logs mechanism to translate unstructured log text into a numerical time-series metric.

Automatic triggering in CodePipeline with a GitHub source action depends on an active webhook that GitHub uses to notify the CodePipeline API whenever commits are pushed to the repository. If that webhook has been deleted, or if its payload URL or secret token no longer matches what CodePipeline expects, GitHub's push events will never reach CodePipeline and no new pipeline execution will be started. This is the classic cause of 'commits pushed but pipeline doesn't run,' and it is precisely why this is the correct answer.

Performance Insights for Amazon RDS is the direct diagnostic tool for database performance. It visualizes database load by wait states, SQL statements, and hosts, allowing you to quickly identify slow queries, lock waits, or I/O bottlenecks that are driving the ALB backend latency. This matches the scenario where application instances are healthy but the database is the constraint, making it the correct next step for root-cause analysis.

This is the correct explanation because the ALB health check probes the configured endpoint and expects a successful status code, and a 503 returned by that endpoint indicates the application's dependency (for example, a database or downstream API) is unavailable. When the health check receives 503 for all tasks, the ALB marks the targets unhealthy and stops routing traffic, ultimately returning HTTP 503 to clients. The symptom therefore matches the health check failure, not an application exception or scaling issue.

An SCP is a preventive, organization-wide control enforced by AWS Organizations before the action is authorized; it cannot be overridden by any IAM policy within the account. To deny non-compliant creation, you attach to the root/OU a policy that denies s3:CreateBucket with a StringNotEquals condition on s3:x-amz-server-side-encryption and a StringNotEquals condition on s3:x-amz-public-access-block, so only requests meeting both criteria succeed. This approach automatically covers every existing and future account and bucket without custom code or manual catch-up.

Setting JAVA_HOME in the buildspec's env section ensures the variable is exported into every build phase's shell before commands run. This resolves the 'invalid JAVA_HOME' error because Maven or Gradle translates this variable into the absolute path of the JDK installation, which is needed for compilation. It's the canonical fix and works regardless of which base image CodeBuild uses.

An escalation plan is a first-class component of an AWS Systems Manager Incident Manager response plan. You define a total duration (e.g., 10 minutes) and add engagement targets such as individual contacts, chat channels, or a full on-call schedule; if the primary responder does not acknowledge the incident within that window, Incident Manager automatically pages the secondary/next-level contact using the configured contact channels (SMS, voice, mobile push). This is the intended solution because it is fully managed, idempotent, and does not require any custom code or additional AWS services. Escalation plans also support multiple levels, and you can set the engagement duration per target to progressively move up the chain until someone acknowledges.

Creating a snapshot of the attached EBS volumes is a core forensic preservation technique because it captures the full disk state—including deleted file remnants, user-space artifacts, logs, and malware binaries—without stopping the instance. Unlike a live filesystem copy, an EBS snapshot is crash-consistent (or application-consistent with pre-freeze), providing a point-in-time image that can be analyzed on a separate forensic instance without risking further alteration of the original evidence. This must be done before any stop/termination, since those actions can change or destroy disk data.