Hard Difficulty Questions

The application source bundle is missing a required file.

Why it fails: A missing required file in the source bundle typically prevents deployment or causes the application process to fail during startup, resulting in a failed environment health status or an HTTP 500 from the application itself. A 502 Bad Gateway is generated by the nginx reverse proxy or load balancer when it cannot obtain a valid HTTP response from the configured upstream, such as when the connection is refused or reset. Even if the app crashes because of a missing file, Elastic Beanstalk's health checks would detect it and report severe health or return 503, not 502, unless the proxy specifically cannot reach the listener—which relates to port binding, not file presence.

The security group of the environment does not allow inbound HTTP traffic.

Why it fails: If the environment's security group denies inbound HTTP traffic from the load balancer, the load balancer's health checks and request forwarding will time out because connections to the instance are blocked. This usually manifests as 504 Gateway Timeout or 503 Service Unavailable from the Elastic Load Balancer, since no healthy instances are available. A 502 specifically indicates that the proxy received an invalid or empty HTTP response, not that traffic was filtered; a blocking security group would cause a connection timeout at the TCP layer rather than a malformed proxy response.

The environment's environment variables are misconfigured.

Why it fails: Environment variables that are misconfigured typically cause the application to fail at runtime by throwing exceptions, producing wrong outputs, or returning HTTP 500 responses because the code itself is running but cannot complete its logic. A 502 Bad Gateway is not an application-level error; it's a proxy-level signal that the upstream server didn't respond correctly to the proxy. Unless the misconfigured variable directly causes the process to exit without releasing the port, it won't trigger 502—it will more likely fail health checks and lead to 500/503 from the app or ELB.

The Lambda function is throwing an unhandled exception

Why it fails: An unhandled exception in the Lambda function would typically cause API Gateway to return a 502 Bad Gateway, but it would also generate an error log entry in CloudWatch Logs. Since the logs show no errors, this can be eliminated as a cause. A 502 from an unhandled exception is also accompanied by a response body containing 'Internal server error' or similar, which is not observed here.

The API Gateway has reached its maximum concurrency limit

Why it fails: API Gateway concurrency limits, such as throughput throttling or burst limits, are enforced as rate limits and produce HTTP 429 Too Many Requests responses when exceeded. Neither account-level nor usage-plan concurrency constraints cause a 502 Bad Gateway, which indicates a proxy or integration-level failure. Additionally, Lambda function concurrency limits would yield 429 or 503 errors, not 502, so this is not the correct cause.

The Lambda function is timing out and API Gateway is not handling the timeout correctly

Why it fails: When a Lambda function times out, API Gateway returns a 504 Gateway Timeout because the backend did not respond within the configured timeout, typically 29 seconds for synchronous invocation. This is fundamentally different from a 502, which indicates a malformed or oversized response after the backend has already finished processing. API Gateway does not 'mis-handle' a timeout into a 502; the status code is deterministic, so this option is incorrect.

CloudFormation StackSets

Why it fails: CloudFormation StackSets are designed for multi-account and multi-region stack deployments, allowing you to manage identical stacks across many accounts from a single template. They do not provide a review or approval mechanism for changes to a single production stack, as their primary purpose is orchestration and consistency across environments rather than change validation.

CloudFormation Stack Policies

Why it fails: CloudFormation Stack Policies are IAM-like JSON documents that protect specific resources from being updated or deleted during a stack update, acting as a safety guardrail. However, they do not offer a preview of the changes or a human review step; they simply deny certain update actions if attempted, so they cannot serve as a process to assess and approve changes before execution.

CloudFormation Drift Detection

Why it fails: CloudFormation Drift Detection is a reactive tool that compares the actual state of stack resources to the expected template configuration to identify manual changes made outside of CloudFormation. It audits what has already happened rather than reviewing planned changes, so it cannot be used to evaluate and approve modifications before they are applied to a production environment.

The S3 bucket has Amazon S3 Transfer Acceleration enabled, which is not supported by CodePipeline.

Why it fails: S3 Transfer Acceleration is fully supported for CodePipeline artifact buckets; it simply uses CloudFront edge endpoints to speed up transfers. Enabling it does not alter the bucket's access control or permission model, so it cannot cause the access-denied error described. The error is a permissions problem, not a transport-layer feature conflict.

The KMS key used to encrypt the bucket objects has been rotated, causing the pipeline to lose access.

