Select Two (Multi-Select) Questions

Encrypt individual tables using MySQL native encryption.

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

Create a new load balancer for the new environment.

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

NetworkReceiveThroughput

Why wrong: NetworkReceiveThroughput measures the incoming network traffic to the RDS instance, typically in bytes per second. While a sustained spike could coincide with heavy read/write activity, it is a throughput metric, not a latency or utilization metric that directly indicates slow query performance. High network throughput alone does not cause slow instance response; it is usually a symptom of large result sets or data transfer patterns, not the root cause of high CPU or query delays.

SwapUsage

Why wrong: SwapUsage is not a standard Amazon RDS metric exposed by CloudWatch for MySQL instances. RDS manages the underlying EC2 host and does not provide direct swap usage; instead, the relevant metric is the FreeableMemory or database-specific memory pressure. Even if swap were occurring, it would be a consequence of memory pressure, not the primary metric for diagnosing a slow MySQL instance, and the question's symptoms point more toward CPU or query efficiency.

FreeStorageSpace

Why wrong: FreeStorageSpace tracks the available disk capacity, but running low on space triggers write operations to block or auto-scaling, not general read latency. Slow query performance is typically caused by resource contention like CPU, memory, or locks, not by free disk space unless the disk is completely full. In the context of a slow MySQL instance, checking FreeStorageSpace would not reveal the most likely cause; it is more relevant for failure prevention than for diagnosing latency.

Use KMS to encrypt the S3 objects

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

Enable versioning.

Why wrong: Enabling versioning on an S3 bucket preserves every version of an object, which helps you recover from accidental overwrites or deletions, but it does not restrict who can read the data. Versioning is a data-integrity and availability feature; it does not add any confidentiality or access-control enforcement, so a malicious actor with read permissions can still retrieve all versions and leak data. In fact, if versioning was previously enabled with permissive ACLs, historical versions can remain accessible even after you tighten current object permissions, making it not a leak-prevention control.

Enable MFA Delete.

Why wrong: MFA Delete requires a user to provide a valid MFA code before deleting an object version or changing the bucket's versioning state, which hardens the bucket against unauthorized deletion by a compromised credential. However, MFA Delete only protects the deletion operation; it does not affect read access in any way, so an attacker with S3:GetObject permissions can still download and exfiltrate data. This control is designed to prevent data loss and tampering, not to prevent data leaks, making it incorrect for a question about protecting against unauthorized disclosure.

Configure cross-region replication.

Why wrong: Cross-region replication (CRR) asynchronously copies every object from the source bucket to a destination bucket in a different AWS Region, which is primarily used for geographic redundancy, disaster recovery, latency optimization, or compliance requirements. It does not change the permissions or encryption on either bucket and, in fact, replicates bucket policies and ACLs—so if the source bucket has a misconfigured public policy, that policy is replicated to the destination, potentially doubling your exposure. CRR is a data-availability feature; it neither detects nor prevents unauthorized read access, so it cannot protect an S3 bucket from data leaks.

Encrypt the messages client-side before sending to SQS.

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

Embed the credentials in the Lambda function code.

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

Store the credentials as Lambda environment variables.

Why wrong: Environment variables can be seen in the Lambda console and are not encrypted by default.

Hardcode the credentials in the Lambda function code.

Why wrong: Hardcoding is insecure and not a best practice.

Store the credentials in a file in the Lambda deployment package.

Why wrong: Storing in the deployment package exposes credentials in the code repository.

Increase the Lambda function timeout.

Why wrong: Increasing the Lambda function timeout only extends the maximum execution duration before Lambda terminates the function; it has no effect on how quickly a request travels through API Gateway or how fast the function itself executes. If the observed latency is due to a slow invocation or network transfer, a higher timeout won't reduce the measured response time—it only prevents a premature timeout. Since the problem is latency, not a function hitting a time limit, this change is ineffective.

Increase the API Gateway throttling limits.

Why wrong: API Gateway throttling limits control the number of requests per second that can hit the backend, protecting it from traffic spikes; they do not influence the round-trip time of any individual successful request. Raising the throttle limit only allows more concurrent or burst requests, and if the Lambda function or API Gateway is already at capacity, a higher limit could increase contention and worsen latency. Therefore, adjusting throttling is a scaling measure, not a performance optimization for per-request response times.

Set the 'IgnoreApplicationStopFailures' flag to true.

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

The user is using an incorrect region endpoint.

Why wrong: Incorrect. Using an incorrect region endpoint results in a different error, not an access denied error.

The S3 bucket is in a different AWS account.

Why wrong: Incorrect. The bucket being in a different AWS account does not inherently cause access denied; cross-account access can be configured.

Enable AWS WAF on the ALB to inspect the header

Why wrong: Incorrect. AWS WAF can inspect headers but cannot execute custom authorization logic; it is rule-based, not decision-based on header content.

Use Amazon Cognito User Pools to validate the header

Why wrong: Incorrect. Amazon Cognito User Pools are used for user authentication via OAuth/OIDC, not for validating arbitrary custom headers.

Configure the ALB to use the Lambda authorizer

Why wrong: Incorrect. ALB does not natively support Lambda authorizers; it can invoke a Lambda as a target but not as an authorizer for access control.

Disable AWS CloudTrail to reduce costs

Why wrong: CloudTrail is essential for auditing, security analysis, and compliance. Disabling it would eliminate the audit trail of API activity, making it impossible to detect unauthorized access, investigate incidents, or meet compliance requirements. Cost should be managed by adjusting trails or data events, not by disabling entirely.

Disable password rotation to avoid user inconvenience

Why wrong: While password rotation can be inconvenient, it's a security best practice that reduces the risk of compromised credentials being used over extended periods. AWS IAM allows custom password policies, but disabling rotation entirely increases the window of exposure for stolen passwords. Modern approaches may favor longer passwords with MFA, but for privileged accounts, rotation remains recommended.

Use the root user for daily administrative tasks

Why wrong: The root user has unrestricted access to all AWS resources and services, including the ability to close the account. AWS recommends creating IAM users with least-privilege permissions for daily tasks and using the root user only for tasks that explicitly require it, like changing account-level settings. Using root daily increases the risk of accidental or malicious critical changes.

Add another primary instance and configure replication.

Why wrong: Amazon RDS for MySQL, particularly in a Multi-AZ configuration, operates with a single primary instance responsible for all write operations. It does not support a multi-master or active-active primary setup where multiple instances can simultaneously accept writes and replicate changes amongst themselves. Attempting to add another primary instance and configure replication would deviate from the standard RDS operational model, leading to unsupported configurations and potential data consistency issues.

Use the Multi-AZ secondary instance endpoint for read queries.

Why wrong: In an Amazon RDS Multi-AZ deployment, the secondary instance serves as a synchronous standby replica, located in a different Availability Zone, solely for high availability and disaster recovery purposes. This secondary instance does not have an accessible endpoint for applications to send read queries and is not designed to serve any traffic. Its only function is to automatically take over as the primary in the event of a failover, making it unavailable for direct application interaction.

Enable Amazon RDS Proxy to distribute read queries across instances.

Why wrong: Amazon RDS Proxy is a fully managed, highly available database proxy that primarily focuses on efficient connection management, including connection pooling and multiplexing, to reduce overhead on the database. While it sits between the application and the database, its core functionality does not include intelligent read/write splitting or distributing read queries across multiple read replicas. RDS Proxy enhances application resilience during failovers and manages connections, but it does not inherently create or manage read-specific endpoints for scaling read operations.

Condition: { "StringLike": { "iam:MFADeviceType": "Virtual" } }

Why wrong: This checks the type of MFA device, not whether MFA was used.

Condition: { "ForAllValues:StringEquals": { "aws:SourceIdentity": "admin" } }

Why wrong: This checks the source identity, not MFA.

Condition: { "StringEquals": { "iam:ResourcePath": "/" } }

Why wrong: This condition checks the resource path, not MFA status.

Make sure the source artifact is a valid zip file containing the application code and environment configuration.

Why wrong: Elastic Beanstalk accepts zip files.

Confirm that the S3 object key does not contain special characters.

Why wrong: S3 keys can contain special characters.

Verify that the S3 bucket name is exactly as specified in the pipeline.

Why wrong: Bucket name is likely correct.

An Amazon ECS cluster

Why wrong: An Amazon ECS cluster is the infrastructure where the ECS service runs, but it is not a required input for the CodeDeploy blue/green deployment configuration itself. The cluster is indirectly referenced through the ECS service that CodeDeploy updates; it does not need to be specified as a separate component in the deployment group or application.

A target tracking scaling policy

Why wrong: Scaling policy is optional, not required for blue/green deployment.

An AWS CloudFormation stack

Why wrong: Incorrect. The CloudFormation stack already exists for the environment; it is not created when adding a database.

An Amazon DynamoDB table

Why wrong: DynamoDB is not a relational database; Elastic Beanstalk uses RDS for relational databases.