AWS Certified DevOps Engineer Professional DOP-C02 (DOP-C02) — Questions 976–1050

This is the only option that provides automatic detection and remediation. An AWS Config managed or custom rule can evaluate each security group and mark it NON_COMPLIANT if it contains an ingress rule with 0.0.0.0/0. You can attach that rule to a Systems Manager Automation document, which uses aws:executeAwsApi to call RevokeSecurityGroupIngress and remove the offending rule, or trigger an AWS Lambda function; this remediation runs automatically on each configuration change. Thus it directly satisfies the requirement to revert unauthorized changes.

The SSM Agent maintains a control-plane communication channel over HTTPS to the Systems Manager regional endpoints, either through the public internet, a NAT gateway, or interface VPC endpoints. If outbound access is blocked by security groups, network ACLs, or route tables, the instance cannot register with Systems Manager, receive patch commands, or report status, yet the agent may continue running locally without logging an explicit error. Therefore, verifying that the instance can resolve and connect to endpoints like ssm.<region>.amazonaws.com on port 443 is the first diagnostic step.

CloudWatch Logs Insights queries multiple log groups in one request using its query syntax, filtering and aggregating events directly within CloudWatch Logs. This satisfies the requirement to search several log groups for an error pattern without exporting data.

CloudFormation identifies resources by logical ID; changing it makes the template treat the RDS instance as a new resource, so the old one is deleted and a replacement created. This replacement occurs regardless of unchanged properties, matching the stem's unexpected replacement with no property edits.

Memory exhaustion caused the timeouts while CPU stayed below target, so CPU-based target tracking never scaled out. A second target tracking policy on memory utilisation triggers scaling on the actual bottleneck, preventing garbage collection pauses during future spikes.

The Lambda event source mapping for an SQS queue governs message deletion: it only deletes a message after the function returns a success response. By ensuring the mapping does not delete messages on failure (which is the standard behavior unless the function reports success), the failed message remains in the source queue. On subsequent polls, the event source mapping receives it again and invokes the function, giving the desired retry behavior. This is the correct way to let Lambda retry processing of a failed message.

Calling the UpdateStack API (or the update operation in the console) on a stack in CREATE_FAILED state is the correct recovery path. CloudFormation only re-evaluates the resources that depend on the changed parameter, so the failed RDS instance is created while already-created resources remain untouched and no downtime is introduced. Any other approach either destroys existing resources or is not applicable to a creation failure.

When the new version applied a forward-only database schema migration, the schema changed irreversibly for the running environment. CodeDeploy rolled back the ECS task set to the old code, but that old code cannot understand the new schema, causing errors, failed health checks, and a broken application. This is the recognized cause: database changes are not automatically rolled back, so they break the previous version. The fix is to implement reverse migrations or use an expansion-contraction pattern.

The correct procedure is to increment the version number in your platform definition file and then run the AWS CLI command `aws elasticbeanstalk create-platform-version`, which uploads the new packer template and associated configuration to build a fresh, immutable platform version. This new version can then be used as the `PlatformArn` in your environment's configuration, allowing the patched AMI to be deployed without affecting existing environments that reference the old version. This workflow is the documented way to apply changes to a custom platform.

Fixing the script error in the application revision directly addresses the root cause: the failure is deterministic in the artifact, so every instance that runs the same script will encounter the same problem. A subsequent redeployment with the corrected AppSpec or associated script lets CodeDeploy re-run the lifecycle hooks on all target instances, ensuring consistent and reproducible success. This is the standard remediation because CodeDeploy deployments are immutable artifacts—changes must be made in the revision, not on live instances.

Registering the instances with an Elastic Load Balancer and configuring health checks in the CodeDeploy deployment group is the correct fix because CodeDeploy can then use the ELB's health check to validate that each instance is serving traffic correctly before allowing the deployment to continue. ELB health checks also enable automatic instance replacement by the Auto Scaling group when an instance becomes unhealthy, which prevents the deployment from being stuck with known-bad hosts. This integrates deployment validation with traffic shift and instance lifecycle management, directly addressing the health check failure at the application layer.

Enabling local caching in the CodeBuild project tells the build runner to preserve a cache directory on the build host between executions, and when using Maven you can point it at the local repository (~/.m2) so previously downloaded artifacts are reused instead of fetched again. This directly eliminates the repeated network transfer of third-party dependencies, making PR builds dramatically faster by serving artifacts from local disk. Unlike remote caches or bigger compute, it targets the exact dependency-resolution bottleneck and works for both Maven and other package managers when configured correctly.

DynamoDB global tables create a fully managed, multi-Region, multi-master replicated database using DynamoDB Streams and a backend replication engine. Changes made in any replica table are replicated to all other selected Regions with sub-second latency, enabling active-active failover: if one Region fails, traffic can be redirected to a remaining Region with minimal or zero downtime. This architecture directly addresses the requirement for low-latency access and resilience to Regional outages, making it the correct answer.

Using CodeBuild to run unit tests on feature branches is correct because it provides fast, isolated feedback on each commit before the code is merged into develop. CodeBuild can be configured to respond to branch push or pull request webhooks, allowing tests to run without requiring a full CodePipeline execution. This validates code early in the development cycle, reducing the chance of integration problems and aligning with GitFlow's feature branch workflow.

Change sets generate a preview of proposed resource modifications, letting the team inspect each JSON diff before execution. Because IAM policy updates surface as distinct resource-change entries, the team can detect them and simply decline to run the change set, satisfying the requirement that production remain unmodified whenever IAM policies differ.

Deploying a NAT gateway in a public subnet is the correct solution because it allows instances in a private subnet to initiate outbound IPv4 traffic to the internet while blocking any unsolicited inbound connections. A NAT gateway is a highly available, managed service that resides in a public subnet with an Elastic IP; the private subnet's route table simply adds a 0.0.0.0/0 route pointing to the NAT gateway. This preserves the instance's private reachability and satisfies the requirement without exposing it publicly.

Failover routing is the correct choice because it explicitly pairs a primary record with a secondary record and uses Route 53 health checks to decide which to return. When the health check for the primary endpoint fails, Route 53 automatically returns the secondary record's value. This works in an active-passive configuration and gives the deterministic failover behavior the company requires.

Amazon CloudWatch Logs subscription filters can deliver log events in real time to a Kinesis data stream, which then uses a Lambda event source mapping to process each record. The stream acts as a durably buffered, highly scalable ingestion layer that decouples producers from consumers and preserves event ordering per shard. This is a fully supported path for real-time log processing and allows multiple Lambda functions or other consumers to read the same stream independently.

CloudWatch Logs Insights runs SQL-like queries directly against live CloudWatch Logs data, allowing you to count matching log entries with a query such as 'stats count(*) by status' in real time. CloudWatch Dashboards can embed these query results as graph or numeric widgets, which automatically refresh (on up to a 60-second interval) to provide a live operational view. This is the native, serverless, and lowest-latency solution designed specifically for this use case.

This is the correct approach: a dynamic reference of the form {{resolve:secretsmanager:MySecret:SecretString:password}} instructs CloudFormation to call the GetSecretValue API during stack creation and extract the field named 'password' from the SecretString of 'MySecret'. The resolved value is then substituted directly into the supported resource property, and it never appears as a literal in the template or the saved stack template. This is the official mechanism for injecting Secrets Manager values into CloudFormation templates without using a custom resource.

Updating runtime-versions to nodejs:14 is the correct fix because the CodeBuild standard image likely no longer includes Node.js 12 after that version reached end-of-life or was deprecated from the managed environment. By specifying an actively supported runtime like Node.js 14, CodeBuild provisions the matching pre-installed runtime, eliminating the "run not available" error. This change is simple, declarative, and leverages CodeBuild's managed image updates without requiring manual installation or custom images.

Network ACLs are stateless, subnet-level filters that apply to all traffic crossing the subnet boundary. Even if a security group allows inbound SSH, a deny rule in the NACL inbound table for port 22 will silently drop the connection before it reaches the instance, so inspecting the subnet's inbound NACL rules is an essential first troubleshooting step.