Why it fails: AWS KMS automatic key rotation only creates new backing keys while retaining the same key ID, so key usage policies and grants remain valid. If the key were manually rotated by disabling or replacing it, the pipeline would encounter an AccessDenied from KMS when calling kms:Decrypt, not a bucket-policy-related error. The specific error text points to the bucket policy, so this explanation does not match the symptom.

The artifact bucket is in a different AWS Region than the pipeline, and cross-region replication is not enabled.

Why it fails: CodePipeline handles cross-region pipelines by provisioning separate artifact buckets in each AWS Region and configuring actions with the appropriate bucket ARN; it does not rely on S3 Cross-Region Replication to copy artifacts. A different-region bucket is a supported configuration as long as the pipeline and the bucket are correctly specified in the action's ArtifactStore. The failure described involves the bucket policy in the region where the bucket exists, not replication, so this is incorrect.

The stack has a stack policy that prevents updates; modify the stack policy.

Why it fails: A CloudFormation stack policy is an IAM-like resource policy that controls which physical resources can be updated, and if it blocks a change it returns a specific denial error such as 'Action denied by stack policy' during the update operation. The error described as 'Rate exceeded' is a throttling exception from the CloudFormation API itself, not a resource-level authorization failure, so modifying the stack policy would have no effect on the exception. Additionally, stack policies protect a stack against accidental updates but are completely unrelated to API request rate quotas.

The IAM role used by CloudFormation does not have sufficient permissions; update the role policy.

Why it fails: Insufficient IAM permissions for the CloudFormation role would cause AccessDeniedException or 'is not authorized to perform' errors when CloudFormation tries to call other services like S3 or EC2 during stack creation or update, not an API rate limit error. The 'Rate exceeded' message specifically indicates that the account has exhausted the default CloudFormation API request quota due to too many concurrent stack operations, which is an account-level throttling condition, not a permissions problem. Updating the role policy would be the remedy for a lack of authorization, but it cannot fix API throttling.

The pipeline is exceeding the CodePipeline execution frequency limit; reduce the number of pipeline executions.

Why it fails: CodePipeline does not define a per-execution frequency limit that would surface as a 'Rate exceeded' error from within a CloudFormation stack action; its own API has separate throttling limits for the CodePipeline control plane, and those would return a 'ThrottlingException' in the pipeline's API calls, not in the CloudFormation update output. When a CloudFormation action in a pipeline fails with 'Rate exceeded,' it is the CloudFormation service that is throttling, not CodePipeline limiting how often you run the pipeline. Reducing pipeline executions would not raise the CloudFormation API quota and therefore would not resolve the root cause.

AWS Network Firewall

Why it fails: AWS Network Firewall is a managed, stateful firewall that operates at the VPC boundary and filters traffic based on network attributes such as IP addresses, ports, protocols, and Suricata-compatible signature rules. While it can inspect and block certain malicious traffic, it is not a web application firewall and lacks the deep HTTP/HTTPS request parsing needed to distinguish legitimate application traffic from SQL injection or XSS payloads. It is better suited for network-layer segmentation and east-west traffic policing, not for per-request layer-7 filtering on an ALB.

AWS Shield Advanced

Why it fails: AWS Shield Advanced is a dedicated DDoS protection service that provides enhanced detection, always-on mitigations, and cost protection against volumetric and stateful DDoS attacks at the network and transport layers. It does not function as a rule-based web application firewall and cannot inspect individual request bodies, headers, or URI patterns to selectively block SQL injection or XSS attempts. Although Shield Advanced can be used alongside AWS WAF as part of a defense-in-depth strategy, it is not a substitute for WAF in this application-layer filtering scenario.

Amazon GuardDuty

Why it fails: Amazon GuardDuty is a continuous threat detection service that analyzes AWS CloudTrail management events, VPC Flow Logs, and DNS query logs to identify indicators of compromise such as brute-force attempts, cryptocurrency mining, or suspicious API call patterns. It operates asynchronously in the background and does not sit inline in the request path, so it cannot evaluate or filter live HTTP requests targeting the application. GuardDuty also lacks native rule sets for SQL injection and cross-site scripting, making it entirely unsuitable for the layer-7 filtering requirement described here.

Increase the number of core nodes to 20 to improve parallelism.

