Hard Difficulty Questions

Condition with aws:SourceArn

Why it fails: The aws:SourceArn condition key is used to restrict access based on the ARN of the AWS resource that is making the request, such as an AWS Lambda function or an EC2 instance. While it can enhance security by ensuring requests originate from expected services, it does not provide a unique identifier for a third-party vendor's specific assumption of a role. It cannot be used to enforce a secret shared between the two accounts for cross-account role assumption.

Condition with aws:SourceAccount

Why it fails: The aws:SourceAccount condition key restricts access to requests originating from a specific AWS account ID. While this can limit access to a known vendor's account, it does not provide a unique, secret identifier that the vendor must present with each role assumption. This means any principal within the vendor's account could potentially assume the role, and it doesn't protect against the "confused deputy" scenario where the vendor's account might be tricked into making an unauthorized request.

Principal element with the vendor's AWS account ID

Why it fails: Simply listing the vendor's AWS account ID in the Principal element of an IAM role's trust policy allows any IAM user or role within that vendor's account to assume the role. This approach lacks a mechanism to verify that the specific request is legitimate and intended by the vendor, as it doesn't require a unique, secret identifier. Without an additional condition like sts:ExternalId, it leaves the access vulnerable to misuse or the "confused deputy" problem within the vendor's own environment.

Create a Lambda authorizer that checks the token against Cognito.

Why it fails: A custom Lambda authorizer can be written to manually decode and validate a Cognito-issued JWT against the user pool's public signing keys, and this approach does work, but it requires the developer to implement token parsing, signature verification, and expiration checks by hand, duplicating logic that API Gateway's built-in Cognito authorizer already provides natively with far less code and maintenance.

Use an IAM authorizer with a policy that allows only Cognito roles.

Why it fails: An IAM authorizer validates AWS Signature Version 4 signed requests using IAM credentials, roles, or Cognito identity pool temporary AWS credentials; it does not natively validate Cognito user pool ID or access tokens, so a request carrying a Cognito user pool JWT would be rejected because it isn't a SigV4-signed request at all.

Use a resource policy on API Gateway to restrict by source IP.

Why it fails: A resource policy that restricts access by source IP address controls where requests can originate from at the network level, but it performs no validation of user identity or credentials whatsoever, so any client from an allowed IP range could call the API without ever proving they are an authenticated Cognito user.

The Lambda function's execution role lacks permissions to write logs to CloudWatch.

Why it fails: An error indicating that the Lambda function's execution role cannot be assumed (e.g., `AccessDeniedException` on `sts:AssumeRole`) occurs during the initial setup or invocation phase. This is distinct from a lack of permissions to write logs to CloudWatch, which would manifest as a runtime error within the function's execution environment, typically an `AccessDenied` error on `logs:CreateLogStream` or `logs:PutLogEvents` after the role has been successfully assumed.

The Lambda function's deployment package is not stored in Amazon S3.

Why it fails: CloudFormation deployment errors related to the Lambda function's code package typically manifest as issues with S3 object retrieval, such as 'NoSuchBucket' or 'AccessDenied' for the specified S3 bucket, or 'InvalidParameterValue' if the S3 key is incorrect. The problem described, however, points to a fundamental inability for the Lambda service to take on the specified execution role, which is distinct from package location or accessibility issues.

The Lambda function's code is too large for the deployment.

Why it fails: Lambda function code size limits are a deployment constraint, with a maximum zipped package size of 50 MB and an unzipped size of 250 MB. Exceeding these limits would result in a specific error message indicating a 'Code size too large' or 'InvalidParameterValue' during the function creation, not an `sts:AssumeRole` failure related to the role's trust policy, which governs who can assume the role.

AWS Secrets Manager

Why it fails: Incorrect: AWS Secrets Manager is for storing and rotating secrets (e.g., database credentials), not for encrypting S3 data at rest.

AWS Certificate Manager (ACM)

Why it fails: ACM issues and renews TLS certificates for transport encryption; it neither encrypts S3 objects at rest nor manages data encryption keys with annual rotation. It is tempting because ACM handles key material, and would be correct for securing HTTPS endpoints, not object storage.