AWS Secrets Manager is purpose-built for storing, retrieving, and automatically rotating database credentials. It provides native integration with RDS, allowing you to configure automatic rotation on a schedule with a managed Lambda rotation function that updates credentials in both Secrets Manager and RDS. Fine-grained IAM policies can restrict access to specific secrets, and the service also supports cross-account access, making it the correct answer for securely storing and auto-rotating RDS credentials.

RDS enforces uniqueness of the DB instance identifier within an account and region, so CloudFormation's CREATE_FAILED reflects a naming collision with an existing instance rather than a template or permission fault. The stem's "already exists" error directly satisfies that constraint.

Subscription filters apply a filter pattern and forward matching log events to a destination, which can be a CloudWatch Logs destination in another account. This satisfies the cross-account aggregation requirement by streaming each account's logs into the single central logging account.

Enabling EBS encryption by default at the account level is a valid method because it automatically encrypts all new EBS volumes created in the account, using either the AWS managed key or a customer-managed KMS key. This setting is region-scoped and applies to volumes created from unencrypted snapshots when the snapshot is copied with encryption, but it does not retroactively encrypt existing unencrypted volumes. It is a control-plane safeguard that ensures any volume provisioned after enabling the setting is encrypted at rest without requiring per-volume configuration.

CloudWatch alarms are the native way to react to metric changes: the CPUUtilization metric for EC2 is published every 5 minutes with basic monitoring, so setting a period of 5 minutes ensures the alarm evaluates the average CPU utilization over each interval. A threshold of 90 means the alarm state becomes ALARM when the CPU utilization statistic exceeds 90%, and you can attach an action such as an SNS notification or Auto Scaling policy. This leverages a built-in metric with a well-established alarm evaluation model, making it the correct and simplest approach.

AWS Config continuously records configuration changes and evaluates them with managed rules, including s3-bucket-logging-enabled, which verifies server access logging is turned on for each bucket. When a bucket is created or its logging configuration changes, AWS Config re-evaluates in near real time and can publish compliance results to an SNS topic, triggering notifications. This provides a fully managed, automated, and near-real-time compliance check, making it the appropriate solution.

Change Sets let you preview the exact changes CloudFormation will make to a stack before executing them. When you create a change set, CloudFormation compiles a list of actions (add/remove/modify resources) that you can review in JSON or summary form, and you can approve, edit, or delete it without touching live infrastructure. This makes them the ideal mechanism for an approval-based change workflow, because the set can be submitted to a reviewer who validates it before the stack update is actually run.

When the ALB forwards a request to a healthy EC2 instance, the target must send a complete, valid HTTP response within the configured timeout. If the application logic crashes, the process closes the socket, or the web server returns a malformed response, the ALB cannot construct a valid HTTP response for the client and surfaces as a 502 Bad Gateway. Thus, a faulty or crashed application is the direct underlying cause of a 502 error.

AWS CodePipeline is the correct orchestrator for a CI/CD pipeline because it provides end-to-end workflow management, defining stages for source, build, test, deployment, and manual approval gates. It can trigger CodeBuild to build and push a container image, then use CodeDeploy or an ECS deploy action to update the ECS service, and even pause between environments (e.g., staging to production) for human sign-off. Its role is to coordinate the sequence and dependencies, not to execute the build or deployment itself, making it the central control plane for the pipeline.

Adding a 'cache' section to the buildspec is the correct way to declare which paths CodeBuild should cache. You specify relative or absolute paths, such as /root/.m2, and CodeBuild saves the contents to a configurable S3 cache bucket after the build. On subsequent builds, CodeBuild restores those paths before the build starts, so dependency resolution skips re-downloading artifacts. This is the official mechanism for Maven dependency caching in CodeBuild.

S3 Glacier Deep Archive is the lowest-cost storage class in S3, priced at approximately $0.00099 per GB-month, specifically designed for long-term retention of data expected to be accessed at most once per year. With a standard retrieval time of 12-48 hours, it is well suited for compliance archives like audit logs that must be retained for 7 years but rarely accessed. The 180-day minimum storage duration is irrelevant when the retention period is 84 months, and the storage cost is a fraction of even S3 Glacier Flexible Retrieval.