Why it fails: Increasing the number of core nodes to 20 improves parallelism but does not address the root cause of Spot interruptions. Spot capacity is reclaimed independently of node count; more nodes actually increase the surface area for potential interruption. A larger fleet without a diversified instance strategy or AZ spread remains equally vulnerable to simultaneous capacity reclamation.

Switch to using On-Demand instances for all nodes.

Why it fails: Switching all nodes to On-Demand guarantees that interruptions will not occur, but it defeats the purpose of using Spot and significantly increases costs. The question focuses on mitigating interruptions while arguably maintaining cost efficiency, so a wholesale switch is an over-correction. It also does not leverage the resilience benefits of diversifying instance types and Availability Zones that a mixed policy provides.

Configure the cluster to terminate idle nodes after 5 minutes to reduce costs.

Why it fails: Configuring the cluster to terminate idle nodes after 5 minutes is a cost-control measure that has no bearing on Spot interruptions. It may even harm a batch workload by shutting down nodes during brief processing gaps, causing reconfiguration overhead. This action does not alter the instance type or AZ diversity of the fleet, so the risk of interruption remains unchanged.

AWS Systems Manager Parameter Store

Why it fails: AWS Systems Manager Parameter Store can store secrets as SecureString values encrypted with KMS, but it does not provide automatic rotation out of the box. You would need to build a custom rotation mechanism, often using AWS Lambda, which adds complexity and risk of inconsistent rotation. Parameter Store is better suited for configuration parameters, non-sensitive data, or secrets that can tolerate manual rotation, making it less robust than Secrets Manager for sensitive database credentials.

Amazon DynamoDB

Why it fails: Amazon DynamoDB is a fully managed NoSQL database designed for scalable, low-latency application data storage, not a secrets management service. Storing database credentials in DynamoDB forces you to implement your own encryption, access control, rotation, and audit logging, which is error-prone and lacks AWS-native lifecycle management. It is a poor choice for sensitive data because it does not offer built-in rotation or secret versioning, and integrating it with Lambda would require significant custom development.

AWS IAM roles

Why it fails: AWS IAM roles are an identity and access management construct that grants permissions to AWS principals, such as users, services, or Lambda functions, via temporary credentials. They do not store the secret values themselves; rather, they can enable IAM database authentication, which lets applications authenticate to supported AWS databases without retrieving a stored password. However, for the explicit purpose of storing sensitive data such as database credentials, IAM roles are not a storage service and cannot hold the secret content, making them an incorrect answer.

Set a DeletionPolicy on the stack to retain resources when the stack is deleted.

Why it fails: A DeletionPolicy is an attribute applied to individual CloudFormation resources, not to the stack as a whole. It determines what happens to a resource when it is removed from the stack template or when the stack is deleted (e.g., Retain, Snapshot, Delete). It is a lifecycle control, not an access control, so it does nothing to restrict who can modify or delete the stack. To protect a stack from accidental deletion, you would instead use IAM policies or an explicit deny on DeleteStack.

Define a StackSetPolicy to control permissions across accounts.

Why it fails: There is no AWS resource called 'StackSetPolicy' in AWS CloudFormation StackSets. StackSets use IAM roles to perform deployments across accounts—typically an administration role and target-account execution roles—but authorization is managed through standard IAM policies and trust relationships, not a dedicated policy resource attached to the stack set. Attempting to define a StackSetPolicy in a template or API call would result in an error because the resource type does not exist.

DiskReadOps

Why it fails: DiskReadOps tracks the number of read operations completed by a disk volume. A memory leak consumes RAM and, later, possibly swap space, but it does not inherently cause disk reads; disk read activity typically stems from file I/O or application data access. While heavy paging can eventually lead to swap I/O, DiskReadOps specifically measures block device requests, not memory-consumption trends, making it insensitive to a leak.

NetworkIn

Why it fails: NetworkIn measures the number of bytes received on the instance's network interfaces. This metric is driven by incoming traffic, which has no direct relationship with memory allocation or deallocation. A process with a memory leak may continue to use the same network patterns, and the leak itself will not alter NetworkIn unless the leak is triggered by specific network requests—making it an unreliable and indirect indicator.

CPUUtilization

Why it fails: CPUUtilization is a default CloudWatch metric that represents the percentage of allocated compute capacity being used. While a memory leak can cause the OS or garbage collector to compensate over time, the leak itself is a passive failure—the allocated memory simply remains unreferenced, and CPU usage is not necessarily affected until the system starts swapping or becomes OOM-bound. Many other factors, such as active load, thread contention, or inefficient code, can cause high CPU, so this metric lacks specificity for diagnosing a memory leak.

The S3 artifact bucket in Account A does not have a bucket policy allowing Account B.

Why it fails: An S3 bucket policy in Account A that grants access to Account B is often necessary for cross-account artifact retrieval, but it is not the source of this specific failure. The error message reported by CodePipeline pertains to the deployment role in Account B failing to assume or use permissions, not to an S3 access control list or policy issue. If the bucket policy were missing, you would see an AccessDenied error when the role attempts to read from the bucket, which is distinct from an assume-role or KMS decryption failure.

The deployment role in Account B does not exist.

Why it fails: If the deployment role in Account B did not exist, CodePipeline would fail the action with a clear, immediate error during the AssumeRole call, such as "The role ARN is not valid" or "AccessDenied: User not authorized to perform sts:AssumeRole". The fact that the pipeline reaches the artifact-handling stage means the role was successfully assumed, so the root cause must lie downstream. Therefore, a missing role is not the issue here, and the error is instead tied to permission to access the encrypted artifact.

The CloudFormation service role in Account B is missing.

Why it fails: The CloudFormation service role in Account B is relevant only when CloudFormation actually creates, updates, or deletes the stack resources; it is not used by CodePipeline to fetch artifacts or to assume the deployment role. A missing CloudFormation service role would produce stack operation errors like "CloudFormation is not authorized to perform action" after the pipeline action has already started, not a failure to decrypt the artifact. Thus, this option is unrelated to the KMS decryption problem described by the error.

Export the memory metric and application logs to Amazon S3 and use Amazon Athena to join them

Why it fails: Exporting CloudWatch Logs to S3 and querying with Athena is inherently batch-oriented; a Logs export task can take up to 12 hours to deliver, so this approach lacks the real-time visibility needed to respond to active memory spikes. Additionally, joining memory metrics with logs in Athena requires manually aligning timestamps across separate export files, and Athena's per-query processing adds latency that is impractical for interactive troubleshooting.

Enable AWS X-Ray on the application to trace requests and identify memory-heavy requests

Why it fails: AWS X-Ray is designed for distributed tracing of application requests, capturing segments and subsegments, but it does not collect or expose EC2 instance memory utilization by default. While you can propagate custom metadata or annotations, correlating those traces with CloudWatch memory metrics requires building a custom reporting pipeline, and memory spikes from background processes or garbage collection would remain invisible if you only trace incoming requests.

Use Amazon EventBridge to capture EC2 instance state changes and correlate with memory spikes

Why it fails: Amazon EventBridge is a serverless event bus that reacts to AWS service events, such as EC2 instance state-change notifications or CloudWatch alarm state transitions, but it does not ingest or analyze application log content. Instance state changes rarely coincide with memory pressure, since an instance can remain 'running' while memory usage climbs; using EventBridge alone would only allow you to trigger a response, not to perform the correlation needed to understand the spike's root cause.

CodeBuild cannot access resources in a private subnet unless it uses a NAT gateway.

Why it fails: This is false because CodeBuild can be configured to run in a VPC by specifying the private subnets and security groups. The build environment's elastic network interface is placed directly into that private subnet, so it can reach RDS without any NAT gateway. A NAT gateway would only be needed for outbound internet traffic, not for communicating with RDS inside the same VPC. Therefore, the lack of a NAT gateway is not the reason for the connection failure.

The CodeBuild service role does not have rds:Connect permission.

Why it fails: IAM permissions do not control database connections at the network or session level. The CodeBuild service role governs AWS API actions, such as RDS describe or modify, but connecting to the database itself requires valid database credentials or IAM database authentication for supported engines. If the network path is blocked, no IAM action can establish a connection, and adding rds:Connect would not help. This option misidentifies the failure as an authorization issue when it is a traffic routing issue.

The RDS instance is in a different subnet CIDR than CodeBuild's subnet.

Why it fails: Subnets with different CIDR ranges can communicate normally within the same VPC as long as the route tables have a local route for the VPC's CIDR block. The VPC router makes local routing transparent across subnet boundaries, so the differing subnet CIDRs do not block traffic. Network access is governed by security groups and network ACLs, not by matching subnet addresses. Therefore, this is not a valid explanation for the connection failure.

