Correct options:

Recovery time objective (RTO) represents the number of hours it takes, to return the Amazon RDS database to a working state after a disaster - Recovery time objective (RTO) and recovery point objective (RPO) are two key metrics to consider when developing a DR plan. RTO represents how many hours it takes you to return to a working state after a disaster.

https://aws.amazon.com/blogs/database/implementing-a-disaster-recovery-strategy-with-amazon-rds/

Automated backups, manual snapshots and Read Replicas are supported across multiple Regions - The automated backup feature of Amazon RDS enables point-in-time recovery for your database instance. Amazon RDS will backup your database and transaction logs and store both for a user-specified retention period. If it’s a Multi-AZ configuration, backups occur on the standby to reduce I/O impact on the primary. Amazon RDS supports Cross-Region Automated Backups. Manual snapshots and Read Replicas are also supported across multiple Regions.

Database snapshots are user-initiated backups of your complete DB instance that serve as full backups. These snapshots can be copied and shared to different Regions and accounts - Database snapshots are manual (user-initiated) backups of your complete DB instance that serve as full backups. They’re stored in Amazon S3 and are retained until you explicitly delete them. These snapshots can be copied and shared to different Regions and accounts. Because DB snapshots include the entire DB instance, including data files and temporary files, the size of the instance affects the amount of time it takes to create the snapshot.

Incorrect options:

Recovery time objective (RTO), expressed in hours, represents how much data you could lose when a disaster happens - RTO represents how many hours it takes you to return to a working state after a disaster. RPO, which is also expressed in hours, represents how much data you could lose when a disaster happens.

You can share automated Amazon RDS snapshots with up to 20 AWS accounts - This statement is incorrect. Amazon RDS enables you to share DB snapshots or cluster snapshots with other AWS accounts. You can share manual DB snapshots with up to 20 AWS accounts. Automated Amazon RDS snapshots cannot be shared directly with other AWS accounts.

Similar to an Amazon RDS Multi-AZ configuration, failover to a Read Replica is an automated process that requires no manual intervention after initial configurations - Unlike an Amazon RDS Multi-AZ configuration, failover to a Read Replica is not an automated process. If you are using cross-Region Read Replicas, you should be certain that you want to switch your AWS resources between Regions. Cross-Region traffic can experience latency, and reconfiguring applications can be complicated.

Reference:

https://aws.amazon.com/blogs/database/implementing-a-disaster-recovery-strategy-with-amazon-rds/

Correct options:

Use EFS as the data tier of the storage layer

Amazon Elastic File System (Amazon EFS) provides a simple, scalable, fully managed elastic NFS file system for use with AWS Cloud services and on-premises resources.

Amazon EFS is a Regional service storing data within and across multiple Availability Zones (AZs) for high availability and durability. Amazon EC2 instances can access your file system across AZs, Regions, and VPCs, while on-premises servers can access using AWS Direct Connect or AWS VPN. You can connect to Amazon EFS file systems from EC2 instances in other AWS Regions using an inter-Region VPC peering connection, and from on-premises servers using an AWS VPN connection. EFS is also POSIX compliant and can be shared across many systems, so it fits the given use-case.

https://aws.amazon.com/efs/

Use EC2 Instance Store as the service tier of the storage layer

An instance store (also known as ephemeral storage) provides temporary block-level storage for your instance. This storage is located on disks that are physically attached to the host computer. Instance store is ideal for the temporary storage of information that changes frequently such as buffers, caches, scratch data, and other temporary content, or for data that is replicated across a fleet of instances, such as a load-balanced pool of web servers. Instance store volumes are included as part of the instance's usage cost.

