Hard Difficulty Questions

Condition with aws:SourceArn

Why wrong: 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 wrong: 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 wrong: 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.

Manually rotate the KMS key every year

Why wrong: Automatic rotation is available and preferred.

Create a new KMS key and update all applications to use it

Why wrong: Manual process, not required.

Use AWS CloudWatch Events to trigger a Lambda function that rotates the key

Why wrong: AWS KMS does not support rotating a customer managed key via a Lambda function; key rotation is an internal KMS operation that can only be enabled or disabled through the key's rotation configuration, not triggered externally. This option is tempting because CloudWatch Events and Lambda are commonly used to automate periodic tasks, and in scenarios requiring custom cryptographic key rotation outside KMS (e.g., for client-side encryption keys), that combination would be the correct approach.

Attach a security group to the API Gateway that only allows traffic from the VPC.

Why wrong: Security groups cannot be attached to API Gateway; they are for VPC resources like EC2 instances. API Gateway is a managed service and does not support security groups.

Create a private API Gateway endpoint and associate it with the VPC.

Why wrong: While a private API Gateway endpoint allows traffic from the VPC, it does not inherently restrict access to only that VPC. A resource policy with a condition on the VPC endpoint is needed to enforce the restriction.

Set up VPC Peering between the VPC and the API Gateway's VPC.

Why wrong: VPC Peering is used to connect two VPCs. API Gateway is not deployed in a VPC, so VPC Peering does not apply here.

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

Why wrong: 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 wrong: 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 wrong: 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.

Enable caching in the Lambda function code

Why wrong: This option is incorrect because 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 wrong: This option is incorrect because 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 CPU threshold is too low; increase the target value to 80%.

Why wrong: A low CPU threshold, such as 20%, for ECS service auto-scaling means that new tasks are launched proactively even with minimal CPU utilization increases. While this might seem beneficial, it primarily affects scaling behavior, not necessarily the root cause of 503 errors which indicate no healthy targets. Increasing the threshold to 80% would make the service less responsive to CPU spikes, potentially leading to more performance degradation and errors if the application is under load, rather than resolving 503s caused by health check issues.

The ALB idle timeout is too low; increase it to 300 seconds.

Why wrong: The ALB idle timeout setting dictates how long the load balancer waits for a response from a registered target or for data from the client before closing the connection. If the idle timeout is too low, long-running requests might be prematurely terminated by the ALB, resulting in HTTP 504 Gateway Timeout errors. This parameter does not directly cause HTTP 503 Service Unavailable errors, which typically indicate that the load balancer found no healthy targets to route the request to, irrespective of connection duration.

The cluster does not have enough EC2 instances; add more instances.

Why wrong: For a containerized web application running on Amazon ECS, if it's utilizing the AWS Fargate launch type, the underlying EC2 instance management is entirely abstracted away. Fargate is a serverless compute engine for containers, meaning users do not provision, patch, or scale EC2 instances. Therefore, suggesting to "add more EC2 instances" is irrelevant and incorrect for a Fargate-based ECS setup, as the capacity is fully managed by AWS.

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

Why wrong: 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 wrong: This option is incorrect because 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 CodeDeploy agent on the instances is not running

Why wrong: If the CodeDeploy agent were not running on the target instances, CodeDeploy would typically report errors such as "AGENT_NOT_INSTALLED" or "AGENT_UNHEALTHY" for those specific instances, indicating a communication failure. The deployment would likely stall or fail for those particular instances, but the overarching deployment error would not be HEALTH_CONSTRAINTS, which specifically relates to the availability of healthy instances during the deployment process itself.

The application revision contains invalid scripts

Why wrong: If the application revision contained invalid scripts, such as syntax errors or incorrect commands in the appspec.yml hooks, CodeDeploy would typically report specific SCRIPT_FAILURE or INSTANCE_FAILURE errors for the affected instances. These errors would detail which script failed and at what lifecycle event, leading to individual instance deployment failures rather than a global HEALTH_CONSTRAINTS error, which implies a broader issue with maintaining the overall fleet's health.

The IAM role for CodeDeploy does not have sufficient permissions

Why wrong: Insufficient permissions for the CodeDeploy service role would manifest as ACCESS_DENIED errors when CodeDeploy attempts to perform actions like reading from S3, interacting with EC2 instances, or updating Auto Scaling groups. These errors would typically occur early in the deployment process, preventing CodeDeploy from even initiating or progressing certain steps, rather than resulting in a HEALTH_CONSTRAINTS error, which specifically relates to the operational health and availability of the target instances during the deployment.