AWS CloudHSM

Why it fails: Incorrect: AWS CloudHSM provides hardware security modules but does not natively integrate with S3 SSE and does not support automatic key rotation.

Enable caching in the Lambda function code

Why it fails: API Gateway's built-in caching mechanism operates at the API layer, external to the Lambda function's execution environment. While a Lambda function *could* implement its own application-level caching using services like ElastiCache, the question implies leveraging API Gateway's native caching to reduce latency for API responses. Enabling caching within the Lambda function code would not utilize API Gateway's integrated caching feature, which is designed to intercept and serve responses before invoking the backend.

Set the TTL in the API Gateway method request integration

Why it fails: The Time-To-Live (TTL) for API Gateway's stage-level caching is configured within the cache settings for a specific stage, not directly within the method request integration settings. The method request integration primarily defines how API Gateway maps incoming request parameters to the backend integration, such as a Lambda function. Cache settings, including TTL, cache capacity, and encryption, are distinct configurations applied to the API Gateway stage itself after caching has been enabled.

Use Amazon ElastiCache and modify the Lambda function to check cache

Why it fails: Using Amazon ElastiCache requires the Lambda function to implement cache-check logic itself, whereas API Gateway caching operates at the API layer without code changes. This option is tempting because ElastiCache is a valid caching service for reducing latency in Lambda-based applications, and it would be correct if the requirement were to cache database query results or session data rather than API responses.

The lifecycle rule is missing the 'Prefix' property, causing it to be invalid.

Why it fails: The statement is incorrect because the 'Prefix' property in an S3 lifecycle rule is entirely optional. If omitted, the rule automatically applies to all objects within the bucket, effectively using an empty prefix. Therefore, its absence does not render the lifecycle rule invalid or cause a CloudFormation deployment failure, as it defaults to a valid scope for the entire bucket.

The lifecycle rule must have a 'Transitions' property.

Why it fails: The assertion that an S3 lifecycle rule must contain a 'Transitions' property is incorrect. Lifecycle rules are highly flexible and can be valid and functional even if they only specify 'Expiration' actions, or simply define a rule status without any object movement instructions. The 'Transitions' property is an optional configuration used specifically for moving objects between different storage classes.

The bucket name contains an account ID, which is not allowed.

Why it fails: The claim that an S3 bucket name cannot contain an AWS account ID is incorrect. While S3 bucket names must be globally unique and adhere to specific naming conventions (e.g., lowercase, no underscores, 3-63 characters), they are permitted to include numbers and hyphens. Therefore, incorporating an account ID, which is a sequence of digits, is syntactically allowed within the general S3 bucket naming rules, even if it's not a common practice for all use cases.

The bucket policy denies access to the error.html object.

Why it fails: While a bucket policy can indeed deny access to specific objects, resulting in a 403 Forbidden error, this option is incorrect because the primary issue described is the failure to display a *custom* error page. If the bucket policy explicitly denied access to `error.html`, S3 would return a generic 403 error, not necessarily indicate a problem with the static website hosting configuration's ability to route to a custom error document. The question implies the custom error page mechanism itself is not functioning as expected, which points to configuration rather than a direct access denial.

The index.html is missing from the bucket.

Why it fails: The absence of `index.html` would typically result in an HTTP 404 Not Found error when a user attempts to access the root URL or a directory without a specified index document. A 403 Forbidden error, which is often the context for issues with custom error pages not displaying, indicates a permissions problem or an explicit denial of access, not that the requested resource itself is missing from the bucket. The type of error (403 vs. 404) is distinct.

The error.html object has incorrect permissions.

Why it fails: Although `error.html` must ultimately be accessible for S3 to serve it (typically via a public read bucket policy), incorrect individual object permissions are not the most direct cause for the *custom error page not being displayed* by the static website hosting feature. If permissions were the sole issue, S3 would likely return a generic 403 Forbidden error, indicating a direct access problem. The failure of the custom error page mechanism to even attempt to route to `error.html` points more strongly to a missing or incorrect configuration in the static website hosting settings, rather than just the object's permissions.

Hardcode the key ID in the application code