As Instance Store based volumes provide high random I/O performance at low cost (as the storage is part of the instance's usage cost) and the fault-tolerant architecture can adjust for the loss of any instance, therefore you should use Instance Store based EC2 instances for this use-case.

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

Per the given use-case, the key requirement for the service tier of the storage layer is to support block storage with more than a million IOPS. The Max IOPS per volume supported by EBS is only 256K for provisioned IOPS SSD (io2 block express). On the other hand, SSD-based instance store volumes support more than a million IOPS for random reads. So, this option is correct.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/storage-optimized-instances.html

Incorrect options:

Use EBS volumes with Provisioned IOPS as the service tier of the storage layer - As mentioned in the explanation above, the Max IOPS per volume supported by EBS is 256K for provisioned IOPS SSD (io2 block express), so this option is incorrect.

Use EC2 Instance Store as the data tier of the storage layer - This option is incorrect as Instance Store cannot be used as data tier for the given use-case because it cannot be shared across many systems at the same time. This capability is only offered by EFS.

Use Amazon S3 as the data tier of the storage layer - This option is incorrect as S3 is not POSIX compliant.

References:

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

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/storage-optimized-instances.html

Correct options:

Configure a Lambda function as one of the SNS topic subscribers, which is invoked to secure the objects in the S3 bucket

Enable object-level logging for S3. Set up a CloudWatch event pattern when a PutObject API call with public-read permission is detected in the AWS CloudTrail logs and set the target as an SNS topic for downstream notifications

You can enable object-level logging for an S3 bucket to send logs to CloudTrail for object-level API operations such as GetObject, DeleteObject, and PutObject. These events are called data events. By default, CloudTrail trails don't log data events, but you can configure trails to log data events for S3 buckets that you specify, or to log data events for all the Amazon S3 buckets in your AWS account.

https://docs.aws.amazon.com/AmazonS3/latest/user-guide/enable-cloudtrail-events.html

You need to further configure a CloudWatch event-pattern based rule to analyze the CloudTrail logs for S3 PutObject API call with public-read permissions. The target for this rule can be set as an SNS topic. The SNS would send the notification via an email or SMS as soon as a public object is detected. Moreover, the SNS topic is also subscribed by a Lambda function which runs custom code to secure the objects in the S3 bucket.

https://docs.aws.amazon.com/sns/latest/dg/welcome.html

Incorrect options:

Enable object-level logging for S3. When a PutObject API call is made with a public-read permission, use S3 event notifications to trigger a Lambda that sends a notification via SNS - S3 event notification allows you to receive notifications when certain events happen in your bucket. To enable notifications, you must first add a notification configuration that identifies the events you want Amazon S3 to publish and the destinations where you want Amazon S3 to send the notifications. S3 can publish notifications for the new object create events.

You can request notification when only a specific API is used (for example, s3:ObjectCreated:Put), or you can use a wildcard (for example, s3:ObjectCreated:*), however, you cannot check if the API call was made with a public-read permission. So, this option is incorrect.

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

Leverage AWS Trusted Advisor to check for S3 bucket public-read permissions and invoke a Lambda function to send a notification via SNS as soon as a public object is uploaded - Trusted Advisor is an application that inspects your AWS environment and makes recommendations for saving money, improving system performance, or closing security gaps. The Trusted Advisor notification feature helps you stay up-to-date with your AWS resource deployment. However, you will only be notified by weekly email when you opt-in for this service, so this does not meet the key requirement for the use-case wherein the notification should be sent as soon as a public object is uploaded. Also, Trusted Advisor just checks buckets in Amazon Simple Storage Service (Amazon S3) that have open access permissions. It cannot be used for near real-time detection of a new public object uploaded on S3.

https://aws.amazon.com/premiumsupport/faqs/

Leverage AWS Access Analyzer to check for S3 bucket public-read permissions and invoke a Lambda function to send a notification via SNS as soon as a public object is uploaded - You can use AWS Access Analyzer to receive findings into the source and level of public or shared access for each public or shared bucket. For example, Access Analyzer for S3 might show that a bucket has read or write access provided through a bucket access control list (ACL), a bucket policy, or an access point policy. It cannot be used for near real-time detection of a new public object uploaded on S3. Additionally, you cannot invoke a Lambda function from Access Analyzer. The findings for Access Analyzer are available within the AWS Console or they can be downloaded in a CSV report.

https://docs.aws.amazon.com/AmazonS3/latest/user-guide/access-analyzer.html

References:

https://docs.aws.amazon.com/AmazonS3/latest/user-guide/enable-cloudtrail-events.html

https://docs.aws.amazon.com/sns/latest/dg/welcome.html

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

https://aws.amazon.com/premiumsupport/faqs/

https://docs.aws.amazon.com/AmazonS3/latest/user-guide/access-analyzer.html

Correct options:

Process and analyze the Amazon CloudWatch Logs for Lambda function to determine processing times for requested images at pre-configured intervals

To help you troubleshoot failures in a function, the Lambda service logs all requests handled by a Lambda function and also automatically stores logs generated by your code through Amazon CloudWatch Logs. You can insert logging statements into your code to determine processing times for requested images. These logs can then be processed at certain pre-configured intervals for further analysis.

https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html

Process and analyze the AWS X-Ray traces and analyze HTTP methods to determine the root cause of the HTTP errors

You can use AWS X-Ray to visualize the components of your application, identify performance bottlenecks such as the one described in the use-case for processing images and troubleshoot those requests that resulted in an error. Your Lambda functions send trace data to X-Ray, and X-Ray processes the data to generate a service map and searchable trace summaries.

https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html

Incorrect options:

Enable execution logging for the API Gateway. Process and analyze the execution logs in the API Gateway for HTTP errors to determine the root cause of the errors

Enable access logging for the API Gateway. Process and analyze the access logs in the API Gateway for HTTP errors to determine the root cause of the errors

For an API Gateway, a "504 Gateway Timeout" error implies an "Endpoint Request Timed-out Exception".

https://docs.aws.amazon.com/apigateway/api-reference/handling-errors/

To troubleshoot an API Gateway REST API or WebSocket API that you're developing, enable execution logging and access logging to Amazon CloudWatch Logs. Execution logs contain helpful information that you can use to identify and fix most errors with your APIs. Access logs contain details about who accessed your API and how they accessed it, which you can also use for troubleshooting.

https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-cloudwatch-logs/

However, neither execution logs nor access logs at the API Gateway level will provide information to identify the root cause for the "504 Gateway Timeout" error as it needs to be analyzed at the source system level which is Lambda function for the given use-case, as that's where the images are being processing and the application is lagging or timing out for some of those images. Another thing to note is that only access logs are available for HTTP APIs, so you do not have access to execution logs for the given use-case.

Therefore, both of these options are incorrect.

Process and analyze the VPC Flow Logs to determine if there is packet loss between the Lambda function and S3

VPC Flow Logs allow you to capture information about the IP traffic going to and from network interfaces in your VPC. You can create a flow log for a VPC, a subnet, or a network interface. If you create a flow log for a subnet or VPC, each network interface in that subnet or VPC is monitored.

https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html

This option has been added as a distractor as you cannot use VPC Flow Logs to determine packet loss. AWS has a built-in tool called AWSSupport-SetupIPMonitoringFromVPC that you can use to monitor metrics such as latency and the percentage of packet loss across a network path. It monitors the selected target IP addresses by continuously running ping, MTR, TCP traceroute, and tracepath network diagnostic tests.

References:

https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html

https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html

https://docs.aws.amazon.com/apigateway/api-reference/handling-errors/

https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-cloudwatch-logs/

https://aws.amazon.com/blogs/networking-and-content-delivery/debugging-tool-for-network-connectivity-from-amazon-vpc/

https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html

Correct options:

Use CloudFront signed URLs to restrict access to the application installation file

Use CloudFront signed cookies to restrict access to all the files in the members' area of the website

Many companies that distribute content over the internet want to restrict access to documents, business data, media streams, or content that is intended for selected users, for example, users who have paid a fee.

To securely serve this private content by using CloudFront, you can do the following:

Require that your users access your private content by using special CloudFront signed URLs or signed cookies.

You should use a signed URL if you want to restrict access to individual files, for example, an installation download for your application. A signed URL includes additional information, for example, expiration date and time, that gives you more control over access to your content.

On the other hand, CloudFront signed cookies allow you to control who can access your content when you don't want to change your current URLs or when you want to provide access to multiple restricted files, for example, all of the files in the members' area of a website.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-choosing-signed-urls-cookies.html

Incorrect options:

Use CloudFront signed cookies to restrict access to the application installation file

Use CloudFront signed URLs to restrict access to all the files in the members' area of the website

These two options contradict the description provided in the explanation above, so these options are incorrect.

Require HTTPS for communication between CloudFront and your S3 origin

Requiring HTTPS for communication between CloudFront and your custom origin (or S3 origin) only enables secure access to the underlying content. You cannot use HTTPS to restrict access to your private content. So this option is incorrect.

References:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-choosing-signed-urls-cookies.html

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-cookies.html

Correct option:

Set up DynamoDB Streams to capture and send updates to a Lambda function that outputs records to Kinesis Data Analytics (KDA) via Kinesis Data Streams (KDS). Detect and analyze anomalies in KDA and send notifications via SNS

A DynamoDB stream is an ordered flow of information about changes to items in a DynamoDB table. When you enable a stream on a table, DynamoDB captures information about every modification to data items in the table for up to 24 hours.

Whenever an application creates, updates, or deletes items in the table, DynamoDB Streams writes a stream record with the primary key attributes of the items that were modified. A stream record contains information about a data modification to a single item in a DynamoDB table.

DynamoDB Streams supports the following stream record views:

KEYS_ONLY — Only the key attributes of the modified item NEW_IMAGE — The entire item, as it appears after it was modified OLD_IMAGE — The entire item, as it appears before it was modified NEW_AND_OLD_IMAGES — Both the new and the old images of the item

You can process DynamoDB streams in multiple ways. The most common approaches use AWS Lambda or a standalone application that uses the Kinesis Client Library (KCL) with the DynamoDB Streams Kinesis Adapter. The KCL is a client-side library that provides an interface to process DynamoDB stream changes. If you enable DynamoDB Streams on a table, you can associate the stream Amazon Resource Name (ARN) with an AWS Lambda function that you write. Immediately after an item in the table is modified, a new record appears in the table's stream. AWS Lambda polls the stream and invokes your Lambda function synchronously when it detects new stream records.

https://aws.amazon.com/blogs/database/dynamodb-streams-use-cases-and-design-patterns/

For the given use-case, you can use a Lambda function to capture updates from DynamoDB Streams and send those records to KDA via KDS. You can then detect and analyze anomalies in KDA and send notifications via SNS.

https://aws.amazon.com/kinesis/data-streams/

https://aws.amazon.com/kinesis/data-analytics/

It is important to note that Kinesis Data Analytics (KDA) only supports the following streaming sources for an application:

A Kinesis data stream (KDS)

A Kinesis Data Firehose (KDF) delivery stream

Therefore, you cannot directly write the output of the records from a Lambda function to KDA, although you can certainly use a Lambda function to pre-process the incoming stream from either KDS or KDF.

Incorrect options:

Set up CloudTrail to capture all API calls that update the DynamoDB tables. Leverage CloudTrail event filtering to analyze anomalous behaviors and send SNS notifications in case anomalies are detected - You can use CloudTrail to capture API calls for DynamoDB as events. The calls captured include calls from the DynamoDB console and code calls to the DynamoDB API operations. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for DynamoDB. The CloudTrail does not support the GetRecords API for DynamoDB Streams so you cannot use it to capture the actual records. Moreover, you cannot use CloudTrail event filtering to analyze anomalous behaviors as it is just a simple filtering mechanism based on certain event attributes such as Read Only, Event Source, Event Time etc.

Configure event patterns in CloudWatch Events to capture DynamoDB API call events and set up Lambda function as a target to analyze anomalous behavior. Send SNS notifications when anomalous behaviors are detected - CloudWatch Events service does not offer event type for DynamoDB as it's dependent on ClodTrail to get the relevant API call information. As explained above, CloudTrail itself cannot capture the DynamoDB streams records as CloudTrail does not support the GetRecords API for DynamoDB Streams. Therefore this option is incorrect.

Set up DynamoDB Streams to capture and send updates to a Lambda function that outputs records directly to Kinesis Data Analytics (KDA). Detect and analyze anomalies in KDA and send notifications via SNS - As mentioned earlier, KDA only supports KDS and KDF as the streaming sources for an application, so this option is incorrect.

References:

https://aws.amazon.com/blogs/database/dynamodb-streams-use-cases-and-design-patterns/

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

https://docs.aws.amazon.com/kinesisanalytics/latest/dev/how-it-works-input.html

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/logging-using-cloudtrail.html

Correct options:

Configure the ElastiCache cluster to have both in-transit as well as at-rest encryption

You can use both in-transit as well as at-rest encryption to guard against unauthorized access of your data on the server. In-transit encryption encrypts your data whenever it is moving from one place to another, such as between nodes in your cluster or between your cluster and your application. At-rest encryption encrypts your on-disk data during sync and backup operations.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/encryption.html

Create the cluster with auth-token parameter and make sure that the parameter is included in all subsequent commands to the cluster

Redis authentication tokens enable Redis to require a token (password) before allowing clients to run commands, thereby improving data security. You can require that users enter a token on a token-protected Redis server. You also need to include it in all subsequent commands to the replication group or cluster.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/auth.html

Configure the security group for the ElastiCache cluster with the required rules to allow inbound traffic from the cluster itself as well as from the cluster's clients on port 6379

You can create a VPC security group to restrict access to the cluster instances. Configure rules that only allow inbound traffic from the cluster itself as well as from the cluster's clients on port 6379. Typically the ElastiCache cluster is accessed from the web servers running on EC2 instances. You can configure the security groups like so:

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/elasticache-vpc-accessing.html

Incorrect options:

Configure the security group for the ElastiCache cluster with the required rules to allow outbound traffic to the cluster's clients on port 6379 - As mentioned in the explanation above, you need to create a security group that allows inbound traffic from the cluster itself as well as from the cluster's clients on port 6379. Creating a security group rule that allows outbound traffic from the cluster on port 6379 is not relevant to the use-case.

Enable CloudWatch Logs to monitor the security credentials for the ElastiCache cluster

Enable CloudTrail to monitor the API Calls for the ElastiCache cluster

Both these options are added as distractors since both CloudWatch Logs and CloudTrail can be used for post-facto analysis to ascertain the series of access events relevant to the cluster. These options will not prevent unauthorized access.

References:

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/encryption.html

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/auth.html

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/elasticache-vpc-accessing.html

Correct options:

Leverage Config rules to audit changes to AWS resources and monitor the compliance of the configuration by running the evaluations for the rule at a frequency that you choose. Develop AWS Config custom rules to establish a test-driven development approach by triggering the evaluation when any resource that matches the rule's scope changes in configuration

AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. With Config, you can review changes in configurations and relationships between AWS resources, dive into detailed resource configuration histories, and determine your overall compliance against the configurations specified in your internal guidelines. You can use Config to answer questions such as - “What did my AWS resource look like at xyz point in time?”.

https://aws.amazon.com/config/

For the given use-case, you can use AWS Config to evaluate the configuration settings of your AWS resources. You do this by creating AWS Config rules, which represent your ideal configuration settings. AWS Config provides customizable, predefined rules called managed rules to help you get started. You can also create your own custom rules. While AWS Config continuously tracks the configuration changes that occur among your resources, it checks whether these changes violate any of the conditions in your rules. If a resource violates a rule, AWS Config flags the resource and marks the rule as noncompliant.

https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_manage-rules.html

There are two types of evaluation trigger types for Config rules:

Configuration changes – AWS Config triggers the evaluation when any resource that matches the rule's scope changes in configuration. The evaluation runs after AWS Config sends a configuration item change notification.

Periodic – AWS Config runs evaluations for the rule at a frequency that you choose (for example, every 24 hours).

Enable trails and set up CloudTrail events to review and monitor management activities of all AWS accounts by logging these activities into CloudWatch Logs using a KMS key. Ensure that CloudTrail is enabled for all accounts as well as all available AWS services

CloudTrail is an AWS service that helps you enable governance, compliance, and operational and risk auditing of your AWS account. Actions taken by a user, role, or an AWS service are recorded as events in CloudTrail. An event in CloudTrail is the record of activity in an AWS account. This activity can be an action taken by a user, role, or service that is monitorable by CloudTrail. CloudTrail events provide a history of both API and non-API account activity made through the AWS Management Console, AWS SDKs, command line tools, and other AWS services.

CloudTrail data events are disabled by default. You can enable logging at an additional cost. Data events are also known as data plane operations and are often high-volume activities. Data events aren't viewable in CloudTrail event history and are charged for all copies at a reduced rate compared to management events.

CloudTrail records management events for the last 90 days free of charge, and are viewable in the Event History with the CloudTrail console. For Amazon S3 delivery of CloudTrail events, the first copy delivered is free. Additional copies of management events are charged.

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-concepts.html#cloudtrail-concepts-management-events

Incorrect options:

Leverage CloudWatch Logs agent to collect all the AWS SDK logs. Search the log data using a pre-defined set of filter patterns that match mutating API calls. Use CloudWatch alarms to send notifications via SNS when unintended changes are performed. Archive log data by using a batch export to Amazon S3 and analyze via Athena - One of the key constraints for the given scenario is that the AWS Management Console is the preferred method for the in-house teams wanting to provision resources. Although this option is technically feasible, but it focuses on using CloudWatch Logs agent to collect all the AWS SDK logs. The given use-case has no specific requirements for AWS SDKs or AWS APIs because AWS Management Console is the preferred method to provision resources. So this option is not the best fit solution.

Leverage CloudTrail integration with SNS to automatically notify unauthorized API activities. Ensure that CloudTrail is enabled for all accounts as well as all available AWS services. Use Lambda functions to automatically revert non-authorized changes in AWS resources - One of the key constraints for the given scenario is that the AWS Management Console is the preferred method for the in-house teams wanting to provision resources. Although this option is technically feasible, but it focuses on capturing unauthorized API activities. The given use-case has no specific requirements for AWS SDKs or AWS APIs because AWS Management Console is the preferred method to provision resources. In addition, the use-case just talks about assessing, auditing and monitoring the configurations of AWS resources. Reverting non-authorized changes in AWS resources is not part of the mandate. So this option is not correct.

Leverage CloudWatch Events near-real-time capabilities to monitor system events patterns to trigger Lambda functions to automatically revert non-authorized changes in AWS resources. Send notifications via SNS topics to improve the incidence response time - The use-case just talks about assessing, auditing and monitoring the configurations of AWS resources. Reverting non-authorized changes in AWS resources is not part of the mandate. So this option is not correct.

References:

https://aws.amazon.com/config/

https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_manage-rules.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-concepts.html#cloudtrail-concepts-management-events

Correct option:

Use AWS Kinesis Data Streams to facilitate multiple applications consume the same streaming data concurrently and independently

Amazon Kinesis Data Streams (KDS) is a massively scalable and durable real-time data streaming service. KDS can continuously capture gigabytes of data per second from hundreds of thousands of sources such as website clickstreams, database event streams, financial transactions, social media feeds, IT logs, and location-tracking events. The data collected is available in milliseconds to enable real-time analytics use cases such as real-time dashboards, real-time anomaly detection, dynamic pricing, and more.

Amazon Kinesis Data Streams enables real-time processing of streaming big data. It provides ordering of records, as well as the ability to read and/or replay records in the same order to multiple Amazon Kinesis Applications. The Amazon Kinesis Client Library (KCL) delivers all records for a given partition key to the same record processor, making it easier to build multiple applications reading from the same Amazon Kinesis data stream (for example, to perform counting, aggregation, and filtering).

Amazon Kinesis Data Streams is recommended when you need the ability for multiple applications to consume the same stream concurrently. For example, you have one application that updates a real-time dashboard and another application that archives data to Amazon Redshift. You want both applications to consume data from the same stream concurrently and independently.

https://aws.amazon.com/kinesis/data-streams/faqs/

Incorrect options:

Use AWS Kinesis Data Firehose to allow applications to consume same streaming data concurrently and independently - Amazon Kinesis Data Firehose is the easiest way to load streaming data into data stores and analytics tools. It can capture, transform, and load streaming data into Amazon S3, Amazon Redshift, Amazon Elasticsearch Service, and Splunk, enabling near real-time analytics with existing business intelligence tools and dashboards you’re already using today. It is a fully managed service that automatically scales to match the throughput of your data and requires no ongoing administration. It can also batch, compress, and encrypt the data before loading it, minimizing the amount of storage used at the destination and increasing security. As Kinesis Data Firehose is used to load streaming data into data stores, therefore this option is incorrect.

Use AWS Kinesis Data Analytics to facilitate multiple applications consume and analyze same streaming data concurrently and independently - Amazon Kinesis Data Analytics is the easiest way to analyze streaming data in real-time. You can quickly build SQL queries and sophisticated Java applications using built-in templates and operators for common processing functions to organize, transform, aggregate, and analyze data at any scale. Kinesis Data Analytics enables you to easily and quickly build queries and sophisticated streaming applications in three simple steps: setup your streaming data sources, write your queries or streaming applications and set up your destination for processed data. As Kinesis Data Analytics is used to build SQL queries on streaming data, therefore this option is incorrect.

Use Amazon SQS to facilitate multiple applications process same streaming data concurrently and independently - Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. SQS offers two types of message queues. Standard queues offer maximum throughput, best-effort ordering, and at-least-once delivery. SQS FIFO queues are designed to guarantee that messages are processed exactly once, in the exact order that they are sent. For SQS, you cannot have the same message being consumed by multiple consumers at the same time, therefore this option is incorrect.

References:

https://aws.amazon.com/kinesis/data-streams/faqs/

https://aws.amazon.com/kinesis/data-firehose/faqs/

https://aws.amazon.com/kinesis/data-analytics/faqs/

Correct option:

Set up a VPC peering connection between the two VPCs and add a route to the routing table of VPC X that points to the IP address range of 172.30.0.0/16

Set up a VPC peering connection between the two VPCs and add a route to the routing table of VPC Y that points to the IP address range of 172.20.0.0/16

A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. Instances in either VPC can communicate with each other as if they are within the same network. You can create a VPC peering connection between your own VPCs, or with a VPC in another AWS account. The VPCs can be in different regions (also known as an inter-region VPC peering connection).

https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html

For the given use-case, you must set up a VPC peering connection between the two VPCs and then add a route to the route table of VPC X that's associated with your subnet in which the 20 EC2 instances running the application reside. The route points to the CIDR block of the peer VPC Y (172.30.0.0/16) or it can also point to just a portion of the CIDR block such as the subnet 172.30.0.0/24 in the VPC peering connection and lastly specify the VPC peering connection as the target. You should also add a route to the routing table of VPC Y that points back to VPC X via the IP address range of 172.20.0.0/16.

 https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html

Incorrect options:

Create and attach NAT gateways for both VPCs and set up routes to the NAT gateways for both VPCs. Assign an Elastic IP for the EC2 instance running MySQL database in VPC Y. Update the application instances to connect to this Elastic IP - You can attach NAT gateways to enable instances in a private subnet to connect to the internet (for example, for software updates) or other AWS services, but prevent the internet from initiating connections with the instances. A NAT gateway forwards traffic from the instances in the private subnet to the internet or other AWS services, and then sends the response back to the instances. NAT gateways are attached in the public subnets. Additionally, adding Elastic IP to the EC2 instance running MySQL database would necessitate updating configurations in the application instances. So, this option is incorrect.

Create and attach internet gateways for both VPCs and set up default routes to the Internet gateways for both VPCs. Assign an Elastic IP for the EC2 instance running MySQL database in VPC Y. Update the application instances to connect to this Elastic IP - Attaching internet gateway to both VPCs would take away the security considerations for the given use-case as in that case the application instances would connect to the EC2 instance running MySQL database over the public internet. Additionally, adding Elastic IP to the EC2 instance running MySQL database would necessitate updating configurations in the application instances. So, this option is incorrect.

Create and attach VPC Gateway endpoints for both VPCs and set up default routes to the Gateway endpoints for both VPCs. Assign an Elastic IP for the EC2 instance running MySQL database in VPC Y. Update the application instances to connect to this Elastic IP - A VPC endpoint enables you to privately connect your VPC to supported AWS services. Traffic between your VPC and the other service does not leave the Amazon network. A gateway endpoint is a gateway that you specify as a target for a route in your route table for traffic destined to a supported AWS service such as Amazon S3. Gateway endpoints cannot be used for establishing routes between VPCs. Additionally, adding Elastic IP to the EC2 instance running MySQL database would necessitate updating configurations in the application instances. So, this option is incorrect.

References:

https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html

https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html