Cross-Region RDS read replicas provide asynchronous replication with an RPO of seconds to minutes, meeting the 1-hour RPO. Promoting a read replica and redirecting traffic via Route 53 can be done within minutes, meeting the 15-minute RTO. This is a valid warm standby configuration.

Configuring the ALB to use an SAML identity provider lets the load balancer act as the relying party, terminating the SAML exchange at the edge of the AWS network. When an unauthenticated user requests a protected target group, the ALB redirects to the IdP, validates the returned assertion, sets an encrypted session cookie, and forwards the authenticated session details to the backend as HTTP headers. This makes authentication transparent to the EC2 instances, so no code changes are required and security is centralized at one access point.

EventBridge is the recommended method for triggering a CodePipeline on CodeCommit pushes. You create a rule with a source of aws.codecommit and an event pattern that matches the codecommit:ReferenceCreated or codecommit:ReferenceUpdated event, and then filter by the branch referenceName, for example "main". The rule targets the CodePipeline pipeline, and the pipeline starts nearly instantly after the push. This approach is fully managed, has no custom code, supports precise branch filtering, and is the AWS-prescribed best practice for CodeCommit source actions.

This is the correct solution because CloudWatch Logs supports server-side encryption using a customer-managed KMS key that you can associate directly with the log group. When you create a log group or call the AssociateKmsKey API, you supply the key ARN, and CloudWatch Logs uses that key to encrypt all new incoming log events. This gives you full control over key rotation, access auditing, and lifecycle management, which is exactly what a requirement for customer-managed encryption requires. Note that the key must exist in the same AWS Region as the log group and its key policy must grant CloudWatch Logs permission to generate a data key for encryption.

This is the core problem: IAM is default-deny, so this Allow statement only grants the upload when the condition is met; it does nothing to block uploads that fail the condition if another policy grants them. To enforce encryption, you must include an explicit Deny for s3:PutObject without the required encryption condition, because Deny always overrides Allow. Merely adding a condition to an Allow does not constrain other permissions.

When a Lambda function is configured with VPC settings, the AWS Lambda service must create an elastic network interface (ENI) in each subnet on the function's behalf, which requires the execution role to have the `ec2:CreateNetworkInterface` permission. Without this permission, CloudFormation receives an 'Ec2.CreateNetworkInterface is not authorized' error and fails the stack creation, because the function resource cannot be provisioned. The role also needs `ec2:DescribeNetworkInterfaces` and `ec2:DeleteNetworkInterface` for cleanup, but the missing `CreateNetworkInterface` action is the direct blocker.

Use a custom Chef recipe and run it on the layer using OpsWorks 'Run Command' is correct because OpsWorks Stacks can execute a recipe on any currently online instance without waiting for a lifecycle event. This converges the specified layer's existing instances to the updated configuration immediately, and Chef's idempotent execution ensures only necessary changes are applied. You can target a single instance, a whole layer, or use custom Chef JSON to pass parameters.

Configuring a CloudWatch Events (now Amazon EventBridge) rule to send a notification to an Amazon SNS topic is a correct and recommended solution for this scenario. You define an event pattern that matches the CreateAccessKey event (source: iam.amazonaws.com, eventName: CreateAccessKey) and set the target to an SNS topic, which then delivers email, text, or other notifications to subscribers. This approach provides near-real-time, event-driven alerts directly from CloudTrail, with no dependence on polling or querying. It is the most direct way to satisfy the requirement of notifying the security team immediately when an access key is created.

This command is the standard way to authenticate Docker to an ECR registry. It invokes the AWS CLI to call ecr:GetAuthorizationToken, which returns a base64-encoded password valid for 12 hours, and pipes it directly to docker login using the --password-stdin flag to avoid exposing the token in process listings. The username must be AWS and the registry URL must include the account ID and region. With proper IAM permissions, this makes the subsequent docker push/build step succeed.

Amazon CloudWatch Logs centralizes log streams from EC2 instances, Lambda, and other AWS services via the CloudWatch agent, making logs available for query within seconds of ingestion. CloudWatch Logs Insights provides an interactive, purpose-built query engine that can search, filter, and aggregate log events across multiple log groups using a simple query language, without requiring external infrastructure. This combination supports fast, exploratory incident analysis, real-time alarming via metric filters, and full retention options—making it the most direct and operationally ready choice.

Assigning a customer managed key from AWS KMS to the RDS instance enables storage-level encryption of the underlying MySQL data volumes, satisfying the data-at-rest requirement. RDS integrates natively with KMS, so the DB instance, automated backups, read replicas and snapshots are all encrypted under that key.

SSHing into a failed instance and manually running the install script is the most direct way to diagnose the failure, because you can reproduce the exact command and see the script's stderr, exit code, missing dependencies, permission errors, or incorrect path assumptions. CodeDeploy lifecycle scripts run under the instance's configured user environment, so executing the same script from the deployment archive directory (for example, /opt/codedeploy-agent/deployment-root/<deployment-id>/.../deployment-archive) exposes the root cause and lets you test a fix locally. This is the standard first step in troubleshooting a failed lifecycle hook.

A blue/green deployment strategy with two S3 buckets allows you to host both the current (blue) and new (green) versions of your application or static assets in separate buckets. You validate the green version in production, then switch routing (e.g., via Route 53 or CloudFront) from blue to green, ensuring zero downtime. If issues arise after the switch, changing the routing back to the blue bucket provides an immediate rollback.

Enabling Amazon S3 caching in the CodeBuild project configuration lets you specify an S3 bucket (and optional prefix) that CodeBuild uses to store and retrieve build artifacts such as the Maven local repository. When S3 caching is turned on, CodeBuild automatically saves the directories declared in the buildspec's cache/paths section to that bucket and restores them at the start of subsequent builds, eliminating repeated dependency downloads and reducing build time. This is the recommended, fully managed caching approach for Java/Maven projects.

S3 default encryption is a bucket-level setting that applies only to objects uploaded after the setting is enabled; it has no retroactive effect on objects that already exist. If the audit found unencrypted objects, the most plausible cause is that these objects were written before the bucket's default encryption was turned on, leaving them in their original, unencrypted state. Enabling default encryption at a later time does not trigger a re-encryption of existing data unless a separate process, such as S3 Batch Operations, is explicitly run.

Configuring the deployment group to automatically roll back when a deployment fails is a built-in CodeDeploy feature: you select this option in the deployment group's rollback configuration, and if the deployment fails (for example, due to a failed health check), CodeDeploy automatically redeploys the last successfully deployed revision. This is one of the two native automatic rollback triggers, and it requires no external services or custom code. It also logs the rollback as a new deployment event for auditability.

Enabling RDS encryption at rest encrypts the underlying storage, automated backups, snapshots, and read replicas using AWS KMS AES-256 encryption, satisfying the data-at-rest requirement. Enforcing SSL connections (for example, by setting rds.force_ssl=1 or requiring ssl-mode in the client) encrypts data between the application and the database, covering data in transit. Note that enabling encryption at rest on an existing unencrypted MySQL instance requires restoring from an encrypted snapshot rather than modifying the instance in place, but together these controls fully address the stated security need.

S3 Default Encryption ensures that every object written to the bucket is automatically encrypted at rest, using either SSE-S3 (AES-256) or SSE-KMS (customer-managed KMS keys); SSE-C is not supported for default encryption. This protects the confidentiality of data at rest and helps satisfy compliance frameworks that mandate encryption. It is a direct security control for data confidentiality, but it does not control who can access the data.

State Manager associations continuously enforce a desired configuration on managed nodes, so the custom document's install command runs on any instance lacking the package and re-applies if it drifts. This satisfies the requirement that all instances maintain the specific software package without manual intervention.

Spot Instances reduce cost by up to 90% and are ideal for interruptible workloads. A diversified allocation strategy across multiple Availability Zones reduces the chance of simultaneous interruptions. Storing progress in S3 ensures that if an instance is reclaimed, another instance can resume from the last checkpoint. This combination meets cost, resilience, and progress-preservation requirements.

Firehose assumes an IAM role in each source account, and that role's permissions govern delivery. If it lacks an OpenSearch write policy for the domain in the central account, delivery fails only in those accounts, matching the intermittent failures. Cross-account access requires the role plus a domain access policy permitting it.

The CloudTrail event shows an s3:PutBucketPolicy call containing 'Principal': '*' and 'Effect': 'Allow' for 's3:GetObject'. That statement explicitly permits anonymous, unauthenticated access to all objects in the bucket. Since no condition restricts the requester and S3 object ownership permits the bucket owner to apply the policy, the bucket is now publicly accessible and every object is readable by anyone with the URL.

Retry with exponential backoff is a core resilience pattern that reattempts an operation after an exponentially increasing delay, typically with jitter to avoid synchronized retries, which prevents a thundering herd. It specifically targets transient failures, such as network timeouts, database connection drops, or throttling (e.g., API Gateway 429s or DynamoDB throttling), where the operation may succeed on a subsequent attempt if the original failure was short-lived. This pattern preserves system stability by giving the dependency time to recover and reducing continuous load, and it is widely supported in AWS SDKs and infrastructure.

Metric filters in CloudWatch Logs can parse CloudTrail logs for specific event names, counting occurrences of CreateUser API calls. Since the organization trail delivers logs to a central log group in the management account, a single metric filter can monitor IAM user creation across all member accounts. This provides a real-time, event-driven signal to trigger a CloudWatch alarm, rather than relying on periodic scans or resource configuration evaluations.

In a blue/green ECS deployment, CodeDeploy shifts traffic to the replacement task set and sets the original task set's desired count to zero. When a rollback triggers, CodeDeploy attempts to restore that original task set, but if its task definition revision was deregistered or replaced, ECS cannot recreate the task set. The missing task definition makes it impossible to satisfy the service's desired count, leaving the service at zero. This is why keeping the original task definition revision available is critical for successful rollbacks.

The CodeDeploy console provides a detailed view of each deployment, including the status of each instance and the specific lifecycle events that have succeeded or failed. This information helps pinpoint where the deployment is failing, such as during the BeforeInstall or AfterInstall hooks. It is a quick way to get an overview of the deployment progress and identify the failing stage.

Creating a service role for CodeBuild and attaching an IAM policy with ECR pull permissions is the proper way to grant access. The service role is assumed by the CodeBuild build, and actions such as ecr:GetAuthorizationToken, ecr:BatchGetImage, and ecr:GetDownloadUrlForLayer allow Docker to pull the image. This approach uses temporary credentials and follows least-privilege principles, making it both secure and auditable. It is the only solution that directly addresses the permission requirement.

AWS CloudFormation is the correct choice because it allows the CI/CD pipeline to be defined declaratively as infrastructure as code. A CloudFormation template can specify the source stage, build actions, deployment providers (including CodeDeploy), IAM roles, S3 buckets, and event triggers, then create or update the pipeline in a repeatable and version-controlled manner. This makes it a true automation mechanism for pipeline creation, unlike the other services listed, which either are the pipeline itself or operate within it.

Increasing evaluation periods to 3 (with the same period of e.g., 5 minutes) means the alarm triggers only if CPU exceeds 70% for 3 consecutive periods (15 minutes). This filters out short bursts and reduces false alarms while still catching sustained high CPU.

Fn::GetAZs returns a list of all Availability Zones available in the current region, and Fn::Select chooses an element via its zero-based index. By combining them, you can assign the first AZ to one subnet (Fn::Select [0, Fn::GetAZs ""]) and the second AZ to another (Fn::Select [1, Fn::GetAZs ""]), ensuring two distinct AZs without hardcoding region-specific names. This approach remains valid even as the region's AZ list changes and keeps the template portable across regions.

