Troubleshooting practice questions

Increase the stack creation timeout to allow more time for the database to be created.

Why it fails: Increasing the stack creation timeout only adjusts how long CloudFormation waits before declaring the overall stack creation failed; it does not address resource-level validation errors that occur immediately during the DBInstance provisioning. If the database resource returns a CREATE_FAILED status quickly, the problem is almost always an invalid configuration parameter (e.g., unsupported DB instance class, wrong engine, or misconfigured DB subnet group), not a lack of time. Timeout changes would leave the root cause unresolved and would merely delay the same failure.

Verify that the VPC has at least two public subnets in different Availability Zones.

Why it fails: Verifying that the VPC has at least two public subnets is incorrect because an Amazon RDS database does not require public subnets; it can be deployed entirely within private subnets. The actual networking requirement is that the DB subnet group contains at least one subnet in two or more Availability Zones, and those subnets can be private. Public subnets with an Internet Gateway are only necessary if you explicitly enable Public Access on the RDS instance, which is neither required by CloudFormation templates nor a common cause of stack creation failure.

Use the Amazon RDS console to check if a DB instance with the same identifier already exists.

Why it fails: Using the RDS console to check for an existing DB instance with the same identifier is a possible but indirect and incomplete approach. A duplicate identifier would indeed cause a failure, but that is only one of many potential causes, and CloudFormation stack events already capture the specific error message from the RDS CreateDBInstance call. Furthermore, DB instance identifiers are scoped per AWS account and region, so collisions are less common; even if one exists, you would still need to examine stack events to confirm the failure reason and decide whether to change the identifier or delete the old instance.

The launch template has insufficient IAM permissions to create instances.

Why it fails: Insufficient IAM permissions in the launch template would cause the RunInstances API call to be rejected with an 'UnauthorizedOperation' or 'AccessDenied' error, not a quota-based message. The instance would never be created because the call fails at the authorization layer, and the Auto Scaling activity history would show an IAM failure reason with a CloudTrail entry. Since the error described in the scenario is explicitly a quota for running instances being exceeded, permissions issues are ruled out.

The VPC subnet does not have enough available IP addresses.

Why it fails: If the VPC subnet had no available IP addresses, the error would be 'Insufficient IP addresses available in subnet' with an InsufficientFreeAddressesInSubnet code, which occurs during the network interface allocation phase. This is a different failure mode than a quota exceeded error; the instance launch fails because the subnet's CIDR is exhausted, not because of account-wide EC2 limits. The scenario explicitly mentions a quota for running instances, so this option is incorrect.

There is an instance that is not passing health checks, preventing new instances.

Why it fails: An instance failing health checks would trigger Auto Scaling to terminate the unhealthy instance and replace it, not block the launch of new instances. The health check failure would cause a lifecycle action and replacement, and any failure to launch a replacement would be due to other constraints like instance limits or network issues. The error message would reflect the underlying launch failure (e.g., quota), not the health status itself, so this option does not explain the quota error.

The EC2 instance type is not supported in the region

Why it fails: An unsupported instance type would be rejected by the EC2 API during the CreateInstance call, so CloudFormation would record the resource as CREATE_FAILED with an error such as InvalidInstanceType or 'The requested configuration is currently not supported'. That is a validation failure, not the 'Resource creation cancelled' state, which indicates the stack operation itself was interrupted by a timeout or user cancellation. Thus this option cannot explain the observed CloudFormation event.

The IAM role attached to the instance lacks permissions

Why it fails: Permissions problems with the attached IAM instance profile manifest as AccessDeniedException errors on API calls made by the instance, such as uploading logs or invoking cfn-signal; these appear as a CREATE_FAILED status on the relevant resource or a rollback trigger, not as a cancelled resource event. CloudFormation does not cancel the creation of an EC2 instance merely because the instance's IAM role lacks permissions—that would either fail at a dependent resource or leave the instance running with an unhealthy configuration. Therefore this is not the cause of a 'Resource creation cancelled' message.

