Correct option:

Leverage horizontal scaling for the web and application tiers by using Auto Scaling groups and Application Load Balancer - A horizontally scalable system is one that can increase capacity by adding more computers to the system. This is in contrast to a vertically scalable system, which is constrained to running its processes on only one computer; in such systems, the only way to increase performance is to add more resources into one computer in the form of faster (or more) CPUs, memory or storage.

Horizontally scalable systems are oftentimes able to outperform vertically scalable systems by enabling parallel execution of workloads and distributing those across many different computers.

Elastic Load Balancing is used to automatically distribute your incoming application traffic across all the EC2 instances that you are running. You can use Elastic Load Balancing to manage incoming requests by optimally routing traffic so that no one instance is overwhelmed.

To use Elastic Load Balancing with your Auto Scaling group, you attach the load balancer to your Auto Scaling group to register the group with the load balancer. Your load balancer acts as a single point of contact for all incoming web traffic to your Auto Scaling group.

When you use Elastic Load Balancing with your Auto Scaling group, it's not necessary to register individual EC2 instances with the load balancer. Instances that are launched by your Auto Scaling group are automatically registered with the load balancer. Likewise, instances that are terminated by your Auto Scaling group are automatically deregistered from the load balancer.

This option will require fewer design changes, it's mostly configuration changes and the ability for the web/application tier to be able to communicate across instances. Hence, this is the right solution for the current use case.

Incorrect options:

Leverage SQS with asynchronous AWS Lambda calls to decouple the application and data tiers - This is incorrect as it uses asynchronous AWS Lambda calls and the application uses synchronous transactions. The question says there should be no change in the application architecture.

Leverage horizontal scaling for the application's persistence layer by adding Oracle RAC on AWS - The issue is not with the persistence layer at all. This option has only been used as a distractor.

You can deploy scalable Oracle Real Application Clusters (RAC) on Amazon EC2 using Amazon Machine Images (AMI) on AWS Marketplace. Oracle RAC is a shared-everything database cluster technology from Oracle that allows a single database (a set of data files) to be concurrently accessed and served by one or many database server instances.

Leverage vertical scaling for the application instance by provisioning a larger Amazon EC2 instance size - Vertical scaling is just a band-aid solution and will not work long term.

References:

https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html

https://aws.amazon.com/blogs/compute/operating-lambda-understanding-event-driven-architecture-part-1/

Correct option:

DynamoDB Transactions

You can use DynamoDB transactions to make coordinated all-or-nothing changes to multiple items both within and across tables. Transactions provide atomicity, consistency, isolation, and durability (ACID) in DynamoDB, helping you to maintain data correctness in your applications.

DynamoDB Transactions Overview:

via - https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transactions.html

Incorrect options:

DynamoDB TTL - DynamoDB TTL allows you to expire data based on a timestamp, so this option is not correct.

DynamoDB Streams - DynamoDB Streams gives a changelog of changes that happened to your tables and then may even relay these to a Lambda function for further processing.

DynamoDB Indexes - GSI and LSI are used to allow you to query your tables using different partition/sort keys.

Reference:

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transactions.html

Correct option:

10

Amazon Kinesis Data Streams enables you to build custom applications that process or analyze streaming data for specialized needs.

A Kinesis data stream is a set of shards. A shard is a uniquely identified sequence of data records in a stream. A stream is composed of one or more shards, each of which provides a fixed unit of capacity.

Kinesis Data Streams Overview:

via - https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html

Each KCL consumer application instance uses "workers" to process data in Kinesis shards. At any given time, each shard of data records is bound to a particular worker via a lease. For the given use-case, an EC2 instance acts as the worker for the KCL application. You can have at most one EC2 instance per shard in Kinesis for the given application. As we have 10 shards, the max number of EC2 instances is 10.

via - https://docs.aws.amazon.com/streams/latest/dev/shared-throughput-kcl-consumers.html

Incorrect options:

1

6

20

These three options contradict the explanation provided earlier. So these are incorrect.

Reference:

https://docs.aws.amazon.com/streams/latest/dev/developing-consumers-with-kcl.html

Correct option:

Create one customer-managed policy with policy variables and attach it to a group of all users

You can assign access to "dynamically calculated resources" by using policy variables, a feature that lets you specify placeholders in a policy. When the policy is evaluated, the policy variables are replaced with values that come from the context of the request itself.

This is ideal when you want want to generalize the policy so it works for many users without having to make a unique copy of the policy for each user. For example, consider writing a policy to allow each user to have access to his or her own objects in an Amazon S3 bucket, as in the previous example. But don't create a separate policy for each user that explicitly specifies the user's name as part of the resource. Instead, create a single group policy that works for any user in that group.

via - https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html

Incorrect options:

Create an S3 bucket policy and change it as users are added and removed

This doesn't scale and the S3 bucket policy size may be maxed out. The IAM policies bump up against a size limit (up to 2 kb for users, 5 kb for groups, and 10 kb for roles). S3 supports bucket policies of up 20 kb.

Create inline policies for each user as they are onboarded: This would work but doesn't scale and it's inefficient.

Create one customer-managed policy per user and attach them to the relevant users: This would work but doesn't scale and would be a nightmare to manage.

Reference:

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html

Correct option:

Amazon API Gateway is an AWS service for creating, publishing, maintaining, monitoring, and securing REST, HTTP, and WebSocket APIs at any scale. API developers can create APIs that access AWS or other web services, as well as data stored in the AWS Cloud.

How API Gateway Works:

via - https://aws.amazon.com/api-gateway/

