AWS Certified DevOps Engineer Professional DOP-C02 (DOP-C02) — Questions 526–600

By creating an organization trail in the management account (using AWS Organizations), CloudTrail automatically logs API activity for all member accounts, including the management account itself, without needing to configure trails in each account. This centralizes governance and ensures the requirement of logging all API calls across the entire AWS environment is met, as organization trails deliver log files for every account to a single S3 bucket.

ALB security policies terminate TLS at the load balancer and enforce the minimum protocol version and cipher suite list, satisfying the TLS 1.2 requirement without modifying each EC2 instance. This centralises enforcement at the single ingress point.

The AWS X-Ray trace map is the correct tool because it visualizes each service as a node and the connections between them as edges, with latency metrics for each edge. This directly reveals whether the identified slowness stems from network communication between services (for example, high I/O wait or retries) rather than from code execution inside a single service, allowing the DevOps team to pinpoint the exact segment of the request path that is underperforming.

A target tracking scaling policy with a target value of 70% average CPU utilization proactively adds instances before utilization reaches 80% and continuously adjusts to maintain the target, providing fast response to spikes without over-provisioning.

Launching EC2 instances in at least two Availability Zones is the foundational principle for highly available web server fleets. Availability Zones are physically separate data centers with independent power, cooling, and networking, so a failure in one AZ does not affect the other. Combined with a load balancer that spans those same AZs, traffic automatically continues to be served by healthy instances if one AZ loses capacity. This design eliminates the single-AZ dependency and is a core requirement for fault-tolerant compute tiers.

Run Command is the correct choice because it provides secure, on-demand remote execution of scripts and commands across EC2 instances, targeting tagged instances through AWS resource groups or tag key-value pairs. It uses SSM documents to define the script and the SSM Agent to execute it, with results streamed back to the console or S3. This directly matches the requirement to run a script on a fleet selected by tags.

The IAM user must have the cloudwatch:GetMetricStatistics permission to call the CloudWatch API and retrieve metric statistics. If the IAM policy attached to the user does not explicitly allow this action, the request is denied and no CPUUtilization data points are returned. Since the namespace, metric name, dimensions, and period are all valid, the most plausible reason for the lack of data is that the IAM permission is missing.

Elastic Beanstalk saved configurations capture environment option settings into a JSON or YAML template that can be downloaded and committed to version control. These templates can be applied to new or existing environments with a direct API/CLI call, enabling repeatable deployment and rollback to a known good state. Because the configuration file is just a file in your repository, you get code review, history, and drift detection naturally.

Security groups are among the resource types for which CloudFormation compares the live configuration—such as ingress rules, egress rules, and group name/description—against the template. If someone adds or removes a rule out-of-band, drift detection marks the security group as MODIFIED. This makes drift detection useful for catching unauthorized network-level changes to your VPC infrastructure.

An Application Load Balancer with sticky sessions is the correct solution because it operates at Layer 7 and can inspect HTTP/HTTPS traffic. ALB uses either the AWSALB cookie with a configurable duration or an application-controlled cookie to send all requests from the same client session to the same EC2 instance. This preserves in-memory session state, which is exactly what a stateful application requires.

The AWS CloudTrail LookupEvents API is the correct method because it directly queries CloudTrail's event history, which records all control plane API calls such as DeleteBucket. You can use the LookupAttributes parameter with AttributeKey=EventName and AttributeValue=DeleteBucket, filtering by time range if needed. This returns the full event record, including the IAM user or role, source IP, and timestamp, for any deletion within the last 90 days. It is the native, low-latency mechanism for exactly this forensic search.

Git LFS solves the binary bloat problem by replacing each large file in the repository with a tiny text pointer, while the actual file content is stored in a separate, scalable LFS store—in this case, an S3 bucket you configure. During checkout, the Git LFS client retrieves the real file from S3 transparently, so developers see the full content without the repository itself growing. This keeps CodeCommit clones fast, avoids the 10 GB limit, and integrates smoothly with existing Git branching and merging workflows.

AWS X-Ray traces requests end-to-end from API Gateway to Lambda and downstream services like DynamoDB, capturing segments, sub-segments, and annotations that reveal where latency is consumed and which component is returning errors. By enabling X-Ray on API Gateway and Lambda, the DevOps engineer can inspect trace timelines, service maps, and error rates per operation to pinpoint performance bottlenecks and failed invocations. This provides correlated, request-level observability that CloudWatch aggregate metrics alone cannot offer, making it a correct component of a comprehensive monitoring solution.