The UserData script failed due to a syntax error

Why it fails: A syntax error in UserData occurs after the EC2 instance has launched, and CloudFormation only cares about the successful creation of the instance itself, so the EC2 resource would still transition to CREATE_COMPLETE. Unless you have a WaitCondition or a CreationPolicy with cfn-signal, CloudFormation never inspects the output of the UserData script, and even a failing script merely logs an error inside the instance. The 'Resource creation cancelled' status is a CloudFormation resource-lifecycle event triggered by stack timeout or cancellation, not by a script failure taking place in the guest OS.

The Auto Scaling group has too many instances, causing increased network overhead

Why it fails: This misidentifies the scaling dynamic: an Application Load Balancer distributes each request to the least loaded healthy target, so adding instances generally reduces per-instance queueing and lowers response latency, not increases it. Only if the application performs heavy inter-instance communication or relies on a shared stateful store would more nodes add meaningful overhead, but that is not inherent to Auto Scaling. Network overhead from additional instances is negligible compared to the latency caused by a slow downstream dependency.

The ALB is routing requests to instances in different Availability Zones, increasing latency

Why it fails: For an Application Load Balancer, cross-zone load balancing is enabled by default, meaning each ALB node actively distributes requests to healthy targets across all Availability Zones in the region. Within a region, AZ-to-AZ traffic travels over AWS's redundant, high-bandwidth backbone—typically adding less than a millisecond—so it cannot be the source of a perceptible slowdown. A request would have to cross regions to experience real network latency impact, which is not the case here.

The ALB idle timeout is set too low, causing connections to be dropped

Why it fails: ALB idle timeout controls how long a connection may remain inactive before the load balancer closes it; setting it too low would terminate idle keep-alive connections, causing clients to see connection resets or 502/504 errors on the next request—not high latency during an active request. The timeout does not affect how quickly an in-flight request is processed, since it is based on inactivity, not request duration. Therefore, a low idle timeout cannot explain a slow web application; it would manifest as sporadic connectivity failures instead.

Check the CloudWatch agent status using the CloudWatch agent status command.

Why it fails: The `amazon-cloudwatch-agent-status` command only reports whether the agent process is running and its basic operational state (e.g., version, config path). It does not surface detailed transport or delivery errors, IAM permission failures, or malformed log config entries. In a pure troubleshooting scenario where logs are not appearing, this command provides no diagnostic path to identify why a log stream is missing or why the agent cannot reach CloudWatch Logs.

Configure a Lambda function to poll the CloudWatch agent for logs.

Why it fails: A Lambda function cannot 'poll' the CloudWatch agent itself because the agent is a local service and has no API endpoint for remote queries. The agent actively pushes log events to CloudWatch Logs via the PutLogEvents API; it does not expose a pull mechanism. While Lambda could be used to inspect CloudWatch Logs API metrics or query already-delivered log streams, that would only confirm the absence of logs after the fact and does not diagnose an agent-side problem such as a bad config or connectivity issue. This approach adds complexity without addressing the agent's failure mode.

Verify that the EC2 instances have an SQS queue configured for log delivery.

Why it fails: The CloudWatch agent does not use Amazon SQS at any point in its log delivery flow. Logs are gathered from local files/streams and sent directly to the CloudWatch Logs service using the AWS SDK (PutLogEvents). Requiring an SQS queue on the EC2 instances implies a queue-based pipeline that does not exist in this architecture. Misdiagnosing the problem as a missing SQS queue would lead you away from the agent's actual log file and error messages, which are the correct sources of truth for delivery failures.

The script is not included in the 'files' section of the appspec.yml

Why it fails: The script's location relative to the 'files' section is irrelevant to execution. In appspec.yml, the 'files' section lists source files to be copied onto the instance, while lifecycle scripts must be declared under the 'hooks' section, which maps each event (e.g., AfterInstall, ApplicationStart) to a run script. If a script is omitted from the 'hooks' section, it would not be executed at all, but that would not generate a non-zero exit error; it would simply not run.

