Correct option:

Use the SQS Extended Client - To manage large Amazon Simple Queue Service (Amazon SQS) messages, you can use Amazon Simple Storage Service (Amazon S3) and the Amazon SQS Extended Client Library for Java. This is especially useful for storing and consuming messages up to 2 GB. Unless your application requires repeatedly creating queues and leaving them inactive or storing large amounts of data in your queues, consider using Amazon S3 for storing your data.

Incorrect options:

Use the MultiPart API - This is an incorrect statement. There is no multi-part API for Amazon Simple Queue Service.

Get a service limit increase from AWS - While it is possible to get service limits extended for certain AWS services, AWS already offers Extended Client to deal with queues that have larger messages.

Use gzip compression - You can compress the messages before sending them to the queue. The messages also need to be encoded after this to cater to SQS message standards. This adds bulk to the messages and will not be an optimal solution for the current scenario.

Reference:

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-s3-messages.html

A. Enable the automated backup feature of Amazon RDS in a multi-AZ deployment that creates backups in a single AWS Region

[+] Automated Backups: Automated backups ensure that your data is regularly backed up and can be restored to any point in time within the backup retention period.

[+] Multi-AZ Deployment: Multi-AZ deployment improves availability and fault tolerance by automatically failing over to a standby instance in another Availability Zone in the same region, providing high availability.

D. Use cross-Region Read Replicas

[+] Cross-Region Read Replicas: Cross-region read replicas provide disaster recovery capabilities by replicating your database to another AWS region. In the event of a regional outage, you can promote the read replica to be the primary database, ensuring continuity of service.

Why Other Options Are Less Suitable:

B. Use database cloning feature of the RDS DB cluster: Database cloning is useful for creating copies of your database for development, testing, or analytical purposes, but it does not provide disaster recovery capabilities.

C. Use RDS Provisioned IOPS (SSD) Storage in place of General Purpose (SSD) Storage: Provisioned IOPS improves the performance of your database by providing faster and more consistent I/O, but it does not contribute to disaster recovery.

E. Enable the automated backup feature of Amazon RDS in a multi-AZ deployment that creates backups across multiple Regions: Automated backups are tied to a single region. Cross-region backups are not directly supported by the automated backup feature; instead, cross-region read replicas should be used for disaster recovery.

Summary:

Enabling automated backups in a multi-AZ deployment ensures high availability and point-in-time recovery within the same region. Using cross-region read replicas enhances disaster recovery by providing the capability to failover to a different region in case of a regional disaster.

Correct option:

Create a custom metric in CloudWatch and make your instances send data to it using PutMetricData. Then, create an alarm based on this metric - You can create a custom CloudWatch metric for your EC2 Linux instance statistics by creating a script through the AWS Command Line Interface (AWS CLI). Then, you can monitor that metric by pushing it to CloudWatch.

You can publish your own metrics to CloudWatch using the AWS CLI or an API. Metrics produced by AWS services are standard resolution by default. When you publish a custom metric, you can define it as either standard resolution or high resolution. When you publish a high-resolution metric, CloudWatch stores it with a resolution of 1 second, and you can read and retrieve it with a period of 1 second, 5 seconds, 10 seconds, 30 seconds, or any multiple of 60 seconds.

High-resolution metrics can give you more immediate insight into your application's sub-minute activity. But, every PutMetricData call for a custom metric is charged, so calling PutMetricData more often on a high-resolution metric can lead to higher charges.

Incorrect options:

Create a custom alarm for your ASG and make your instances trigger the alarm using PutAlarmData API - This solution will not work, your instances must be aware of each other's RAM utilization status, to know when the average RAM would be too high to trigger the alarm.

Enable detailed monitoring for EC2 and ASG to get the RAM usage data and create a CloudWatch Alarm on top of it - By enabling detailed monitoring you define the frequency at which the metric data has to be sent to CloudWatch, from 5 minutes to 1-minute frequency window. But, you still need to create and collect the custom metric you wish to track.

Migrate your application to AWS Lambda - This option has been added as a distractor. You cannot use Lambda for the given use-case.

References:

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html

https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html#CloudWatchAlarm

Correct option:

Use ElastiCache to improve latency and throughput for read-heavy application workloads

Use ElastiCache to improve performance of compute-intensive workloads

Amazon ElastiCache allows you to run in-memory data stores in the AWS cloud. Amazon ElastiCache is a popular choice for real-time use cases like Caching, Session Stores, Gaming, Geospatial Services, Real-Time Analytics, and Queuing.

via - https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/elasticache-use-cases.html

Amazon ElastiCache can be used to significantly improve latency and throughput for many read-heavy application workloads (such as social networking, gaming, media sharing, and Q&A portals) or compute-intensive workloads (such as a recommendation engine) by allowing you to store the objects that are often read in the cache.