STS

The AWS Security Token Service (STS) is a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users that you authenticate (federated users). However, is not supported at the time with API Gateway.

Incorrect options:

IAM permissions with sigv4 - They can be applied to an entire API or individual methods.

Lambda Authorizer - Control access to REST API methods using bearer token authentication as well as information described by headers, paths, query strings, stage variables, or context variables request parameter.

Cognito User Pools - Use Cognito User Pools to create customizable authentication and authorization solutions for your REST APIs.

Reference:

https://aws.amazon.com/api-gateway/

Correct option:

Versioning can be enabled only for a specific folder

The versioning state applies to all (never some) of the objects in that bucket. The first time you enable a bucket for versioning, objects in it are thereafter always versioned and given a unique version ID.

Versioning Overview:

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

Incorrect options:

Overwriting a file increases its versions - If you overwrite an object (file), it results in a new object version in the bucket. You can always restore the previous version.

Deleting a file is a recoverable operation - Correct, when you delete an object (file), Amazon S3 inserts a delete marker, which becomes the current object version and you can restore the previous version.

Any file that was unversioned before enabling versioning will have the 'null' version - Objects stored in your bucket before you set the versioning state have a version ID of null. Those existing objects in your bucket do not change.

Reference:

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

Correct option:

Use a Lambda@Edge

Lambda@Edge is a feature of Amazon CloudFront that lets you run code closer to users of your application, which improves performance and reduces latency. With Lambda@Edge, you don't have to provision or manage infrastructure in multiple locations around the world. You pay only for the compute time you consume - there is no charge when your code is not running.

How Lambda@Edge Works:

via - https://aws.amazon.com/lambda/edge/

Incorrect options:

Use a Global DynamoDB table as a Lambda source - A Lambda function can run off of DynamoDB Streams using Event Sources, however, it does not deploy the Lambda function globally.

Deploy Lambda in a Global VPC - This option is a distractor as there is no concept of Global VPC in AWS.

Deploy Lambda in S3 - You can't deploy Lambda in S3 but can have your Lambda functions triggered by S3 events.

Reference:

https://aws.amazon.com/lambda/edge/

Correct option:

The simplest way to use HTTPS with an Elastic Beanstalk environment is to assign a server certificate to your environment's load balancer. When you configure your load balancer to terminate HTTPS, the connection between the client and the load balancer is secure. Backend connections between the load balancer and EC2 instances use HTTP, so no additional configuration of the instances is required.

via - https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/configuring-https.html

Create a config file in the .ebextensions folder to configure the Load Balancer

To update your AWS Elastic Beanstalk environment to use HTTPS, you need to configure an HTTPS listener for the load balancer in your environment. Two types of load balancers support an HTTPS listener: Classic Load Balancer and Application Load Balancer.

Example .ebextensions/securelistener-alb.config

Use this example when your environment has an Application Load Balancer. The example uses options in the aws:elbv2:listener namespace to configure an HTTPS listener on port 443 with the specified certificate. The listener routes traffic to the default process.

Incorrect options:

Use a separate CloudFormation template to load the SSL certificate onto the Load Balancer - A separate CloudFormation template won't be able to mutate the state of a Load Balancer managed by Elastic Beanstalk, so this option is incorrect.

Open up the port 80 for the security group - Port 80 is for HTTP traffic, so this option is incorrect.

Configure Health Checks - Health Checks are not related to SSL certificates, so this option is ruled out.

References:

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/configuring-https-elb.html

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/configuring-https.html

Correct option:

Use a Write Through strategy

The write-through strategy adds data or updates data in the cache whenever data is written to the database.

In a Write Through strategy, any new blog or update to the blog will be written to both the database layer and the caching layer, thus ensuring that the latest data is always served from the cache.

via - https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Strategies.html

Incorrect options:

Use a Lazy Loading strategy without TTL

Lazy Loading is a caching strategy that loads data into the cache only when necessary. Whenever your application requests data, it first requests the ElastiCache cache. If the data exists in the cache and is current, ElastiCache returns the data to your application. If the data doesn't exist in the cache or has expired, your application requests the data from your data store.

Use a Lazy Loading strategy with TTL

In the case of Lazy Loading, the data is loaded onto the cache whenever the data is missing from the cache. In case the blog gets updated, it won't be updated from the cache unless that cache expires (in case you used a TTL). Time to live (TTL) is an integer value that specifies the number of seconds until the key expires. When an application attempts to read an expired key, it is treated as though the key is not found. The database is queried for the key and the cache is updated. Therefore, for a while, old data will be served to users which is a problem from a requirements perspective as we don't want any stale data.

Use DAX - This is a cache for DynamoDB based implementations, but in this question, we are considering ElastiCache. Therefore this option is not relevant.

Reference:

https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Strategies.html

Correct option:

Security Groups

A security group acts as a virtual firewall for your EC2 instances to control incoming and outgoing traffic. Inbound rules control the incoming traffic to your instance, and outbound rules control the outgoing traffic from your instance.

Check the security group rules of your EC2 instance. You need a security group rule that allows inbound traffic from your public IPv4 address on the proper port.

Incorrect options:

IAM Roles - Usually you run into issues with authorization of APIs with roles but not for timeout, so this option does not fit the given use-case.

The application is down - Although you can set a health check for application ping or HTTP, timeouts are usually caused by blocked firewall access.

The ALB is warming up - ALB has a slow start mode which allows a warm-up period before being able to respond to requests with optimal performance. So this is not the issue.

Reference:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectionTimeout