Select Two (Multi-Select) Questions

AWS CloudFormation

Why it fails: AWS CloudFormation is an Infrastructure as Code (IaC) service used for provisioning and managing AWS resources through declarative templates. While it can define the infrastructure *on which* applications are deployed, it does not directly deploy application code itself; its primary function is to create, update, and delete AWS services like EC2 instances, not to push application binaries to them.

AWS OpsWorks

Why it fails: AWS OpsWorks provides configuration management services using Chef and Puppet to automate server configuration, software installation, and application deployment. While it can deploy applications as part of its lifecycle management, its core strength lies in managing the operational configuration of instances and applications, rather than being a dedicated, streamlined service solely for automated code deployment like CodeDeploy or Elastic Beanstalk.

AWS CodeBuild

Why it fails: AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs unit tests, and produces deployable artifacts. It is a build service designed to process code *before* deployment, transforming raw source into executable packages or container images. CodeBuild does not perform the actual deployment of these artifacts to target environments.

Dockerfile

Why it fails: A `Dockerfile` is essential for defining the environment and dependencies of a containerized application when deploying to an Elastic Beanstalk Docker environment. However, it primarily specifies how to build the application's image, not the general deployment process or instance configuration for non-Docker platforms. It does not provide mechanisms for configuring AWS resources or executing lifecycle hooks directly within Elastic Beanstalk's deployment pipeline.

appspec.yml

Why it fails: The `appspec.yml` file is a core component of AWS CodeDeploy, defining the source files, permissions, and lifecycle event hooks for deploying an application revision to target instances. While CodeDeploy can be integrated with Elastic Beanstalk, `appspec.yml` is not directly used by Elastic Beanstalk's native deployment process for application bundles. Elastic Beanstalk manages its own deployment orchestration without requiring this specific CodeDeploy artifact.

buildspec.yml

Why it fails: A `buildspec.yml` file is specifically designed for AWS CodeBuild projects, outlining the commands and phases required to build source code, run tests, and produce artifacts. It dictates how an application is compiled or packaged, rather than how it is deployed to an environment. Elastic Beanstalk expects a pre-built application source bundle for deployment and does not directly interpret or execute `buildspec.yml` during its deployment workflow.

Encrypt individual tables using MySQL native encryption.

Why it fails: While MySQL does offer native table-level encryption features, such as InnoDB tablespace encryption, this approach is distinct from Amazon RDS encryption at rest. RDS encryption at rest operates at the storage volume level, encrypting the entire underlying data store, including all tables, indexes, and logs, rather than requiring individual table configuration. Therefore, relying solely on native MySQL table encryption would not fulfill the requirement for comprehensive RDS data at rest encryption.

Enable encryption at rest after the DB instance is created.

Why it fails: Amazon RDS does not allow enabling encryption at rest on an existing, unencrypted DB instance directly. The encryption status is a fundamental property of the underlying storage volume established at creation. To encrypt an unencrypted RDS instance, a new encrypted DB instance must be created, and data migrated from the unencrypted instance, typically via a snapshot copy and restore process, or logical replication.

Use client-side encryption to encrypt data before sending to RDS.

Why it fails: Client-side encryption involves encrypting data within the application before it is transmitted to the database. While a valid security practice for data in transit and potentially for specific sensitive fields, it is a separate mechanism from Amazon RDS encryption at rest. RDS encryption at rest specifically secures the data stored on the underlying storage volume, automated backups, and snapshots, independent of how the data was encrypted before being written to the database.

Check the stack outputs.

Why it fails: Stack outputs are values defined in the Outputs section of the template, and CloudFormation only populates them after the stack has been successfully created or updated. If the stack creation failed, the stack never reaches a complete state, so no Outputs are available in the console or via DescribeStacks. Therefore, checking outputs offers zero diagnostic value for a failed creation.

Delete the stack and recreate it with the same parameters.

Why it fails: Deleting the failed stack triggers CloudFormation to clean up any resources that were created, which also discards the stack events and the rollback history that contained the failure reasons. Recreating with identical parameters will almost certainly reproduce the same failure, and you'll be no closer to identifying the root cause. The correct pattern is to inspect stack events and template logic before any destructive action.

Check AWS CloudTrail logs for the stack creation attempt.

Why it fails: AWS CloudTrail records the underlying API calls that CloudFormation makes on your behalf (for example, ec2:RunInstances or iam:CreateRole), but it does not include CloudFormation-specific resource status reasons or stack-level error messages. To understand why a particular resource failed, you need the statusReason found in the stack events, not the raw AWS API logs. CloudTrail is useful for auditing who triggered the stack operation, not for diagnosing mostly internal CloudFormation resource failures.

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.

Create a new load balancer for the new environment.

Why it fails: Creating a brand-new load balancer for the green environment is unnecessary because the existing ALB can already route to multiple target groups. A new ALB would introduce a separate DNS endpoint, forcing clients or aliases to change and adding operational overhead. Blue/green should reuse the same front end and simply adjust listener rules or weighted target groups to shift traffic to the new Auto Scaling group.

Update the existing Auto Scaling group with the new application version.

Why it fails: Updating the existing Auto Scaling group to the new application version is an in-place or rolling update, not blue/green. The same ASG, launch template, target group, and instances are mutated, so the old environment is destroyed before the new build is validated. If the new version is unhealthy, you cannot instantly roll back to a separate old environment; you would have to redeploy, causing longer downtime.

Terminate the old EC2 instances immediately after deploying the new ones.

Why it fails: Terminating the old EC2 instances immediately after the new ones are deployed destroys the rollback path before the new environment has proven stable. During cutover, if the new target group fails health checks or produces errors, the old instances are gone and the application becomes unavailable. Blue/green keeps the old fleet running until traffic has been fully shifted and the new environment is verified.

AWS IAM

Why it fails: AWS IAM manages users, groups, roles, and permission policies to control who can perform which actions on which resources; it has no role in encrypting object bytes at rest and is unrelated to S3's server-side encryption mechanisms.

AWS Certificate Manager (ACM)

Why it fails: ACM issues and manages TLS certificates for data in transit; it does not encrypt S3 objects at rest. It is tempting because ACM is an AWS security service often paired with S3 static website endpoints, but server-side encryption is provided by SSE-S3, SSE-KMS, or SSE-C instead.

AWS CloudHSM

Why it fails: AWS CloudHSM provisions dedicated, single-tenant hardware security modules primarily used for custom cryptographic operations and generating KMS custom key stores; it is not one of S3's supported server-side encryption options (SSE-S3, SSE-KMS, SSE-C) for encrypting objects at rest.

Use KMS to encrypt the S3 objects

Why it fails: While encrypting S3 objects with AWS Key Management Service (KMS) is a robust security measure for data at rest, it is not a prerequisite for an EC2 instance to access those objects. The ability to retrieve an S3 object is governed by the IAM permissions granted to the accessing entity, not by the encryption method used. KMS encryption primarily protects data confidentiality, not the authorization to access it.

Configure an S3 bucket policy allowing the role

Why it fails: An S3 bucket policy is typically employed for cross-account access scenarios, to grant public access, or to define permissions for specific AWS services not directly associated with an IAM role. When the EC2 instance and the S3 bucket reside within the same AWS account, the permissions granted directly to the IAM role attached to the EC2 instance are sufficient for access, rendering a separate S3 bucket policy redundant and unnecessary for this specific use case.

Create an instance profile and assign a key pair

Why it fails: An instance profile is an AWS container for an IAM role that allows an EC2 instance to assume that role, and it is automatically created when an IAM role is assigned to an EC2 instance. Assigning a key pair, however, is solely for establishing secure SSH access to the EC2 instance itself and has no bearing on the instance's permissions to interact with other AWS services like S3. These are distinct security mechanisms serving different purposes.

Hardcode the credentials in the container image.

Why it fails: Hardcoding credentials in the image embeds them in every layer and registry copy, exposing them to anyone who can pull the image and preventing rotation without a rebuild. It is tempting because it requires no runtime configuration, and would only be acceptable for throwaway local test images with no real secrets.

Define environment variables in the task definition with the credentials.

Why it fails: Plain environment variables in the task definition are visible in the console, API responses and container inspection, so credentials are not securely passed. It is tempting because environment variables are the simplest way to inject configuration, and would suit non-sensitive values such as region or log level.

CloudFront cache policy

Why it fails: CloudFront cache policies govern edge caching behaviour, not the KMS key policy or IAM permissions that authorise cross-account decryption of SSE-KMS objects. They become relevant when tuning TTLs and forwarded headers for a distribution, which is unrelated to the AccessDenied error here.

Route 53 resolver rule policy

Why it fails: Route 53 Resolver rules control DNS forwarding between hybrid networks, not S3 object authorisation. They would be the right focus when resolving on-premises DNS names through a Resolver endpoint, but the AccessDenied stems from the KMS key policy and the S3 bucket policy.

Encrypt the messages client-side before sending to SQS.

Why it fails: Client-side encryption would protect data in transit and at rest outside SQS, but the requirement is specifically for encryption at rest *within SQS*. SQS’s server-side encryption (SSE) using KMS handles this automatically; client-side encryption is unnecessary and adds complexity. It is tempting because client-side encryption is a valid approach for end-to-end confidentiality when the service itself cannot be trusted to encrypt, but here SQS supports native at-rest encryption, making client-side encryption an overengineered solution that does not satisfy the stated requirement.

Store the messages in an S3 bucket with default encryption instead of using SQS.

Why it fails: Storing messages in an S3 bucket fundamentally alters the application's architecture from a message queueing system to an object storage solution. Amazon SQS provides managed queueing semantics like message visibility timeouts, FIFO ordering, and dead-letter queues, which are essential for decoupling microservices and reliable asynchronous communication. S3, while offering default encryption for objects at rest, lacks these queueing features and would require significant custom development to replicate SQS's functionality, making it an unsuitable replacement for a messaging application.

Use AWS CloudHSM to generate and store the encryption keys.

Why it fails: AWS CloudHSM provides dedicated hardware security modules (HSMs) for generating and storing encryption keys, offering FIPS 140-2 Level 3 validated security. However, Amazon SQS Server-Side Encryption (SSE) is natively integrated with AWS Key Management Service (KMS) for key management, not directly with CloudHSM. While KMS can optionally use CloudHSM as a custom key store, SQS's direct SSE integration is with KMS itself. Therefore, attempting to use CloudHSM directly for SQS message encryption at rest is not a supported or feasible configuration.

The bucket is in a different region than the user's default region.

Why it fails: While S3 buckets are provisioned within a specific AWS region, IAM permissions are evaluated globally across all regions where a principal might attempt to access resources. The region where a user's default settings are configured, or the region where the S3 bucket resides, does not inherently restrict or deny IAM permissions for S3 actions like s3:ListBucket. Access is determined solely by the applicable IAM and resource policies, irrespective of regional differences.

The bucket is encrypted with AWS KMS.

Why it fails: AWS KMS encryption primarily protects the data at rest within S3 objects, encrypting the object content itself. However, the s3:ListBucket action is a bucket-level permission that allows an IAM principal to view the metadata of objects within a bucket, such as their names and sizes, but not their actual encrypted content. Therefore, KMS encryption on the objects does not inherently prevent or deny the ability to list the contents of the bucket.

Embed the credentials in the Lambda function code.

Why it fails: Embedding credentials directly within the Lambda function's source code is a severe security vulnerability. These credentials would be committed to version control, making them accessible to anyone with repository access and difficult to rotate without code changes and redeployments. This practice significantly increases the risk of unauthorized access if the code repository is compromised or if the function's deployment package is inspected.

Store the credentials in the buildspec.yml file in the CodeCommit repository.

Why it fails: Storing sensitive credentials directly within the buildspec.yml file, which resides in a CodeCommit repository, is highly insecure. This action permanently embeds the secrets into the repository's history, making them visible to anyone with read access to the repository, including past versions. Such exposure makes credential rotation extremely difficult and poses a significant data breach risk.

Pass the credentials as CloudFormation parameters during deployment.

Why it fails: Passing sensitive credentials as plain-text CloudFormation parameters during deployment is an insecure practice. While parameters can be used for configuration, they are visible in the CloudFormation console, API calls, and logs, exposing the secret value to anyone with permissions to view stack details. CloudFormation parameters are not designed for secure secret management and lack encryption at rest or in transit for sensitive data.

Set the '--on-failure' parameter to 'ROLLBACK' during stack update.

Why it fails: The '--on-failure' parameter is specifically designed to control the behavior of CloudFormation during stack *creation* if an error occurs, dictating whether the stack rolls back, deletes, or remains in a failed state. It has no applicability or effect on stack *update* operations. Stack updates utilize different mechanisms for managing failures and rollbacks, making this parameter irrelevant for enabling automatic rollback during an update.

Use a change set to review the changes before updating.

Why it fails: Using a change set provides a crucial preview of how proposed modifications will affect a CloudFormation stack's resources before the update is executed. It allows developers to review and understand the impact of changes, helping to prevent unintended resource modifications or deletions. However, a change set is purely a planning and review tool; it does not inherently enable or trigger any automatic rollback functionality during or after the stack update process.

Apply a stack policy that denies updates to critical resources.

Why it fails: Applying a stack policy is a security and governance measure that defines explicit permissions for update actions on specific resources within a CloudFormation stack. Its primary purpose is to protect critical resources from accidental or unauthorized modifications by denying certain update operations. While it safeguards resources, a stack policy does not provide any mechanism for automatically rolling back a stack in response to deployment failures or operational issues.

Set the 'IgnoreApplicationStopFailures' flag to true.

Why it fails: Setting the 'IgnoreApplicationStopFailures' flag to true instructs CodeDeploy to proceed even if the ApplicationStop lifecycle event script fails. While it prevents the deployment from halting due to this specific error, it does not address the underlying issue. An application that fails to stop cleanly might leave resources locked, ports in use, or processes running, which can prevent the new application version from starting correctly or lead to an inconsistent state, ultimately causing service disruption and failing to prevent downtime.

Use an 'AllAtOnce' deployment configuration.

Why it fails: Using an 'AllAtOnce' deployment configuration directly contradicts the goal of preventing downtime. This configuration instructs CodeDeploy to update all target instances within the deployment group simultaneously. During this process, every instance will be taken offline as the old application is stopped and the new one is installed and started. This results in a complete service interruption across all instances, leading to significant and unavoidable downtime for end-users.

Install the CodeDeploy agent on each instance.

Why it fails: Installing the CodeDeploy agent on each instance is a fundamental prerequisite for CodeDeploy to function, as it enables the instance to receive and execute deployment commands. However, merely having the agent installed does not inherently implement strategies to prevent downtime. The agent facilitates the deployment process itself, but achieving zero-downtime requires additional configurations like load balancers, specific deployment configurations (e.g., 'OneAtATime', 'HalfAtATime'), and traffic shifting mechanisms.

Create an IAM user policy that denies s3:GetObject for anonymous users.

Why it fails: Creating an IAM user policy that denies s3:GetObject for anonymous users is ineffective because IAM user policies are designed to control permissions for specific IAM identities (users, groups, roles). Anonymous users, by definition, do not possess an IAM identity to which such a policy could be attached or applied. To control access for anonymous users, a bucket policy must be used, as it applies directly to the S3 resource itself.

Enable versioning on the bucket.

Why it fails: Enabling versioning on an S3 bucket is a data durability feature that preserves multiple versions of an object, protecting against accidental deletions or overwrites. While crucial for data recovery and integrity, versioning has no impact whatsoever on the access control mechanisms governing who can read, write, or delete objects within the bucket. It is entirely separate from permissions management.

Enable default encryption on the bucket.

Why it fails: Enabling default encryption on an S3 bucket ensures that all new objects uploaded are encrypted at rest, enhancing data security and compliance. However, encryption is a data protection measure that scrambles data to prevent unauthorized viewing if storage is compromised; it is not an access control mechanism. An encrypted object can still be publicly accessible if the bucket policy or ACL permits it, as encryption does not restrict who can retrieve the object.

Increase the read capacity units (RCU) to 2000.

Why it fails: Increasing Read Capacity Units (RCU) primarily addresses throttling issues, where requests are rejected because the provisioned throughput is exceeded. If the table is merely 'slow' due to high latency per request rather than throttling, simply increasing RCU will not inherently reduce the individual request latency. It would only increase cost without improving the response time for each read operation.

Add a Global Secondary Index (GSI) on the frequently read attribute.

Why it fails: Adding a Global Secondary Index (GSI) allows for querying data using an alternate key, enabling new access patterns. However, it does not inherently speed up existing read operations on the base table's primary key. Furthermore, maintaining a GSI adds write overhead to the main table and can introduce eventual consistency considerations for queries against the index, potentially increasing overall complexity and not directly solving 'slow' reads on the primary key.

Decrease the write capacity units (WCU) to 250.

Why it fails: Decreasing Write Capacity Units (WCU) only impacts the rate at which data can be written to the DynamoDB table. This action has no direct or indirect effect on the performance, latency, or throughput of read operations. Read and write capacities are provisioned and consumed independently, meaning a change to WCU will not alleviate slow read performance.

Attach an IAM policy to all IAM users in each account that denies unencrypted operations.

Why it fails: Attaching IAM policies to individual IAM users within each account is insufficient because it only restricts those specific users and does not apply to service roles, the root user, or other principals. Furthermore, IAM policies primarily control *who can perform an action*, not necessarily *how the action is performed* (e.g., forcing encryption on *all* PutObject requests without explicit bucket policies). This approach would require extensive, decentralized management across numerous accounts and still leave many potential vectors for non-compliant S3 operations.

Enable AWS CloudTrail to log all S3 API calls and send alerts.

Why it fails: While AWS CloudTrail is essential for auditing and monitoring API activity, logging S3 API calls and sending alerts is a reactive measure that detects non-compliant actions *after* they have occurred. CloudTrail provides visibility into who did what, when, and from where, but it does not inherently prevent users or services from performing unencrypted operations or creating non-compliant buckets. Therefore, it cannot enforce encryption settings or prevent public access proactively; it only notifies of violations post-facto.

Use AWS Trusted Advisor to check for unencrypted buckets.

Why it fails: AWS Trusted Advisor provides recommendations and best practice checks, including identifying unencrypted S3 buckets, but it is a diagnostic tool that offers advice rather than enforcement. It performs periodic checks and highlights potential issues, but it does not have the capability to prevent the creation of non-compliant resources or automatically remediate existing ones. Relying solely on Trusted Advisor would require manual intervention to address each identified issue, making it unsuitable for automated, organization-wide enforcement.

Change the deployment configuration to AllAtOnce.

Why it fails: Changing the deployment configuration to `AllAtOnce` merely alters the strategy by which CodeDeploy attempts to deploy to all instances simultaneously, rather than in batches. This modification does not address underlying issues such as a misconfigured agent, incorrect application revision, or permission problems that prevent *any* successful deployment. If a fundamental issue exists, deploying to all instances at once will simply result in all instances failing simultaneously, offering no diagnostic benefit.

Verify that the EC2 instance has an IAM role that allows CodeDeploy to access it.

Why it fails: The IAM role attached to an EC2 instance (instance profile) grants permissions for the CodeDeploy agent running *on* that instance to communicate with the AWS CodeDeploy service and other AWS services, such as S3 for fetching revisions. CodeDeploy itself, as a service, uses a separate service role to interact with EC2 instances (e.g., to tag them or manage Auto Scaling groups). This option incorrectly implies CodeDeploy needs an instance role to 'access' the instance, rather than the agent on the instance needing permissions to interact with the CodeDeploy service.

Increase the health check grace period on the Auto Scaling group.

Why it fails: The health check grace period in an Auto Scaling group is designed to provide newly launched instances sufficient time to initialize and pass their Elastic Load Balancer (ELB) or EC2 status checks before the Auto Scaling group considers them unhealthy. This setting is unrelated to CodeDeploy's internal deployment process or its ability to successfully deploy an application revision to an instance. CodeDeploy manages its own health checks and lifecycle hooks during a deployment, independent of the ASG's health check grace period.

Amazon S3 Transfer Acceleration

Why it fails: Amazon S3 Transfer Acceleration is a feature designed to speed up data transfers to and from S3 buckets over long distances. It achieves this by routing data through CloudFront's globally distributed edge locations, optimizing network paths. This service focuses solely on improving data transfer performance and has no functionality related to user authentication, authorization, or the provision of temporary AWS credentials for mobile applications.

AWS Identity and Access Management (IAM)

Why it fails: AWS IAM is the service for securely managing access to AWS services and resources, primarily through long-term credentials like IAM user access keys or roles. While IAM defines the permissions, directly embedding or distributing IAM user credentials within a mobile application is a severe security vulnerability. Mobile applications require temporary, short-lived credentials with specific, limited permissions, which IAM users do not inherently provide for end-users.

AWS Key Management Service (KMS)

Why it fails: AWS Key Management Service (KMS) is a managed service that makes it easy to create and control encryption keys used to encrypt your data. KMS is primarily focused on cryptographic operations, such as generating, storing, and managing symmetric and asymmetric encryption keys. It does not provide any mechanism for authenticating application users or issuing temporary security credentials for accessing AWS services; its role is purely data protection through encryption.