Overview of Amazon ElastiCache features:

via - https://aws.amazon.com/elasticache/features/

Incorrect options:

Use ElastiCache to improve latency and throughput for write-heavy application workloads - As mentioned earlier in the explanation, Amazon ElastiCache can be used to significantly improve latency and throughput for many read-heavy application workloads. Caching is not a good fit for write-heavy applications as the cache goes stale at a very fast rate.

Use ElastiCache to improve performance of Extract-Transform-Load (ETL) workloads - ETL workloads involve reading and transforming high volume data which is not a good fit for caching. You should use AWS Glue or Amazon EMR to facilitate ETL workloads.

Use ElastiCache to run highly complex JOIN queries - Complex JSON queries can be run on relational databases such as RDS or Aurora. ElastiCache is not a good fit for this use-case.

References:

https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/elasticache-use-cases.html

https://aws.amazon.com/elasticache/features/

Correct option:

"Save the S3 key for each user's profile photo in a DynamoDB table and use a lambda function to dynamically generate a pre-signed URL. Reference this URL for display via the web application"

On Amazon S3, all objects by default are private. Only the object owner has permission to access these objects. However, the object owner can optionally share objects with others by creating a pre-signed URL, using their own security credentials, to grant time-limited permission to download the objects.

You can also use an IAM instance profile to create a pre-signed URL. When you create a pre-signed URL for your object, you must provide your security credentials, specify a bucket name, an object key, specify the HTTP method (GET to download the object), and expiration date and time. The pre-signed URLs are valid only for the specified duration. So for the given use-case, the object key can be retrieved from the DynamoDB table, and then the application can generate the pre-signed URL using the IAM instance profile.

Please see this note for more details:

via - https://docs.aws.amazon.com/AmazonS3/latest/dev/ShareObjectPreSignedURL.html

Incorrect options:

"Make the S3 bucket public so that the application can reference the image URL for display" - Making the S3 bucket public would violate the security and privacy requirements for the use-case, so this option is incorrect.

"Keep each user's profile image encoded in base64 format in a DynamoDB table and reference it from the application for display"

"Keep each user's profile image encoded in base64 format in an RDS table and reference it from the application for display"

It's a bad practice to keep the raw image data in the database itself. Also, it would not be possible to create a secure access URL for the image without a significant development effort. Hence both these options are incorrect.

Reference:

https://docs.aws.amazon.com/AmazonS3/latest/dev/ShareObjectPreSignedURL.html

Correct option:

Amazon EBS works with AWS KMS to encrypt and decrypt your EBS volume. You can encrypt both the boot and data volumes of an EC2 instance. When you create an encrypted EBS volume and attach it to a supported instance type, the following types of data are encrypted:

1. Data at rest inside the volume
2. All data moving between the volume and the instance
3. All snapshots created from the volume
4. All volumes created from those snapshots

EBS volumes support both in-flight encryption and encryption at rest using KMS - This is a correct statement. Encryption operations occur on the servers that host EC2 instances, ensuring the security of both data-at-rest and data-in-transit between an instance and its attached EBS storage.

Incorrect options:

EBS volumes support in-flight encryption but do not support encryption at rest - This is an incorrect statement. As discussed above, all data moving between the volume and the instance is encrypted.

EBS volumes do not support in-flight encryption but do support encryption at rest using KMS - This is an incorrect statement. As discussed above, data at rest is also encrypted.

EBS volumes don't support any encryption - This is an incorrect statement. Amazon EBS encryption offers a straight-forward encryption solution for your EBS resources associated with your EC2 instances. With Amazon EBS encryption, you aren't required to build, maintain, and secure your own key management infrastructure.

Reference:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html

Correct option:

Server-Side Encryption with Customer Master Keys (CMKs) Stored in AWS Key Management Service (SSE-KMS)

You have the following options for protecting data at rest in Amazon S3:

Server-Side Encryption – Request Amazon S3 to encrypt your object before saving it on disks in its data centers and then decrypt it when you download the objects.

Client-Side Encryption – Encrypt data client-side and upload the encrypted data to Amazon S3. In this case, you manage the encryption process, the encryption keys, and related tools.

When you use server-side encryption with AWS KMS (SSE-KMS), you can use the default AWS managed CMK, or you can specify a customer-managed CMK that you have already created.

Creating your own customer-managed CMK gives you more flexibility and control over the CMK. For example, you can create, rotate, and disable customer-managed CMKs. You can also define access controls and audit the customer-managed CMKs that you use to protect your data.

Please see this note for more details: 

via - https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html

Incorrect options:

Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3) - When you use Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3), each object is encrypted with a unique key. As an additional safeguard, it encrypts the key itself with a master key that it regularly rotates. So this option is incorrect for the given use-case.