Set the DeletionPolicy attribute to Retain on the database resource.

Why wrong: Setting the DeletionPolicy attribute to Retain on a database resource instructs CloudFormation to preserve the resource when its containing stack is deleted, or when the resource is removed from the template. However, DeletionPolicy does not prevent CloudFormation from replacing a resource during a stack update if a property change requires a new physical resource. If a database property is updated in a way that triggers replacement, CloudFormation will still attempt to create a new database and then delete the old one, unless other update policies are specifically applied.

Use the Parameters section to set a conditional update flag.

Why wrong: The Parameters section in a CloudFormation template is designed to accept input values at stack creation or update time, allowing for template customization without direct modification. While parameters can influence resource properties, they do not inherently provide a mechanism to control or prevent specific update behaviors, such as resource replacement or modification. There is no built-in CloudFormation functionality where a parameter can act as a 'conditional update flag' to alter the update strategy of a resource.

The IAM role does not have a trust policy for EC2.

Why wrong: A trust policy defines which AWS entities are permitted to assume an IAM role. If the EC2 instance were unable to assume the role due to a missing or incorrect trust policy for the `ec2.amazonaws.com` service principal, then *all* attempts to access AWS services using that role, including the successful S3 access, would fail with an `AccessDenied` error. The fact that S3 access works confirms the trust policy is correctly configured for EC2.

The DynamoDB table is in a different region than the EC2 instance.

Why wrong: AWS services like DynamoDB are designed to support cross-region access, provided the application explicitly configures the AWS SDK to target the correct region. If the DynamoDB table were in a different region and the application failed to specify it, the error would typically manifest as a `ResourceNotFoundException` or similar, indicating the table could not be located in the default or specified region, rather than an `AccessDeniedException` related to IAM permissions.

The application is using the wrong AWS SDK.

Why wrong: Using a different or outdated AWS SDK version might lead to issues such as incompatible API calls, serialization errors, or missing features, but it does not fundamentally alter the underlying IAM permissions granted by a role. The SDK's role is to facilitate interaction with AWS services and automatically retrieve credentials from the instance metadata service. Permission failures stem from the IAM policy itself or the role's attachment mechanism, not the SDK version used.

Increase the EC2 instance size to handle the microservices load.

Why wrong: Increasing the EC2 instance size, known as vertical scaling, is a strategy to enhance the capacity of a single server. However, when migrating to a microservices architecture, especially one leveraging container orchestration services like Amazon ECS with AWS Fargate, the underlying EC2 instance size becomes largely irrelevant. Fargate abstracts away the server infrastructure, managing compute capacity automatically, thus making vertical scaling of specific EC2 instances an inappropriate solution for this migration context.

Deploy all microservices in a single ECS service for simplicity.

Why wrong: Deploying all microservices within a single Amazon ECS service fundamentally undermines the core benefits of a microservices architecture. Microservices are designed for independent deployment, scaling, and failure isolation, allowing each component to evolve and operate autonomously. Consolidating them into one service reintroduces tight coupling, creates a single point of failure, and prevents individual scaling based on specific service demands, negating the architectural advantages.

Scale horizontally by adding more EC2 instances.

Why wrong: While horizontal scaling by adding more EC2 instances can improve the availability and performance of an existing monolithic application, it does not directly facilitate a controlled, zero-downtime migration to a new microservices architecture. This approach primarily addresses capacity for the current application rather than providing a mechanism for gradually deploying, testing, and transitioning traffic to new, independently deployable microservices without service interruption.

The Lambda function's concurrency is set too high, causing race conditions.

Why wrong: While a high concurrency setting for a Lambda function can indeed increase the likelihood of race conditions, this issue is distinct from the problem of duplicate event processing. Race conditions occur when multiple concurrent executions attempt to modify shared resources simultaneously, leading to unpredictable or inconsistent states. Duplicate event processing, however, stems from the source (S3) sending the same event multiple times, causing the Lambda function to perform the same logical operation redundantly, irrespective of how many instances run concurrently.

The DynamoDB table does not have a primary key that prevents duplicates.

Why wrong: A DynamoDB table must have a primary key, and it inherently prevents items with identical primary key values from being written. However, if the Lambda function generates a new, unique identifier (e.g., a UUID) for the primary key for each invocation, then even duplicate S3 events will result in separate, unique primary keys being generated and new items being inserted. The problem isn't the absence of a primary key, but rather the lack of a robust idempotency strategy that uses a consistent, event-derived identifier to prevent duplicate writes for the same logical operation.

The S3 bucket is configured with versioning, causing multiple object creation events.

Why wrong: S3 versioning tracks multiple versions of an object and can generate events for actions like creating new versions or deleting objects. While versioning might lead to multiple distinct events for different object states (e.g., s3:ObjectCreated:Put for a new version, then another for an update), it does not inherently cause the same event notification to be delivered multiple times. The fundamental cause of duplicate processing for a single logical S3 action is the "at least once" delivery guarantee of S3 event notifications, which applies regardless of whether versioning is enabled.

Deny effect with a Condition: StringEquals on s3:x-amz-server-side-encryption

Why wrong: The condition key s3:x-amz-server-side-encryption only checks whether encryption is requested (e.g., AES256 or aws:kms), but does not specify which KMS key. Using StringEquals with this key would deny requests that do not use the encryption header, but it would not enforce the use of a specific KMS key.

Allow effect with a Condition: StringEquals on kms:RequestTag/key-id

Why wrong: Service Control Policies (SCPs) primarily function as guardrails, setting maximum permissions. While they can include an Allow effect, it's generally not used to grant permissions but rather to define a baseline or override a higher-level Deny. For enforcing a specific configuration like KMS key usage, a Deny is the correct and robust approach to prevent non-compliant actions. Furthermore, the kms:RequestTag/key-id condition key is designed for KMS API calls to check tags on the request itself, not for S3 PutObject operations, which use S3-specific encryption headers. This SCP would therefore be ineffective and misconfigured for the stated goal.

Deny effect with a Condition: IpAddress on aws:SourceIp

Why wrong: The aws:SourceIp condition key is used to restrict or allow access to AWS resources based on the originating IP address of the request. While this is a valuable control for network-based access, it has no bearing on the server-side encryption method or the specific KMS key used for S3 objects. Applying this condition would only control *who* can upload objects based on their network location, completely failing to address the requirement of enforcing a specific KMS key for encryption.

Use async HTTP calls with a callback

Why wrong: Employing asynchronous HTTP calls with a callback mechanism allows the Lambda function to initiate external requests without blocking its execution thread. This non-blocking I/O pattern enables the function to potentially handle other tasks or simply not consume billed compute time while awaiting the external service's response. Once the response is received, the callback function is invoked to process the results, significantly reducing the overall execution duration for I/O-bound operations and preventing timeouts.

Increase the function's timeout to 60 seconds

Why wrong: Increasing the function's timeout merely extends the maximum allowable execution duration, acting as a temporary fix rather than an optimization. While it might prevent premature termination, it does not accelerate the underlying slow external HTTP calls or improve the function's efficiency. This approach can lead to higher AWS costs, as the function is billed for the entire duration it is active, even if it's idly waiting for a slow external dependency.

Increase the SQS visibility timeout to 60 seconds

Why wrong: Increasing the SQS visibility timeout to 60 seconds controls how long a message remains hidden from other consumers after it has been received by one. This setting is crucial for preventing duplicate processing in case a consumer fails before deleting a message, but it has no direct impact on the Lambda function's execution performance or its ability to complete external HTTP calls within its own configured timeout. It is a queue-level setting unrelated to the compute duration of the function itself.

Add a test stage in the pipeline and configure a 'branch' filter on the source action to only trigger for the development branch.

Why wrong: This is the recommended approach. The source action's 'Branch' field can be set to 'development', so the pipeline only executes when changes are pushed to that branch. The test stage will then run as part of that execution.

Add a test stage in the pipeline and configure a 'branch' condition on the test action using a Lambda function.

Why wrong: CodePipeline does not support configuring 'branch' conditions directly on individual actions within a stage using a Lambda function as a conditional gate. While a Lambda function can be invoked as an action itself, it cannot act as a pre-condition to conditionally execute *another* action based on source branch metadata. Implementing such logic would require the Lambda to perform the conditional check and then potentially trigger or skip subsequent actions via AWS SDK calls, which is an overly complex and non-standard pattern for this requirement.

Add a test stage in the pipeline and use a 'Manual approval' action that requires a human to verify the branch.

Why wrong: Using a 'Manual approval' action to verify the branch is an inefficient and inappropriate solution for automatically limiting pipeline execution to a specific branch. Manual approvals are designed for human gatekeeping before critical deployments, not for automated branch-based filtering. This approach would require constant human intervention for every change, negating the benefits of automation and failing to automatically restrict pipeline runs to only the development branch.

Use a custom key store with automatic rotation enabled.

Why wrong: Custom key stores integrate AWS KMS with an external key manager, such as AWS CloudHSM or an external key management system. Since the cryptographic key material for KMS keys within a custom key store is generated and managed outside of AWS KMS's direct control, AWS cannot automatically rotate this material. Therefore, automatic key rotation is not a supported feature for KMS keys residing in custom key stores, requiring manual management of key material lifecycle.

Use a key with imported key material and set a rotation period of 365 days.

Why wrong: When a customer managed key (CMK) uses imported key material, the user is responsible for generating the cryptographic material outside of AWS KMS and then importing it. Because AWS KMS does not generate or control the source of this key material, it cannot automatically create new material for rotation. Consequently, automatic key rotation is not supported for CMKs with imported key material, necessitating a manual process of creating new keys and updating applications to achieve rotation.

Use a customer managed key with automatic rotation enabled.

Why wrong: Customer managed keys can be rotated automatically, but the default rotation period is 365 days, same as AWS managed keys. However, the question does not specify custom control, and AWS managed keys are simpler for this requirement.

Change the deployment configuration to 'CodeDeployDefault.AllAtOnce'.

Why wrong: Changing the deployment configuration to 'CodeDeployDefault.AllAtOnce' only alters the deployment strategy, causing all instances to be updated simultaneously instead of in batches. While this might speed up the overall deployment process if successful, it does not address the fundamental issue of a failing install_dependencies.sh script. The script would still encounter the same errors on every instance, leading to a complete deployment failure across the entire group, making this configuration change irrelevant to resolving script execution problems.

Reinstall the CodeDeploy agent on the failed instance.

Why wrong: Reinstalling the CodeDeploy agent is unnecessary because the agent successfully executed the install_dependencies.sh script and accurately reported its failure. This indicates the agent itself is operational and communicating correctly with the CodeDeploy service. Agent issues typically manifest as an inability to start deployments, communicate status, or execute any scripts at all, rather than specific script failures. Therefore, reinstalling the agent would not resolve an error within the application's deployment script.

Increase the number of EC2 instances in the deployment group.

Why wrong: Increasing the number of EC2 instances in the deployment group would only scale out the problem, not resolve it. If the install_dependencies.sh script contains errors, every new instance added to the deployment group would attempt to execute the same flawed script during its deployment lifecycle. Consequently, all these additional instances would also fail their deployments, leading to a larger number of unsuccessful deployments without addressing the underlying script issue. This action would waste resources and time without achieving a successful application deployment.

Add a manual approval step between the backend and frontend pipelines.

Why wrong: Adding a manual approval step between separate backend and frontend pipelines introduces significant human latency and potential for error, directly contradicting the goals of automated CI/CD for rapid, reliable deployments. While it enforces order, it transforms an automated process into a manual gate, slowing down release cycles and increasing operational overhead, which is inefficient for frequently updated microservices.

Create a single pipeline that deploys both services simultaneously by updating both ECS services in a single CodeDeploy deployment.

Why wrong: Creating a single CodeDeploy deployment to update multiple ECS services simultaneously does not guarantee the necessary deployment order or atomicity for interdependent microservices. CodeDeploy would attempt to update both services concurrently, meaning the frontend could begin deploying before the backend is fully updated, stable, and available. This approach lacks the sequential execution and dependency validation required to prevent service disruption.

Configure the frontend pipeline to trigger after the backend pipeline completes using Amazon CloudWatch Events.

Why wrong: Configuring the frontend pipeline to trigger via Amazon CloudWatch Events after the backend pipeline completes ensures sequential execution, but it does not guarantee the backend service is fully healthy and stable before the frontend deployment starts. 'Completion' of a pipeline typically signifies the deployment process has finished, not necessarily that the new application version is fully operational and passing all health checks, potentially leading to the frontend deploying against an unstable backend.