The script requires dependencies that are not installed on the instance

Why it fails: Missing dependencies can cause a script to fail, but the deployment failure is caused by the script returning a non-zero exit code, not by the absence of the dependency itself. CodeDeploy does not inspect why a script failed; it only observes the exit status. Moreover, missing dependencies typically produce errors like 'command not found' or 'module not found' at runtime—these still result in a non-zero exit, but the immediate signal CodeDeploy reacts to is the exit code, not the dependency issue.

The script is not owned by the root user

Why it fails: File ownership does not impact whether a script can be executed; only the file's permission bits and the executing user's access rights matter. In CodeDeploy, the 'runas' attribute in the hooks section specifies the user under which the script runs, and as long as that user has execute permission (or the file is world-executable), the script runs regardless of whether the file is owned by root. An ownership mismatch would only matter if the 'runas' user lacked read/execute permission on the script, which is a permissions issue, not an ownership issue.

Add annotations to the traces for better filtering.

Why it fails: Annotations in X-Ray are user-defined key-value pairs attached to segments or subsegments for the purpose of indexing, searching, and filtering traces; they do not capture or display timing data for the network hops between services. Adding annotations would only help you retrieve traces that meet certain criteria after the fact, but it provides no visibility into where latency is introduced along the service boundary — making it an auxiliary tool for trace organization, not a diagnostic aid for slow inter-service communication.

View the raw segments of the upstream service.

Why it fails: Viewing the raw segments of the upstream service shows the internal work performed within that service (e.g., database queries, local processing, and subsegment timing) but stops at the point where the service sends its response. It does not include the time spent on the wire or the network round-trip between the upstream and downstream services, so it cannot reveal connection-level latency such as packet loss, DNS resolution issues, or load balancer delays that occur outside the service's own execution context.

Adjust the sampling rules to capture more traces.

Why it fails: Adjusting sampling rules changes the proportion of requests that are recorded by X-Ray, which controls trace volume and cost but has no bearing on the analysis of a specific latency problem in an already-captured trace. Even if you increase the sampling rate, you are simply recording more of the same type of trace data; the information needed to diagnose the slow connection (the per-http-edge latency metrics) is still only available through the trace map, and changing sampling rules will not add any dimensions of diagnostic visibility to the existing traces.

The build environment ran out of disk space.

Why it fails: An out-of-disk-space condition would not appear as a Gradle exit status 1 from `./gradlew build`; it would instead generate filesystem-level errors such as 'No space left on device' or 'Failed to write...' when Gradle tries to download dependencies or write its cache. Such an environment failure would likely interrupt the process earlier, for example during the `install` or `pre_build` phase, not as a clean non-zero exit from the build command itself.

The artifact packaging step failed.

Why it fails: The artifact packaging step, such as creating a ZIP/tarball or copying outputs to a designated directory, is defined in the `post_build` phase, which executes only after the `build` phase has exited successfully. Because `./gradlew build` stopped with status 1, the pipeline aborted during the `build` phase, meaning `post_build` never ran and therefore cannot be the cause of this failure.

The linting step failed.

Why it fails: In this buildspec, the `build` phase runs `./gradlew build`, a Gradle task that compiles code and runs tests; a separate linting task would be invoked explicitly (e.g., `./gradlew lint`) in `pre_build` or as its own command. A lint failure would produce lint-specific output and its own non-zero exit from that distinct command, not the generic status 1 from `./gradlew build`. Thus the linting step is not what caused the failure shown.

Configure the build to use a VPC with a NAT gateway

Why it fails: Adding the build to a VPC and routing traffic through a NAT gateway only changes the network path for outbound requests; it neither stores nor reuses Maven artifacts between executions. Each build still performs a cold download from the external repository, and the VPC/NAT overhead (NAT processing, subnet routing, IAM roles) can even increase build latency. The bottleneck here is dependency re-downloading, not network reachability, so a NAT gateway does not address the root cause.

Use AWS CodeArtifact as a proxy for Maven dependencies

Why it fails: CodeArtifact as an upstream proxy does cache packages on its own infrastructure, but that cache is remote: every CodeBuild run must still pull the dependencies over the network into the ephemeral build container, so it does not eliminate the download step or the associated network time. For Maven specifically, the local build client likely must resolve and fetch coordinates through CodeArtifact endpoints each time, and if the cache hasn't already been populated by a prior run, it still contacts the upstream repository. While CodeArtifact can reduce repeated public repository traffic, enabling local disk caching is the more direct way to avoid re-fetching dependencies on every PR build.

Change the compute type to general1.2xlarge

Why it fails: Changing the CodeBuild compute type to general1.2xlarge increases the vCPU and memory allocation, which helps CPU- or memory-bound build phases such as compilation and test execution. However, when the reported slowness comes from downloading dependencies, the limiting factor is network bandwidth and the round-trip latency of remote repositories — both of which remain unchanged on a larger instance. You will pay for more compute capacity without addressing the actual bottleneck of repeated dependency downloads.

The Deny statement condition incorrectly uses StringNotEquals, which denies all instances except those with the Production tag.

Why it fails: The Deny statement uses StringNotEquals to deny ec2:RunInstances for non-Production requests, but its action is limited to RunInstances and its condition evaluates only at launch time. It never applies to ec2:StopInstances, so it cannot 'deny all instances' for stop operations. Further, StringNotEquals is a legitimate condition operator; the issue is that the stop action has no Allow, not that the operator is malformed.

The Deny statement includes ec2:StopInstances implicitly because stop is a termination action.

Why it fails: IAM action coverage is explicit; ec2:StopInstances is a distinct API action from ec2:RunInstances and ec2:TerminateInstances, so it is not included implicitly by a Deny that mentions only RunInstances. Stopping an instance is not a termination action in IAM terms, and resource/condition elements in that Deny apply only to instance launches. Thus this rationale misreads the statement's scope and cannot explain the stop failure.

The policy does not prevent stopping instances with the Development tag; the failure must be caused by another policy or service control policy.

Why it fails: In IAM, actions not explicitly allowed are implicitly denied, so the absence of ec2:StopInstances in the Allow statement alone prevents stopping instances regardless of their Development tag. There is no need to invoke another identity-based policy or an SCP; while such policies can broaden or further restrict permissions, they are not required to produce the failure. Therefore the tag-based reasoning does not identify the actual cause.

Create an RDS event subscription for 'low storage' events.

Why it fails: RDS event subscriptions deliver SNS notifications for operational database events such as storage capacity thresholds, failover status, or maintenance windows, not for individual query execution. A 'low storage' event indicates disk space pressure, which may indirectly affect performance but does not reveal which SQL statements are slow or why. Because event notifications lack SQL text, duration, and execution plans, they cannot help diagnose specific slow queries, even if storage issues exist.

Monitor the 'CPUUtilization' metric in CloudWatch.

Why it fails: CloudWatch's CPUUtilization metric is an aggregated instance-level gauge showing the average percentage of CPU consumed by all database sessions combined. While sustained high CPU can accompany slow query problems, this metric cannot identify any individual query, its SQL text, its execution time, or its frequency. It provides a signal that the database is resource-constrained but leaves you guessing which statements to tune, so it is insufficient as a primary tool for pinpointing slow queries.

Enable Enhanced Monitoring to view process list and SQL queries.

Why it fails: Enhanced Monitoring uses a lightweight OS-level agent on the RDS host to report granular metrics such as CPU utilization, memory pressure, disk I/O, networking, and a process list at intervals as short as one second. While the process list shows the names and resource usage of OS processes (e.g., mysqld or postgres), it does not reveal the SQL text being executed or per-query statistics like execution time or rows scanned. Therefore, it cannot tell you which specific query is slow; it only hints at whether the instance itself is operating under resource stress.

The Lambda function has a very short timeout (e.g., 3 seconds) configured in the function properties.