The Lambda runtime (nodejs18.x) does not support X-Ray tracing.

Why it fails: The Node.js 18 Lambda runtime fully supports AWS X-Ray; the X-Ray SDK has official packages for Node.js and the runtime includes the required support for service-side tracing. Runtime version determines language support, not whether X-Ray is available, so this cannot be the cause of missing trace data. In fact, nodejs18.x is one of the actively traced runtimes in AWS Lambda.

The TracingConfig mode is set to 'Active' but should be 'PassThrough'.

Why it fails: TracingConfig mode should be Active when you want X-Ray to trace every invocation; PassThrough would only emit trace data when a parent tracing header already exists, which is not appropriate for unconditionally enabling tracing. Active is the correct setting for this use case, so the complaint that it 'should be PassThrough' is incorrect. The problem is not the mode but the role permissions.

The Lambda function code does not use the AWS X-Ray SDK.

Why it fails: Using the AWS X-Ray SDK in function code is required only to instrument downstream HTTP calls, databases, and to create custom subsegments; it is not required for Lambda itself to generate and upload the basic service trace. With Active tracing, Lambda automatically creates the invocation segment and the daemon uploads it if the execution role has the right permissions. Missing SDK usage would produce less detailed traces, but it would not prevent the function's own trace from reaching X-Ray.

Create a buildspec file that includes a sleep command to stagger start times.

Why it fails: Does not prevent overlap; just delays.

Set up a separate CodeBuild project for each job and use a custom retry policy.

Why it fails: Different projects do not prevent overlap within same job.

Use Amazon CloudWatch Events to trigger a Lambda function that checks the build status before starting a new build.

Why it fails: Lambda can check and prevent overlapping builds.

Place all tasks in the same Availability Zone to reduce latency

Why it fails: Collocating every task in a single Availability Zone trades resilience for the negligible latency saved over inter-AZ network hops. If that AZ experiences an outage, the entire service becomes unavailable because ECS cannot place replacement tasks elsewhere, and the service scheduler's default spread placement is overridden. A production microservice must tolerate an AZ failure, which requires distributing tasks across multiple AZs rather than pinning them to one.

Run a standalone Fargate task and use a CloudWatch alarm to restart it

Why it fails: A standalone Fargate task is a one-shot invocation: ECS does not track its health or restart it if it exits, because only tasks managed by an ECS service benefit from desired-count reconciliation. A CloudWatch alarm can only notify or trigger another action (such as a Lambda function), not directly restart a Fargate task, and the intervention window leaves the service down. This approach lacks the automatic replacement that an ECS service provides, and also does not support multi-AZ distribution.

Use an EC2 launch type with a single instance to reduce complexity

Why it fails: Running an EC2 launch type with a single instance creates a single point of failure: if that instance terminates, crashes, or is stopped for maintenance, every task on it is lost and the cluster has no registered container instance on which to place replacements. Even with an ECS service, desired count cannot be maintained because the service scheduler has no other instance in the cluster. Multi-AZ fault tolerance and enough capacity for tasks require a cluster of multiple instances, especially for a critical microservices workload.

The CloudFormation stack is in a 'ROLLBACK_COMPLETE' state and cannot be updated.

Why it fails: A CloudFormation stack in ROLLBACK_COMPLETE state has failed during creation and was rolled back; attempting to update it triggers a stack status error such as 'Stack is in ROLLBACK_COMPLETE state and cannot be updated,' which is an entirely different error class from the reported 'security token invalid' ExpiredTokenException. The deploy action would fail before calling CloudFormation APIs with credentials, or would receive a ValidationError about stack state, not an authentication error. Therefore this option does not explain the observed symptom.

The CodeBuild project does not have access to the CodeCommit repository.

Why it fails: CodeBuild's access to the CodeCommit repository is established during the source phase through the source provider and build project configuration; if the build role lacked repository permissions, the failure would occur as a 'Source' stage error or a 'Host key not verified' / 'Unable to access repository' error during the Build stage. The deploy stage no longer fetches code from CodeCommit—it runs the SAM package and calls CloudFormation using the build project's service role. Since the error occurs specifically in the deploy stage as an AWS API token error, this option is incorrect.

The SAM template is invalid and contains syntax errors.