This is the S3 CLI parameter that explicitly requests server-side encryption with AWS KMS (SSE-KMS). Setting the value to `aws:kms` instructs S3 to use a customer master key (CMK) for encrypting the object at rest. When combined with `--kms-key-id`, it allows specifying a particular KMS key, but the presence of `--server-side-encryption aws:kms` alone satisfies the encryption requirement.

Secrets Manager securely stores and rotates credentials. By granting the ECS task role permission to retrieve the secret, the application can fetch credentials at runtime without hardcoding them. This aligns with least privilege and eliminates static credentials in code or environment variables.

SCPs centrally govern the maximum available permissions for every IAM principal in all accounts within an AWS Organizations hierarchy. They act as guardrails that filter which actions a principal or root user can perform, regardless of any IAM policies that grant broader access, enabling cross-account policy enforcement.

The actual flaw is that the instance resource lacks a SecurityGroupIds or SecurityGroups property to reference the security group. DependsOn only ensures the security group is created first; it does not attach the group to the instance. Without an explicit reference in the instance properties, CloudFormation has no way to associate the security group, even though it exists and is available.

This configuration uses the ALB's per-target request count as a scaling metric, so Auto Scaling continuously adjusts the EC2 fleet to keep that value near the chosen target. The ALB target group integration ensures newly launched instances are immediately registered to receive traffic, and the policy can scale both out and in based on real observed load. It is designed for variable workloads like critical web apps and responds faster and more accurately than scheduled or simple scaling policies.

The deployment group's Amazon EC2 tag group is configured with key 'Environment' and value 'Production', and CodeDeploy identifies target instances solely by this tag filter. If no running instance carries both the exact key and value, CodeDeploy cannot discover any targets and the deployment fails with a 'No instances found' error before any other step executes. Therefore, the missing tag is the root cause of the failure.

In CodeBuild, Docker commands require access to a Docker daemon, but the default build environment runs as an unprivileged container without the necessary kernel capabilities (e.g., CAP_SYS_ADMIN) to start or use Docker. When privileged mode is not enabled, any Docker command such as `docker build` or `docker push` fails with permission errors or 'Cannot connect to the Docker daemon' because the daemon cannot run inside the container. Setting `PRIVILEGED_MODE=true` in the CodeBuild project environment (or via `PrivilegedMode: true` in infrastructure as code) is mandatory for Docker-based builds that need to build and push images to Amazon ECR.

CodeCommit triggers invoke a Lambda function asynchronously when a reference is updated, and that Lambda can inspect the pushed commit objects using the Git command line or the CodeCommit API to verify GPG signatures. Although the trigger fires after the push is initially accepted, the Lambda can delete or restore the branch reference to its previous commit via the UpdateRef API, effectively rejecting the unsigned commit and preserving repository integrity. This is the practical way to enforce signed commits because CodeCommit itself has no native, built-in signed-commit enforcement.

By configuring the Auto Scaling group to span multiple Availability Zones and enabling cross-zone load balancing on the ALB, the application can survive an entire AZ failure. If one AZ becomes unavailable, the ALB routes traffic only to the remaining healthy targets, while the ASG automatically launches replacement instances in the other AZs to maintain capacity. Cross-zone load balancing ensures that traffic is distributed evenly across all instances, even when one AZ has fewer instances. This design provides both redundancy and optimal utilization.

Auto Scaling is configured to use EC2 status checks for health, so it will detect the instance's failed status check and automatically terminate it, launching a new instance with the same launch configuration to maintain desired capacity. Waiting is the correct action because the replacement process is fully automated and requires no manual intervention. The new instance will be created once the unhealthy instance is marked as unhealthy, typically within a few minutes.

Reserved concurrency sets a hard upper limit on the number of simultaneous executions for a specific function and, more importantly, guarantees that this amount of capacity is reserved exclusively for that function from the account's total concurrency pool. This prevents other functions from exhausting the shared pool and ensures the critical function can always handle its peak load without being throttled. It also makes the function's behavior predictable during traffic spikes, because the reserved capacity is always available for that function's invocations.

Enabling ALB access logs and storing them in Amazon S3 records every request with fields such as elb_status_code, target_status_code, request_processing_time, target_processing_time, and response_processing_time, as well as the exact request path and user agent. By querying these logs, you can identify the specific HTTP response codes (including the 503s), observe patterns by path or client, and determine whether the timeouts occur in the load balancer or at the target. This is the definitive diagnostic step to isolate the cause of intermittent 503s.

A batch build lets you define multiple builds that CodeBuild schedules on separate compute environments, running them concurrently up to the configured max batch size or parallelization limit. Each build in the batch can have its own buildspec override, environment variables, or input source, making it ideal for sharding unit tests across workers. This is the intended AWS mechanism for executing independent unit tests in parallel.

Elastic Beanstalk automatically processes the .ebextensions directory inside your source bundle, passing any .config files (YAML/JSON) to the CreateStack operation as AWS::CloudFormation::Init metadata. The packages key lets you specify packages like yum, rpm, or gem, while the commands and container_commands keys execute shell commands at specific points in the deployment lifecycle. Because these run on every instance before the application is deployed, they give you a supported, idempotent way to install dependencies and tweak configuration without managing your own AMI. This is the most portable and preferred method for most customizations.

CodePipeline executes deploy actions by assuming a dedicated IAM service role, and that role must contain an identity-based policy granting the required API permissions (e.g., codedeploy:CreateDeployment, ecs:UpdateService, or cloudformation:CreateStack) on the target resource. If a required permission is missing or explicitly denied, the deploy stage fails with an AccessDenied error even though every other pipeline configuration is correct. You should review the pipeline execution details to identify the specific denied action, then attach an appropriate managed or inline policy to the service role.

The CodeBuild service role is an IAM role that grants the build project permission to call AWS APIs. When CodeBuild uploads build artifacts to an S3 bucket, it must have the s3:PutObject action allowed on that artifact bucket. The failure occurs at the upload step because the role currently lacks write access; adding s3:PutObject to the role's policy for the artifact bucket's ARN resolves the AccessDenied error.

Terraform's `force-unlock` command is the sanctioned recovery mechanism for a stale lock. Run `terraform force-unlock <LOCK_ID>` from the CLI using the lock ID printed in the error message (or found in the DynamoDB `LockID` item); this removes the lock item via a properly logged API call. It is safe only when you confirm no other `terraform` process is actively applying or planning against that state, because it overrides mutual exclusion.

High-resolution metrics allow one-second granularity, and combining a short evaluation period with M-out-of-N datapoints to alarm makes the alarm evaluate recent error data quickly. This directly addresses the delay and sparsity of custom metrics during rapid spikes, improving alarm responsiveness.

Amazon CloudWatch Alarms are the native mechanism for EC2 AutoRecovery. By configuring an alarm on the System Status Check metric (StatusCheckFailed_System) with the 'recover' action, you let EC2 automatically restart the instance on new hardware while preserving its instance ID, private IP, Elastic IP, and instance store data. This is the direct, built-in solution that requires no custom code or additional orchestration.

The policy is missing s3:ListBucket permission on the bucket. CodePipeline requires the ability to list the contents of the S3 artifact bucket in order to enumerate source objects, determine which artifacts are present, and trigger the pipeline correctly. s3:ListBucket is a bucket-level action, so its Resource must be the bucket ARN (arn:aws:s3:::bucket-name), not the object ARN. Without this permission, the pipeline will fail during the source stage with an access denied error, even though GetObject is present, because the service cannot discover which objects to fetch.

Storing an ordinary TypeScript CDK project in Git and using the `cdk pipelines` construct creates a self-mutating CI/CD pipeline that automatically builds, synthesizes, and deploys the app to one or more AWS environments. This approach lets you version the CDK source, review pull requests, run unit tests, and retain the full CloudFormation deployment model underneath. It is the recommended production pattern because pipeline updates are also managed through the same CDK code, giving you repeatable and auditable infrastructure delivery.

Deleting the pod with `kubectl delete pod <name>` immediately sends a termination signal (SIGTERM) to the container, and after the grace period, a SIGKILL, removing the pod from the cluster and stopping the malicious process. This is the primary containment step to halt active compromise; however, if the pod is managed by a ReplicaSet or Deployment, the controller will replace it, so you must also update the workload definition or scale down to prevent recreation. It is a precise operation that affects only the compromised instance.

Configure the CodeCommit source action in the pipeline to specify 'main' as the Branch name; CodePipeline then only initiates an execution when a new commit is pushed to that exact branch. This branch filter is applied at the source stage before any build or deploy action runs, preventing resource consumption for non-main branches. It is the standard, supported mechanism for branch-scoped pipeline behavior in CodePipeline.

A Cross-Region Read Replica uses Amazon RDS's asynchronous replication to continuously apply transactions from the primary DB instance to a replica in a different AWS Region. This typically achieves an RPO in the low seconds (usually 1–5 seconds) and a short RTO by promoting the replica to a standalone primary via the console or API. Because replication is ongoing, it minimizes data loss far more effectively than any interval-based snapshot strategy.

Enabling the local cache feature in CodeBuild stores resolved dependencies (e.g., Maven, pip, npm packages) in a local directory or an S3-backed bucket between builds. On subsequent builds, CodeBuild restores this cache instantly, eliminating the need to re-download and re-resolve packages. This directly reduces the network I/O bottleneck that dominates unit-test build time, especially for frequently executed builds, and is the correct way to speed up dependency-heavy pipelines.

Auto Scaling can be configured with an appropriate health check type (EC2 status checks or ELB/ALB health checks) and a termination policy to automatically detect and replace unhealthy instances. This ensures that the ASG maintains the desired instance count by terminating the unhealthy instance and launching a new one, providing a self-healing architecture for the critical application.

Lambda's execution role needs `logs:CreateLogGroup` and `logs:CreateLogStream` before `logs:PutLogEvents` can succeed, since the log group and stream must exist first. Without these actions, the function cannot create its destination, so writes fail regardless of the PutLogEvents permission. This satisfies the stem's requirement for the missing write-enabling actions.

The execution role is the IAM identity that the Lambda service assumes on the function's behalf, and you must attach an identity-based policy with logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents. Without these actions, CloudWatch Logs will reject the function's log writes, causing request failures and missing log streams. This is the standard, least-privilege pattern for granting Lambda access to CloudWatch Logs in the same account.

A lifecycle hook pauses the Auto Scaling termination process by moving the instance into the 'terminating:wait' state, giving you a configurable period to perform custom actions before the instance is finally terminated. An in-instance script or agent can monitor and gracefully drain active user sessions, commit any required state, and then call complete-lifecycle-action with the appropriate lifecycle hook token to signal that termination may proceed. This is the only option that actually holds the termination process itself and coordinates with application-level work rather than merely affecting network connections or scaling timers.

Amazon CloudWatch natively ingests the `ApproximateNumberOfMessagesVisible` metric that SQS publishes every minute, making queue depth directly measurable. A CloudWatch alarm that transitions to ALARM state based on this metric can be attached to a scaling policy in EC2 Auto Scaling (for step or simple scaling), or you can use a target tracking policy with a custom metric. This is the standard, supported mechanism for scaling compute resources based on queue backlog.

With no stack policy, CloudFormation uses a default Allow policy that permits all update actions (Update:*) on every resource, so updates can proceed for any resource. Alternatively, an explicit stack policy with a statement containing Effect: Allow, Action: Update:*, Principal: *, and Resource: * has the same effect and also allows all resources to be updated. This matches the requirement to allow updates to all resources.

The query results show a sharp upward spike in the error count in the most recent time bins, jumping from 1 to 12, which is a clear and significant acceleration in the error rate over the last 15 minutes. This trend is not random fluctuation; the consistent climb in the final bins indicates an emerging incident that requires immediate attention. The slope of the line in the visualization confirms the error rate is increasing, not just an isolated outlier.

AWS WAF is a web application firewall that filters and monitors HTTP(S) requests using rules for IP reputation, geographic origin, URI patterns, SQL injection, and cross-site scripting. Its rate-based rules automatically block IPs that exceed configured request thresholds, making it effective against HTTP floods and the low-and-slow application-layer DDoS attacks that target web endpoints. WAF integrates with CloudFront, Application Load Balancer, and API Gateway, allowing it to enforce Web ACLs at the edge or origin.

AWS CloudTrail is the native AWS service that records every API call made in your account, including the identity of the caller, the time of the call, the source IP address, the request parameters, and the response elements. It captures management events for control-plane operations across AWS services, and can also log data events for S3 object-level activity and Lambda function invocations. CloudTrail delivers these logs to an S3 bucket (and optionally CloudWatch Logs) for long-term storage and analysis, making it the correct service for auditing all AWS API calls.

The default inactivity timeout for many HTTP clients is exactly 3 seconds, so when the external API takes longer than that to respond, the client aborts with a timeout error before the Lambda function's own timeout limit is reached. Raising the client timeout (or configuring connection/read timeouts) to exceed the expected API response time directly resolves the issue. This matches the symptom precisely because every call that exceeds the threshold fails at the same 3-second mark.

Amazon RDS Performance Insights is the correct choice because it provides a database-focused dashboard that visualizes the DB Load metric in units of Average Active Sessions (AAS), directly correlating temporal load spikes with the specific SQL statements, waits, hosts, and users responsible. This enables you to drill down into individual slow queries and diagnose performance degradation without needing to manually parse slow query logs or instrument application code.

This option uses a single CodePipeline execution triggered by all branch updates, and then applies a stage condition such as #{SourceVariables.BranchName} == 'main' on the deployment action. Test and build stages still run for every branch, but non-main branches are skipped at the deployment stage, so no production release occurs for feature branches. This minimizes pipeline infrastructure, reduces maintenance, and keeps the automation fully managed inside the pipeline.

An ECS service with a task definition and a multi-AZ placement strategy is the correct pattern because the service scheduler continuously maintains the desired count, automatically replacing tasks that fail, become unhealthy, or lose connectivity. Distributing tasks across multiple Availability Zones ensures the service remains available even if an entire AZ goes down, as the remaining AZs still host task copies. Service Auto Scaling independently adjusts the desired count based on CloudWatch metrics or target tracking, providing elasticity and capacity management without sacrificing the resilience built into the service model.

Creating a custom Amazon Machine Image (AMI) that has all required runtime dependencies pre-installed and using it in the Auto Scaling group is the most robust fix. When instances launch from this golden AMI, the operating system and packages are already present, so the CodeDeploy deployment only needs to place and start the application code. This eliminates runtime failures caused by dependency installation errors and guarantees consistency across newly launched instances.

Create an IAM role in the target account with a trust policy that allows the CodePipeline service role in the originating account to assume it via sts:AssumeRole. Then configure the deployment action (e.g., ECS, CloudFormation, S3) to use that role's ARN so the pipeline can perform resource operations in the target account without long-lived credentials. This follows least privilege and avoids hard-coding keys, and it is the canonical pattern documented by AWS for cross-account CodePipeline deployments.

Amazon CloudWatch Dashboards are the native solution for building customizable operational views that aggregate metrics from AWS services, including EC2 auto scaling groups, load balancers, and custom application metrics. They support real-time graphing with automatic refresh, can combine multiple metrics, alarms, and logs into a single pane of glass, and allow cross-account or cross-region aggregation. With built-in integration for Auto Scaling group metrics like average CPU utilization and healthy host counts, CloudWatch Dashboards are the appropriate choice for a critical application's real-time operational monitoring.

AWS X-Ray traces requests as they flow through a distributed application, providing end-to-end visibility into latencies, errors, and dependencies across microservices running on Amazon EKS. By instrumenting the application with the X-Ray SDK, you can identify the specific service or database call causing performance degradation. X-Ray's service graph and trace timelines reveal exactly where requests are spending time, making it the correct choice for troubleshooting application-level performance issues.

Adding a manual approval action is the native and correct way to gate a production deployment in CodePipeline. The action is an Approval type stage step that pauses the pipeline execution until an authorized IAM principal explicitly clicks Approve or Reject in the console, or calls the appropriate AWS SDK/CLI commands. This provides a built-in, auditable human checkpoint with no additional infrastructure, and it can optionally send SNS or EventBridge notifications to reviewers.

AWS Systems Manager State Manager uses associations to define the state you want to maintain on your managed instances, including running custom scripts via Run Command documents or other SSM documents. Associations support a schedule using cron or rate expressions and can target instances by tags, resource groups, or individual instance IDs. This makes State Manager the ideal service for regularly executing a custom script on EC2 instances selected by tags. The association's schedule ensures the script runs automatically, and it provides compliance reporting on execution history.

Using AWS CodeBuild with CodeCommit as a source, you can configure pull request filters so a test build starts automatically when a PR is created, before the branch is merged. The buildspec can run unit tests and integration tests against the PR source revision, then post status back to CodeCommit. This event-driven behavior is a canonical continuous integration practice because it validates every proposed change quickly without waiting for a scheduled pipeline.

An AWS::EC2::Route entry with destination 0.0.0.0/0 and target pointing to an InternetGateway is the precise mechanism that makes a public subnet public. This route directs all non-local traffic to the internet gateway, enabling instances with public IPs to reach outbound and receive inbound internet traffic. Without this specific route, the internet gateway exists but the subnet cannot use it, so creating the route is the decisive step.

The AWS CodeBuild service role is the IAM identity that supplies temporary credentials to the build container. Pushing a Docker image to Amazon ECR requires calling the ECR API operations InitiateLayerUpload, UploadLayerPart, CompleteLayerUpload, and PutImage, so the role must explicitly allow those actions. Without these permissions, even a successfully authenticated docker login will fail when the push actually attempts to upload the image layers. Granting the policy to the service role is the secure, minimal-change fix.

A change set is a read-only summary of the modifications CloudFormation will perform if you execute it, including resource additions, removals, and replacements with details such as `Replacement` and `RequiresRecreation`. You create a change set, inspect its proposed actions—even using `--changeset` filtering or the console UI—and only then choose to execute it, which gives you a controlled, auditable review gate before any infrastructure is altered.

S3 server access logs record every request made to a bucket, capturing the authenticated identity, timestamp, source IP and operation performed. This directly satisfies the requirement to determine which actions the unauthorised user took, since the logs detail the specific REST operations against the bucket.

Shield Advanced provides always-on detection and inline mitigation at the AWS edge, absorbing large volumetric DDoS attacks before they reach the ALB. It also includes DDoS cost protection and 24/7 access to the DDoS Response Team (DRT), who can analyze attack patterns and apply mitigations directly. Enabling it on the ALB is a fundamental step for comprehensive DDoS protection.

IAM policies can restrict Git push operations to specific branches using the `codecommit:References` condition key. Denying `codecommit:GitPush` to `refs/heads/main` prevents direct pushes. Additionally, approval rule templates enforce pull request approvals. Together, they meet both requirements: no direct pushes and mandatory review.

When a manual approval action is reached, an authorized IAM user sees a Review button in the CodePipeline console and can choose Approve or Reject. Selecting Reject transitions the pipeline execution to a failed state with a status of 'Rejected', and any reviewer comment is recorded in the execution history. This is the only mechanism that directly causes a rejection.

Incorrect. Approval rule templates only require approvals from specified users; they do not verify commit signatures or enforce signing.

A cooldown period is a duration after a scaling activity during which the scaling policy cannot trigger another action, even if the CloudWatch alarm remains in breach. In Application Auto Scaling, this prevents rapid oscillation and lets the newly added tasks take effect. If a previous scale-out or scale-in occurred recently, the outstanding cooldown will block the new scaling request, which exactly matches the symptom of the alarm being breached but no scaling activity occurring.

Configuring a health check against a specific application endpoint, such as /healthz or /api/v1/status, makes the ELB perform a deep health check that exercises your application's critical request path, including framework routing, connections to dependent services, and session or cache state. This directly addresses the scenario where an instance accepts TCP or HTTP requests but is not truly ready to serve application traffic. By returning a non-200 status only when application dependencies or internal state are degraded, the ELB can accurately detect the unhealthy instance and stop sending it traffic.

CodeBuild treats any command that returns a non-zero exit code as a failed build, which immediately stops the pipeline and prevents the artifact from being promoted to the deploy stage. When a secret-scanning tool detects an issue, it exits with a non-zero code; configuring the build project to treat that as fatal ensures the pipeline is blocked before deployment. This is often implemented in the buildspec by running the scanner as the final command or using build phases with explicit failure handling.

AWS Secrets Manager stores database credentials encrypted and supports automatic rotation, so the pipeline retrieves them at deploy time via IAM-scoped API calls instead of embedding them in code or instance user data, meeting the secure storage and retrieval requirement.

The Correct answer: The `ContinueUpdateRollback` API or the AWS Management Console action is specifically designed for stacks stuck in `UPDATE_ROLLBACK_FAILED`. It resumes the rollback from the point where it failed, skips resources that were already successfully rolled back, and can optionally skip resources you explicitly specify. This recovers the stack to its last known good state with minimal disruption, and it is the only built-in mechanism that directly resolves this status.

The awslogs driver natively ships ECS container logs to CloudWatch Logs, where Logs Insights queries across all 50 services and metric filters trigger alerts on error patterns. This satisfies centralised querying and alerting without managing extra infrastructure.

The Resource does not include the bucket ARN, so bucket-level operations like ListBucket are not denied.

Correct: When CodeBuild is attached to a VPC, the build container uses an elastic network interface with the project's security group. The outbound rules on that security group must explicitly allow TCP traffic to the RDS security group on the database port (e.g., 3306 for MySQL or 5432 for PostgreSQL). If the outbound rule is missing, the packets are silently dropped, causing a timeout even though the RDS inbound rule and IAM role are correct. Since security groups are stateful, the response path is automatically allowed once the inbound rule on RDS accepts the request, but the initial outbound allowance is still required.