Server-Side Encryption with Customer-Provided Keys (SSE-C) - With Server-Side Encryption with Customer-Provided Keys (SSE-C), you manage the encryption keys and Amazon S3 manages the encryption, as it writes to disks, and decryption when you access your objects. So this option is incorrect for the given use-case.

Server-Side Encryption with Secrets Manager - AWS Secrets Manager helps you protect secrets needed to access your applications, services, and IT resources. The service enables you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle. You cannot combine Server-Side Encryption with Secrets Manager to create, rotate, or disable the encryption keys.

Reference:

https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html

The correct answers are:

A. You should use Express Workflows for workloads with high event rates and short duration: Express Workflows are designed for high-volume, short-duration tasks that require faster execution and cost less. This would be suitable for tasks like real-time validation of loan applications or quick credit checks.

D. Standard Workflows on AWS Step Functions are suitable for long-running, durable, and auditable workflows that can also support any human approval steps: Standard Workflows are designed for complex workflows that can span longer durations and require features like human intervention, auditing, and error handling. This would be ideal for the overall loan approval process, including steps like document verification, risk assessment, and final approval.

Why other options are incorrect:

B. Standard Workflows on AWS Step Functions are suitable for long-running, durable, and auditable workflows that do not support any human approval steps: This is incorrect. Standard Workflows do support human approval steps through features like the "Approval" task type.

C. Express Workflows have a maximum duration of five minutes and Standard workflows have a maximum duration of 180 days or 6 months: While this is partially true, it doesn't capture the full essence of the differences between the two workflow types.

E. Both Standard and Express Workflows support all service integrations, activities, and design patterns: This is not entirely accurate. While both types support a wide range of integrations, there are some differences in their capabilities and limitations. For example, Express Workflows have a lower maximum payload size compared to Standard Workflows.

Example:

In a loan approval workflow, you could use an Express Workflow to quickly check the applicant's credit score, and then use a Standard Workflow to orchestrate the entire loan approval process, including manual approval steps, document verification, and final decision-making.

Correct option:

Configure Lambda to connect to VPC with private subnet and Security Group needed to access RDS - You can configure a Lambda function to connect to private subnets in a virtual private cloud (VPC) in your account. Use Amazon Virtual Private Cloud (Amazon VPC) to create a private network for resources such as databases, cache instances, or internal services. Connect your lambda function to the VPC to access private resources during execution. When you connect a function to a VPC, Lambda creates an elastic network interface for each combination of the security group and subnet in your function's VPC configuration. This is the right way of giving RDS access to Lambda.

Lambda VPC Config:

via - https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html

Incorrect options:

Use Lambda layers to connect to the internet and RDS separately - You can configure your Lambda function to pull in additional code and content in the form of layers. A layer is a ZIP archive that contains libraries, a custom runtime, or other dependencies. Layers will not help in configuring access to RDS instance and hence is an incorrect choice.

Configure lambda to connect to the public subnet that will give internet access and use the Security Group to access RDS inside the private subnet - This is an incorrect statement. Connecting a Lambda function to a public subnet does not give it internet access or a public IP address. To grant internet access to your function, its associated VPC must have a NAT gateway (or NAT instance) in a public subnet.

Use Environment variables to pass in the RDS connection string - You can use environment variables to store secrets securely and adjust your function's behavior without updating code. You can use environment variables to exchange data with RDS, but you will still need access to RDS, which is not possible with just environment variables.

References:

https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html

https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html

https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html

https://aws.amazon.com/premiumsupport/knowledge-center/internet-access-lambda-function/

Correct option:

Amazon SQS is highly scalable and does not need any intervention to handle the expected high volumes

Amazon SQS leverages the AWS cloud to dynamically scale, based on demand. SQS scales elastically with your application so you don't have to worry about capacity planning and pre-provisioning. For most standard queues (depending on queue traffic and message backlog), there can be a maximum of approximately 120,000 inflight messages (received from a queue by a consumer, but not yet deleted from the queue).

Info on Queue Quotas: 

via - https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-quotas.html

Incorrect options:

Pre-configure the SQS queue to increase the capacity when messages hit a certain threshold - This is an incorrect statement. Amazon SQS scales dynamically, automatically provisioning the needed capacity.

Enable auto-scaling in the SQS queue - SQS queues are, by definition, auto-scalable and do not need any configuration changes for auto-scaling.

Convert the queue into FIFO ordered queue, since messages to the down system will be processed faster once they are ordered - This is a wrong statement. You cannot convert an existing standard queue to FIFO queue. To make the move, you must either create a new FIFO queue for your application or delete your existing standard queue and recreate it as a FIFO queue.

Standard to FIFO queue conversion:

via - https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html

References:

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-quotas.html

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html