AWS CloudTrail is the governance, compliance, and audit service that continuously logs every API call made to AWS across the entire account. Each event records the caller identity, source IP address, request parameters, and response elements, which directly satisfies the security team's requirement to audit all API activity. CloudTrail can also deliver these immutable audit logs to an S3 bucket or CloudWatch Logs for long-term retention and automated analysis. It is the definitive service for answering who, what, and when regarding AWS API usage.

An AWS KMS customer master key with imported key material (Origin: EXTERNAL) cannot have automatic key rotation enabled, because rotation relies on the key material being generated and managed within AWS KMS. The import mechanism bypasses KMS's managed backing keys, so the service cannot automatically replace the backing key. To rotate such a key, you must manually create a new CMK or import new key material into the existing CMK.

This explicit Deny is the correct approach because it denies any PutObject that does not include the x-amz-server-side-encryption header with the value 'aws:kms'. The value 'aws:kms' is the algorithm identifier for SSE-KMS, ensuring all uploaded objects are encrypted with a KMS-managed key. Because it is an explicit deny, even if another policy allows an unencrypted upload, this deny overrides it. This is the standard pattern for enforcing KMS encryption across an S3 bucket.

In CodeBuild, each build phase executes from the source root, so any command that references a file—such as a build script, configuration file, or dependency manifest—must specify a path relative to that root (or use $CODEBUILD_SRC_DIR). If buildspec.yaml points to a file using an incorrect relative path (e.g., forgetting a subdirectory, misspelling a folder, or assuming a different working directory), the shell returns a 'No such file or directory' error. Verify the actual repository layout against every file path used in the install, pre_build, build, and post_build commands.

Rebooting the DB instance with the 'Reboot with failover' option selected forces a synchronous failover to the standby instance, typically completing in 60-120 seconds. This is the fastest method to manually initiate a failover while preserving existing data, as the standby is already in sync and becomes the new primary.

Deploying the ECS service across multiple subnets with larger CIDR blocks increases the total number of usable private IP addresses in different Availability Zones, allowing additional tasks to be launched. Since each awsvpc-mode task requires an ENI with its own private IP, a larger IP pool directly solves the exhaustion. Using multiple AZs also improves availability by spreading tasks across fault domains, making this the appropriate corrective action.

Custom Chef recipes are the native configuration-management mechanism in AWS OpsWorks. Assigning a recipe that invokes the platform package manager (e.g., `apt-get update` and `apt-get upgrade -y` or `yum update -y`) to the setup lifecycle event ensures it runs on every instance immediately after boot, before any application deployment. The setup event runs only once at instance launch, making it the correct hook for initial patch application, and OpsWorks propagates any recipe changes when instances are updated or started.

The `awslogs` log driver, configured under the `logConfiguration` element in the ECS task definition, makes Docker send the container's `stdout` and `stderr` directly to a specified CloudWatch Logs group and stream. The ECS agent automatically creates log streams, and you can set `awslogs-group`, `awslogs-region`, and `awslogs-stream-prefix`; the task execution role must have `logs:CreateLogStream` and `logs:PutLogEvents` permissions. This approach requires no changes to the application image, works on both Fargate and EC2 launch types, and provides near-real-time access to logs through the CloudWatch console, CLI, or APIs. It is the native, recommended method for centralizing ECS container logs.

Enabling active tracing with AWS X-Ray gives you end-to-end visibility into requests as they pass through the Lambda function and any downstream AWS services or HTTP APIs. X-Ray automatically records a trace segment for each invocation, captures timing, errors, and subsegments for calls made with the AWS SDK, and supports sampling to control cost. It also propagates trace IDs across services, enabling you to follow a single user request through the entire distributed application.

A TLS-enabled ELB (ALB or NLB) terminates the TLS/SSL handshake with clients, decrypting traffic at the AWS edge and thereby providing the cryptographic controls required for cardholder data in transit under PCI DSS Requirement 4. It also allows you to attach an AWS Certificate Manager certificate and optionally re-encrypt traffic to backend targets, so the load balancer is a correct service for securing communications.