Why it fails: Hardcoding the KMS Key ID directly into the application's source code is a significant security anti-pattern. This practice embeds sensitive configuration within the codebase, making it visible in version control systems and requiring a full code redeployment for any key rotation or change. It violates the principle of separating configuration from code, increasing the risk of accidental exposure and hindering operational agility.

Store the key ID in a configuration file on the instance

Why it fails: Storing the KMS Key ID in a local configuration file on the EC2 instance, while better than hardcoding, still presents a substantial security vulnerability. If the instance's operating system is compromised through a remote code execution exploit or privilege escalation, an attacker could easily read this file from the filesystem. This method does not protect the key ID from unauthorized access by a malicious actor who gains control of the underlying host.

Retrieve the key ID using the instance's IAM role

Why it fails: An instance's IAM role grants specific permissions to perform AWS API actions, such as kms:Encrypt or kms:Decrypt, on designated KMS keys. However, the IAM role itself does not store or provide the actual KMS Key ID to the application. The application still needs to be explicitly configured with the identifier of the target KMS key to know which key to use for cryptographic operations, even if the IAM role authorizes its usage.

The log group retention policy is set to 0 days.

Why it fails: Setting a CloudWatch Logs retention policy to 0 days is not a valid configuration within AWS. Instead of immediately deleting logs, CloudWatch interprets a 0-day retention as 'never expire,' meaning logs would persist indefinitely. Therefore, if the Lambda function were successfully generating logs, they would still be visible in the log group, contradicting the observation of no logs.

The Lambda function is configured to log to a custom log group.

Why it fails: Even if a Lambda function is configured to use a custom log group, such as by setting the AWS_LAMBDA_LOG_GROUP_NAME environment variable, logs would still be directed and written to that specified group. The problem statement indicates *no logs at all* are appearing, not that logs are missing from the *default* log group. A custom log group configuration would simply change the destination, not prevent logging entirely if permissions were correct.

The Lambda function has reserved concurrency set to 0.

Why it fails: Setting a Lambda function's reserved concurrency to 0 explicitly prevents the function from being invoked by any triggers. This means the function's code would not execute, and consequently, no logs would be generated because the runtime environment is never spun up. The issue would manifest as failed invocations or throttled requests, rather than successful invocations that simply fail to produce logs.

A unit test is failing; fix the test code.

Why it fails: An ECONNRESET error indicates a network connection was forcibly closed by the peer, which is fundamentally different from a unit test failure. Unit tests typically fail due to incorrect code logic or unmet assertions, resulting in specific assertion errors (e.g., 'expected X but got Y') rather than low-level network communication issues. Therefore, fixing test code would not resolve a network reset problem.

The npm cache is corrupted; clear the cache in CodeBuild.

Why it fails: AWS CodeBuild environments are ephemeral, meaning each build starts with a fresh, clean environment. There is no persistent npm cache that could become corrupted and carry over between builds. An ECONNRESET error specifically points to a problem with the network connection itself, not an issue with local cached data, making cache clearing irrelevant.

The npm token has expired; regenerate the token.

Why it fails: An expired or invalid npm token, typically used for authenticating with private package registries, would result in an HTTP 401 Unauthorized error, indicating an authentication failure. An ECONNRESET error, however, is a lower-level TCP error that means the connection was forcibly closed by the peer, pointing to a fundamental network connectivity issue rather than an authentication problem. Regenerating a token would not address a network reset.

Use the Ref function in the ECS service to reference the load balancer.

Why it fails: Using the Ref function in the ECS service to reference the load balancer primarily retrieves the logical ID or a default attribute (like ARN for some resources) of the load balancer. While CloudFormation often infers implicit dependencies from Ref to ensure the referenced resource exists before its value is needed, it does not explicitly guarantee that the referenced resource is fully provisioned and operational before the dependent resource begins its creation. For critical operational readiness, DependsOn is more explicit and reliable.

Define the load balancer before the ECS service in the template.

Why it fails: The order in which resources are declared within a CloudFormation template's Resources section is purely for human readability and template organization. CloudFormation's engine determines the actual resource creation order based on an internal dependency graph, which is primarily built from explicit DependsOn attributes and implicit dependencies inferred from intrinsic functions like Ref or Fn::GetAtt. Without explicit instructions, the engine may attempt concurrent creation or an arbitrary order, leading to potential race conditions.

Use the Fn::GetAtt function to reference the load balancer.

Why it fails: The Fn::GetAtt function is used to retrieve a specific attribute value from a resource, such as the DNSName or CanonicalHostedZoneName of a load balancer. While using Fn::GetAtt creates a data dependency, ensuring the attribute value is available when needed, it does not explicitly enforce the creation order or guarantee that the referenced resource is fully operational before the dependent resource starts. For strict operational sequencing, DependsOn is the appropriate mechanism.

Increase the Lambda function timeout to 10 seconds.

Why it fails: Increasing the Lambda function timeout is the correct solution when an external dependency, such as an API call, occasionally exceeds the default execution limit. AWS Lambda functions have a configurable timeout, with a default of 3 seconds. If an external API call, especially one with variable latency, occasionally takes longer than this default, the Lambda function will be prematurely terminated, leading to invocation failures. Increasing the timeout to 10 seconds allows the function sufficient time to complete the external call and process its response, preventing these intermittent failures.

Increase the Lambda function reserved concurrency.

Why it fails: Increasing the Lambda function reserved concurrency dictates the maximum number of simultaneous executions for a specific Lambda function, preventing it from consuming all available account concurrency. While crucial for performance and resource management, especially during peak loads, reserved concurrency has no bearing on the duration a single function invocation is allowed to run. A function will still time out after its configured duration, regardless of how many concurrent instances are reserved or available for execution.

Increase the Lambda function memory to 1024 MB.

Why it fails: Increasing the Lambda function memory allocation directly impacts its available CPU power and, consequently, its execution speed for CPU-bound tasks. While more memory can reduce the overall execution duration for computationally intensive operations by providing more processing resources, it does not inherently extend the maximum allowed execution time (timeout). The timeout is a distinct configuration that defines the hard limit for how long a function can run, irrespective of its memory setting.

Increase the Lambda function's memory allocation

Why it fails: Increasing a Lambda function's memory allocation primarily impacts its CPU power, network bandwidth, and overall execution duration, allowing it to process data faster or handle larger payloads. However, memory allocation has no direct bearing on the order in which messages are received or processed by downstream services or concurrent invocations. Message ordering is a system-level concern, typically managed by queuing services or specific protocol implementations, not by the compute resource's individual capacity.

Use API Gateway's built-in message ordering feature

Why it fails: Amazon API Gateway, particularly for WebSocket APIs, acts as a managed service for routing messages, handling connection management, authentication, and throttling. While it efficiently manages the bidirectional communication, API Gateway itself does not inherently provide or guarantee message ordering for messages sent through connected clients. It delivers messages as they arrive, and any requirement for strict sequential processing must be implemented by a downstream service or a dedicated queuing mechanism.

Set the 'sequenceNumber' property in the WebSocket message

Why it fails: While including a 'sequenceNumber' property within a WebSocket message can help clients identify and potentially reorder messages on the receiving end, it does not enforce processing order on the server-side. The server would still receive messages out of order and process them asynchronously based on arrival. Relying solely on client-side reordering means the server-side logic might still operate on stale or incorrectly ordered data, which is problematic for real-time applications requiring strict sequential processing.

Increase the reserved concurrency

Why it fails: Increasing reserved concurrency for an AWS Lambda function ensures that a specified number of concurrent executions are always available for that function, preventing throttling due to account-wide or unreserved concurrency limits. However, it does not alter the maximum execution duration for any individual invocation. A function timing out indicates that a single execution exceeds its allowed duration, which is unrelated to how many instances can run simultaneously.

Place the Lambda function in a VPC

Why it fails: Placing an AWS Lambda function within a Virtual Private Cloud (VPC) provides it with access to private resources like Amazon RDS databases or EC2 instances that are not publicly accessible. While VPC configuration can impact network latency or connectivity for external services, it does not inherently modify the function's execution timeout setting. A timeout occurs due to the function's code running longer than permitted, irrespective of its network environment.

Decrease the memory allocation of the Lambda function

Why it fails: Decreasing the memory allocation for an AWS Lambda function is counterproductive when facing timeouts, as memory is directly proportional to the available CPU power. Reducing memory typically leads to a decrease in CPU cycles and overall processing capability, which would likely increase the function's execution time rather than shorten it. This action would exacerbate the timeout issue by making the function run even slower.

The Lambda function is configured with a DLQ that causes retries.

Why it fails: A Dead-Letter Queue (DLQ) in AWS Lambda serves as a destination for messages that a function fails to process successfully after exhausting all configured retries. The purpose of a DLQ is to capture and store failed invocations for later analysis, not to initiate or cause additional retries of successful invocations. Therefore, a DLQ cannot be the source of duplicate successful Lambda function executions, as it only comes into play when processing has already failed and exhausted its retry attempts.

The Lambda function is idempotent and should handle duplicates.

Why it fails: Idempotency is a crucial design pattern where a function produces the same result regardless of how many times it is invoked with the same input, effectively handling duplicates without adverse side effects. While implementing an idempotent Lambda function is a best practice for resilience in serverless architectures, the question specifically asks for the cause of duplicate invocations. This option describes a solution or a desired characteristic of the function, rather than identifying the root technical reason why the duplicate events are being generated and delivered in the first place.

The S3 bucket has multiple event notifications that trigger the same Lambda function.

Why it fails: AWS S3 allows configuring multiple event notifications on a single bucket, each with its own event types (e.g., s3:ObjectCreated:Put, s3:ObjectCreated:*) and optional prefix/suffix filters. If an S3 bucket has two or more distinct notification configurations that are both configured to trigger the same Lambda function and whose filters overlap for a given object event, a single S3 action will result in multiple, identical invocations of that Lambda function. This common misconfiguration is a direct and frequent cause of duplicate processing in serverless applications.

Use the AWS::Lambda::Version resource to create a new version.

Why it fails: The AWS::Lambda::Version resource is used to create an immutable snapshot of a Lambda function's *current* configuration and code, allowing for safe rollbacks and traffic shifting. However, it does not inherently update the underlying function's code itself. To deploy new code, the AWS::Lambda::Function resource's Code property must be modified, which AWS::Lambda::Version does not directly facilitate.

Include the S3 bucket and key as template parameters and update the stack with a new key when code changes.

Why it fails: While changing the S3Key property of the AWS::Lambda::Function resource *would* trigger an update, this approach requires creating a new S3 object with a unique key for every code change. This manual management of distinct S3 object keys is cumbersome and less efficient than leveraging S3's native object versioning capabilities, which automatically track changes to the same object key under a consistent key name.

Use a custom resource backed by a Lambda function that polls S3 for changes.

Why it fails: Implementing a custom CloudFormation resource to poll S3 for code changes introduces unnecessary complexity and operational overhead. CloudFormation already provides a direct and efficient mechanism for detecting Lambda code updates via the S3ObjectVersion property. This custom solution would also be less reactive, potentially introducing deployment delays, and is not idiomatic for this common use case.

The Lambda function will be throttled due to reserved concurrency.

Why it fails: Reserved concurrency in AWS Lambda limits the maximum number of simultaneous executions for a function. While exceeding this limit would lead to throttling of *new* invocations, it does not directly cause existing, in-flight messages to be processed multiple times due to a short visibility timeout. Throttling prevents new work from starting, whereas the scenario described involves a message becoming visible again before its initial processing completes, leading to re-processing.

The Lambda function will process messages successfully with no issues.

Why it fails: This statement is incorrect because a fundamental issue exists when the SQS visibility timeout is shorter than the Lambda function's processing duration. In such a scenario, the message will automatically reappear in the queue before the Lambda function can successfully complete its work and delete the message. This premature re-visibility ensures that the message will be picked up again, leading to duplicate processing rather than successful, issue-free completion.

The Lambda function will automatically increase its processing speed.

Why it fails: AWS Lambda functions execute with a fixed amount of allocated memory and corresponding CPU power, which determines their processing speed. Lambda does not possess an inherent mechanism to automatically increase its processing speed or resource allocation dynamically in response to a message taking too long to process. Any changes to processing speed would require manual configuration adjustments to memory or code optimization, not an automatic system response to a visibility timeout issue.

The Lambda function timed out.

Why it fails: A Lambda timeout typically results in a 504 Gateway Timeout error if invoked via API Gateway, or a Task timed out after X seconds error message in the logs, often accompanied by a 500 Internal Server Error from the Lambda service itself if invoked directly and synchronously. A 200 OK status code, even with a FunctionError header, does not signify a timeout; it indicates the invocation request was successfully processed by the Lambda service, but the function's execution within that request encountered an issue.

The payload was too large for synchronous invocation.

Why it fails: If the invocation payload exceeds the maximum allowed size for synchronous invocation (6 MB for request body), the Lambda service would reject the request *before* attempting to invoke the function. This would typically result in a 413 Request Entity Too Large HTTP status code or a 400 Bad Request with a specific error message indicating the payload size limit was exceeded, not a 200 OK status code with a FunctionError header.

The Lambda function was not found.

Why it fails: If the specified Lambda function does not exist or the invoking principal lacks permissions to access it, the Lambda service would return a 404 ResourceNotFoundException HTTP status code. A 200 OK status code, even with an error header, signifies that the Lambda service successfully located and attempted to invoke the specified function, implying the function itself was found and accessible and the invocation request was valid.

Attach a NAT Gateway to the private subnet and update the route table.

Why it fails: A NAT Gateway allows instances in private subnets to initiate outbound connections to the internet, including public AWS service endpoints. However, the traffic still traverses the public internet to reach CloudWatch, which does not satisfy a requirement for *private* connectivity within the AWS network. This approach introduces an internet egress point, potentially increasing security exposure and data transfer costs.

Install the CloudWatch agent on each instance and configure it to use a proxy.

Why it fails: While the CloudWatch agent is necessary to collect metrics and logs, merely configuring it to use a proxy server does not inherently establish private connectivity to CloudWatch. The proxy itself would still require a network path to CloudWatch, either via the public internet or through an existing private connection like a VPC Endpoint or Direct Connect, which this option does not provide. This solution only intermediates traffic, it doesn't create the private network path.

Attach an Internet Gateway to the VPC and assign public IPs to instances.

Why it fails: Attaching an Internet Gateway to the VPC and assigning public IP addresses to EC2 instances places them in a public subnet, allowing direct internet access. While this enables communication with CloudWatch's public endpoints, it exposes the instances directly to the public internet, which is generally undesirable for security and compliance reasons, especially when private connectivity is preferred or required. This approach bypasses the need for private subnets entirely, sacrificing isolation.

The API Gateway CORS configuration is incorrect; the allowed origin should be set to '*'.

Why it fails: Setting the `Access-Control-Allow-Origin` header to '*' allows requests from any origin, which can resolve CORS issues but is generally not the most secure practice for production environments. However, the root cause of a CORS error is typically the *absence* of the necessary CORS headers in the response, not merely an overly restrictive origin value. If the Lambda function is not returning these headers at all, simply configuring API Gateway with a wildcard origin will not inject them into the Lambda's response, especially in a proxy integration.

The web application is not sending the preflight OPTIONS request.

Why it fails: Web browsers automatically handle the sending of preflight `OPTIONS` requests for 'complex' cross-origin requests, such as those involving non-standard HTTP methods or custom headers. The web application's code does not explicitly initiate this request. Therefore, if a CORS error occurs, it signifies that the browser *did* attempt the necessary CORS handshake, but the server's response (or lack of appropriate CORS headers) failed to satisfy the browser's security policy, rather than the client failing to send the preflight request.

The Lambda function is not returning the CORS headers in the response.

Why it fails: When an AWS Lambda function is integrated with Amazon API Gateway, particularly in a proxy integration, the Lambda function is fully responsible for constructing the complete HTTP response, including all necessary CORS headers such as `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods`, and `Access-Control-Allow-Headers`. If these critical headers are omitted from the Lambda's response, the browser will block the cross-origin request due to security policies, leading directly to a CORS error. For non-proxy integrations, the Lambda must still provide these headers for API Gateway to map them correctly into the final response.