Why it fails: The Timeout property on an AWS::Lambda::Function (e.g., 3 seconds) limits how long the function can run when invoked, not how long CloudFormation has to create the resource. The creation process—downloading the deployment package and registering the function—is not governed by this value. Even a 3-second timeout will not cause creation to fail; it only applies after the function is created and called at runtime.

The Lambda function's execution role does not have permission to download the ZIP file from S3.

Why it fails: The Lambda execution role grants permissions to the function when it runs (e.g., reading from S3, invoking services), and is not used by CloudFormation during resource creation. The S3 download during stack creation is performed by the CloudFormation service itself, which must have read access to the bucket—possibly via a CloudFormation service role. If the execution role lacked S3 permissions, you would see an access-denied error only when the function executes, not during creation.

The CloudFormation service role does not have permissions to create Lambda functions.

Why it fails: The CloudFormation service role (or the user's role) is what CloudFormation uses to make API calls to create resources. If that role lacks lambda:CreateFunction, the stack would fail with an 'API: lambda:CreateFunction AccessDenied' error, not a timeout. A timeout during resource creation points to the operation taking too long, not to a missing IAM permission. Thus, the correct diagnosis requires distinguishing between permission failures and duration overload.

Access is denied only if the bucket is encrypted

Why it fails: Denying access based on encryption is incorrect because S3 bucket encryption using SSE-S3, SSE-KMS, or SSE-C does not participate in IAM or bucket policy authorization decisions. Encryption only governs how the object is stored and decrypted, not whether a principal has permission to read it. The access failure here is caused by the bucket policy's explicit deny, which is evaluated independently of any encryption settings on the object or bucket.

Access is allowed only if the instance is in the same region

Why it fails: The AWS region where the EC2 instance runs has no bearing on S3 authorization for this scenario. S3 is a regional service with a global namespace, and IAM policy evaluation does not inspect the requester's region unless a condition key like aws:SourceIp or aws:SourceVpce explicitly references it. Region mismatch cannot grant access, and it certainly cannot override an explicit deny in the bucket policy. The denial is logic-driven, not topology-driven.

Access is allowed because the IAM role allows it

Why it fails: The IAM role attached to the EC2 instance indeed grants an allow for the S3 action, but IAM authorization is not an additive union where any single allow wins. AWS evaluates all applicable policies together, and an explicit deny in any policy—including a resource-based bucket policy—immediately overrides every allow from any other policy. This is why the instance receives AccessDenied despite having a valid IAM role permit; the deny has priority.

EC2 Status Checks

Why it fails: Amazon EC2 Status Checks are automated checks that run on every instance and report either system status (loss of power, network connectivity, or hardware issues that require AWS to repair) or instance status (misconfigured OS, networking, or corrupted file system). They provide a boolean pass/fail reachability signal, not numeric performance counters such as memory utilization, so they cannot diagnose an out-of-memory condition. Even when the instance is running and all status checks pass, the guest OS memory can be exhausted.

AWS Config

Why it fails: AWS Config is a configuration tracking and compliance service that records resource configuration items, configuration history, and configuration snapshots, and evaluates those configurations against rules you define (e.g., 'should EBS volumes be encrypted'). It detects changes in the state of a resource — like an instance type modification or a security group change — but it never samples runtime metrics from inside an EC2 instance. Memory utilization is a dynamic operating-system-level metric, not a configuration attribute, so AWS Config has no data path to capture it.

AWS CloudTrail

Why it fails: AWS CloudTrail is an auditing service that logs API activity in your AWS account, capturing who made a call, from which IP address, when, and what the API request/response looked like. It is designed for security investigation, compliance, and operational troubleshooting of control-plane actions (like RunInstances or TerminateInstances), not for collecting time-series performance data from within an instance. Memory utilization is not an API event; it is a guest-OS metric generated continuously, so CloudTrail would never contain a memory utilization reading.

Modify the CloudFormation template to use the user's IAM role instead of a service role.

Why it fails: CloudFormation cannot simply 'use the user's IAM role' because a service role must have a trust policy that allows the CloudFormation service principal (cloudformation.amazonaws.com) to assume it; a user role is intended for interactive or programmatic access by a person and does not include that trust relationship. Even if the user's role has broad permissions, passing it as the stack's role will fail with a validation error or, if it can be assumed, violate least-privilege by granting CloudFormation the same full access a user possesses. The template itself does not declare IAM roles; the role ARN is supplied at stack creation or update time, so modifying the template would not address the underlying permissions problem.

Create a new stack policy that allows the required actions.

Why it fails: A stack policy is an IAM resource-based policy attached to a CloudFormation stack that controls which update operations (e.g., Update:Modify, Update:Delete) can be performed on specific resources during a stack update. It does not grant any permissions to CloudFormation or to the underlying AWS services; it only prevents accidental changes by filtering the actions CloudFormation may attempt. The failure to create resources is an authorization failure on the resource API calls made by the service role, so adding a stack policy cannot resolve a missing IAM permission for the role.

Add the user's IAM role to the trust policy.

Why it fails: The trust policy of the service role defines which principals (services or accounts) are allowed to assume that role. Adding the user's IAM role as a trusted entity would permit that user role to assume the service role, but it would still not permit CloudFormation to assume it, because the service principal 'cloudformation.amazonaws.com' is not listed. This misconfiguration could even worsen security by creating a privilege escalation path where a user role with lower privileges can assume a role that has resource-creation permissions. The fix must instead update the trust policy to include the CloudFormation service principal only.

The npm install command is running before the source is downloaded.

Why it fails: CodeBuild automatically downloads the repository source code before any build commands are executed. The build phases run in a fixed order: source checkout happens before install, so the workspace always contains the downloaded source when `npm install` starts. If the source were somehow absent, the install phase could not even find `package.json`, producing a different error about a missing manifest, not a missing module.

The lodash package is not compatible with the Node.js version.

Why it fails: If lodash were incompatible with the configured Node.js version, `npm install` would typically fail with an `engine` warning or a compile-time error, and the build would stop before producing an artifact. A "Cannot find module 'lodash'" runtime error indicates the package was never installed into `node_modules`, which is a dependency declaration or installation problem, not a version compatibility problem.

The build environment does not have internet access to download packages.

Why it fails: Packages are downloaded from the npm registry during the install phase. If the build environment had no internet access, `npm install` would fail with a network error such as `ENOTFOUND`, `ETIMEDOUT`, or an `ECONNREFUSED` — not a module-not-found error at build time. The error message about lodash being missing means the install step either did not include lodash or was skipped for that package, not that network connectivity was the issue.

The build commands are not executed because the pre_build phase failed.

Why it fails: If the pre_build phase had failed, CodeBuild would immediately stop and mark the build as FAILED without ever running the build phase, so the missing-file error from a command in the build phase would never be observed. The error message itself indicates a file-not-found condition during command execution, not a phase-level failure. A phase failure is identified by an exit code and a clearly labeled phase name in the logs (e.g., 'PRE_BUILD' on the failing line), whereas this issue points to a path resolution problem.

The artifact definition in the buildspec.yaml is incorrect.

Why it fails: The artifact section in buildspec.yaml defines which files or directories are collected and uploaded as build outputs after the build phases successfully complete. An incorrect artifact definition would produce errors during the post-build artifact packaging step—such as an empty artifact, missing output files, or a failure to upload to S3—not a file-not-found error when executing a build command. Since the reported error occurs while running a command, it is caused by an input file reference, not by the output artifact specification.

The environment variables in CodeBuild are not set correctly.

Why it fails: Environment variables in CodeBuild (set in the project configuration, the env section of buildspec.yaml, or from a parameter store) supply dynamic values to commands but do not create, delete, or relocate files relative to the source tree. A file-not-found error arises when a literal path or a path constructed from a variable points to a non‑existent location; if a variable were undefined, the shell would typically substitute an empty string or the literal '$VAR' into the path, still causing a path error—but the root cause would be the path construction, not the environment variable mechanism itself. The question's scenario gives no indication that variable expansion is involved, so this is not the likely cause.

Modify the security group to allow SSH from the engineer's IP.

Why it fails: Modifying the security group to permit SSH from the engineer's IP addresses only the network firewall layer, not the instance's guest OS health. If the OS has panicked, the network stack is hung, or memory/CPU is exhausted, sshd cannot accept connections even when traffic reaches the instance. Security group changes are enforced by the hypervisor's packet filtering and cannot revive or interact with a frozen operating system. An out-of-band access method is needed to inspect and recover the instance.

Use AWS Systems Manager Session Manager to start a session.

Why it fails: AWS Systems Manager Session Manager is an agent-based, in-band service: the SSM agent must be installed, running, and able to reach Amazon SSM endpoints through the instance's network. If the instance is unresponsive because of an OS kernel issue, network failure, or the agent itself has stopped, it cannot authenticate or establish a WebSocket session. Session Manager also depends on an IAM instance profile with appropriate permissions and on the agent being up-to-date, so it will not function during kernel oopses or network partition events. It is therefore not a reliable path when the instance is completely unresponsive.

Check AWS Personal Health Dashboard for instance issues.

Why it fails: AWS Personal Health Dashboard (now part of AWS Health) aggregates service health, account-level events, and scheduled maintenance windows across AWS services, not per-instance guest OS status. An OS-level hang, kernel panic, or resource exhaustion in a single EC2 instance will not surface as a Personal Health Dashboard event. It can alert you to AWS-side issues such as instance store retirement or degraded hardware, but it cannot provide the OS console needed to debug an unresponsive instance. For instance-level diagnostics, you should use the EC2 console, EC2 Serial Console, or system logs.

Delete the failed stack and recreate it with the same template.

Why it fails: Deleting the failed stack and recreating it with the identical template will usually reproduce the same LimitExceeded failure, because rollback already cleans up any partially provisioned resources and the account-level quota for the resource type remains unchanged. Unless another stack or resource is deleted to free capacity, the recreate will hit the same hard limit. The correct action is to increase the quota before redeploying.

Review the IAM permissions for the CloudFormation service role.

Why it fails: Reviewing the IAM permissions of the CloudFormation service role would only address AccessDenied errors, not LimitExceededException. The error message explicitly states that an account limit has been reached, which means the request was authenticated and authorized, but the resource type's quota in that region is exhausted. IAM misconfigurations cannot produce a 'limit reached' error.

Modify the CloudFormation template to use a different resource type.

Why it fails: Switching to a different resource type in the template is an architectural workaround that avoids the specific quota only by changing what you deploy, which may not satisfy the application's actual requirements. For instance, switching from one database engine to another does not reduce the number of security groups or VPCs needed. The proper resolution is to request a quota increase for the original resource type rather than altering the design to sidestep a service limit.

The external API is throttling the request.

Why it fails: An external API responding with 429 Too Many Requests or 502 because of throttling returns a status code quickly; it does not make the HTTP client wait for the full 3-second window. Throttling errors surface as a non-2xx response that your code can handle, not as a timeout exception, so this would not produce the consistent 3-second timeout symptom.

The Lambda function is not in a VPC.

Why it fails: Lambdas outside a VPC are attached to an AWS-managed network that provides direct internet access, so they do not encounter a network-bound 3-second timeout when reaching a public API. VPC placement affects which private resources are reachable and requires a NAT gateway for internet, but the absence of a VPC is the network configuration most likely to avoid timeouts, not cause them.

The Lambda function's memory is insufficient.

Why it fails: Memory size controls the CPU proportion and memory available; insufficient memory leads to out-of-memory errors or OOM kills, not socket-level timeout exceptions after a fixed interval. The consistent 3-second timeout indicates something is timing out at the connection layer, whereas memory pressure would cause varied failures or a higher error rate correlated with algorithm complexity. Since the symptom is a duration-based cutoff, the root cause cannot be memory.