Why it fails: A syntactically invalid SAM template would cause a template validation failure from CloudFormation or an error during the `sam build`/`sam package` step, such as 'Template format error: YAML not well-formed' or 'Transform AWS::Serverless-2016-10-31 failed.' Such validation errors occur at the point the template is parsed—long before any CloudFormation API call is made—and they would not produce a 'security token invalid' ExpiredTokenException. Therefore this option cannot explain the deploy-stage token error.

Create a CloudTrail organization trail and use CloudTrail Insights to detect configuration changes.

Why it fails: CloudTrail Insights is designed to analyze write-only management events to identify unusual activity, such as anomalies in API usage, not to monitor configuration changes to CloudTrail itself. An organization trail centralizes event logging, but it does not detect if the trail is disabled, its settings are altered, or if a new trail is created without proper coverage. Therefore, this option would not ensure that CloudTrail is enabled across the organization.

Set up CloudWatch Events rules in each account to detect trail disabling.

Why it fails: CloudWatch Events (now Amazon EventBridge) rules can capture API events like `DisableTrail`, but setting up these rules individually in each account is operationally burdensome and does not provide a centralized view of compliance. Since the rules must be created per account, there is no automatic propagation to new accounts, and auditing would require navigating each account's events separately. This solution lacks the organization-wide governance capabilities needed to continuously enforce CloudTrail enablement.

Use AWS Trusted Advisor to check CloudTrail configuration in each account.

Why it fails: AWS Trusted Advisor provides best-practice checks for individual accounts, but its checks are accessed per account and do not aggregate compliance status across an AWS Organization. Even though Trusted Advisor can identify that CloudTrail is not enabled in a specific account, the results are not centrally viewable or programmatically enforceable for all accounts at once. Thus, while useful for a single account, it does not meet the requirement for multi-account centralized monitoring.

CloudFormation can automatically create new AWS accounts using a template.

Why it fails: CloudFormation templates are declarative documents that only manage resources that already exist within a single AWS account. There is no CloudFormation resource type that creates a new AWS account; account creation is performed by AWS Organizations using the CreateAccount API or during AWS Control Tower provisioning. Attempting to place account creation in a template would fail because the template has no valid resource type and no credentials to create the account outside the organization's management path.

Nested stacks can be used to deploy resources in different accounts from a single template.

Why it fails: Nested stacks are stacks declared inside a parent stack, enabling modular and reusable templates. All resources in the parent and nested stacks are provisioned within the same AWS account and AWS region; there is no field or parameter that changes the target account or region for a nested stack. Therefore, nested stacks cannot deploy resources across multiple accounts, and trying to use them for that purpose will either fail or require a different mechanism such as AWS CloudFormation StackSets.

You can use cross-stack references to share resources between accounts.

Why it fails: Cross-stack references allow a stack in the same account and region to export an output (for example, a VPC ID) and another stack to import it using the Fn::ImportValue intrinsic function. The export namespace is per account and per region, so a stack in another account cannot import that exported value; the import would fail because the value does not exist in that account's namespace. For sharing resources across accounts, you should use AWS Resource Access Manager (RAM) or StackSets to provision synchronized resources, not CloudFormation cross-stack references.

The build stage did not produce the correct output artifact.

Why it fails: A missing or misnamed build output artifact is a data problem, not a credentials problem. CodePipeline reports this as an artifact resolution error on the Deploy stage, such as 'Artifact ... does not exist' or 'Unable to download artifact', typically before invoking CloudFormation. The error in this scenario is an invalid security token, which is raised when the AWS API call to CloudFormation or STS fails authentication/authorization, so the build artifact cannot be the cause.

The SAM template has a syntax error.

Why it fails: A SAM template syntax error would be caught during the build or package phase when `sam build` parses the template, producing a YAML parse error, unknown resource type, or invalid property error with a file and line number. CloudFormation would not report an invalid security token because the template never reaches an API call; even in CodePipeline, the validation error appears before the deploy action attempts to assume a role. Therefore a malformed template would yield a different, template-specific error message.

The 'sam deploy' command is missing the '--capabilities' parameter.

Why it fails: Omitting `--capabilities` from the `sam deploy` command causes CloudFormation to reject the change set with a 'requires capabilities: [CAPABILITY_IAM]' error, which is a template validation/authorization condition, not a security token failure. CodePipeline executes `sam deploy` as a shell command and does not see an invalid token for a capabilities-parameter omission. The error here is at the STS role-assumption layer, so a missing capabilities flag is an unrelated common mistake.