Option A is incorrect. This data collection system architecture is best suited to batch consumption of stream data. You are trying to build a real-time financial risk management analytics collection architecture. You have several databases and data warehouses generating your data stream from their changed data. This approach is called ongoing replication or change data capture (CDC) within the Database Migration Service. A collection architecture using the Database Migration Service will be the most optimal for this use case.
Option B is incorrect. This data collection system architecture is suited to real-time consumption of data, but a collection architecture using the Database Migration Service would better fit this use case. You have several databases and data warehouses generating your data stream from their changed data. This approach is called ongoing replication or change data capture (CDC) within the Database Migration Service. A collection architecture using the Database Migration Service will be the most optimal for this use case.
Option C is correct. This type of data collection infrastructure is best used for streaming transactional data from existing relational data stores. You create a task within the Database Migration Service that collects ongoing changes within your various operational data stores, an approach called ongoing replication or change data capture (CDC). These changes are streamed to an S3 bucket where a Glue job is used to transform the data and move it to your S3 data lake. 
Option D is incorrect. Kinesis Data Analytics cannot write directly to S3; it only writes to a Kinesis data stream, a Kinesis Data Firehose delivery stream, or a Lambda function. Also, this collection architecture does not take advantage of the Database Migration Service ongoing replication or change data capture (CDC) technique.
Reference:
Please see the AWS Database Migration Service user guide titled Creating Tasks for Ongoing Replication Using AWS DMS (https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Task.CDC.html), the AWS Schema Conversion Tool user guide titled What Is the AWS Schema Conversion Tool? (https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html),
the Amazon Kinesis Data Analytics for SQL Applications developer guide titled Configuring Application Output
(https://docs.aws.amazon.com/kinesisanalytics/latest/dev/how-it-works-output.html), the AWS Streaming Data page titled What is Streaming Data? (https://aws.amazon.com/streaming-data/), the AWS Database Migration Service FAQs (https://aws.amazon.com/dms/faqs/), the Amazon Kinesis Data Analytics FAQs (https://aws.amazon.com/kinesis/data-analytics/faqs/), the Amazon Kinesis Data Streams FAQs (https://aws.amazon.com/kinesis/data-streams/faqs/), , the Amazon Kinesis Data Firehose developer guide titles What is Amazon Kinesis Data Firehose? (https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html#data-flow-diagrams), the AWS Glue developer guide titled AWS Glue Concepts (https://docs.aws.amazon.com/glue/latest/dg/components-key-concepts.html), and the Amazon Kinesis Data Firehose FAQs (https://aws.amazon.com/kinesis/data-firehose/faqs/)

Option A is incorrect because using the commands in this answer you don’t reduce the size of your tbl files before attempting to move them to S3. Also, when you attempt to move these files into Redshift from your S3 bucket the process will be less efficient because you haven’t split your files into more manageable sizes.
Option B is incorrect because when you attempt to split your files you haven’t determined the actual number of rows of each file. Therefore, your random selection of a split size will more than likely not be an efficient selection.
Option C is incorrect because your split command does not have a trailing ‘-’ at the end of the command. Therefore your smaller files on your S3 bucket will have names like ‘orders.tbl0001’ versus the more readable and manageable ‘orders.tbl-0001’ if you use a trailing ‘-’ in the split command.
Option D is correct because you have used the wc command to find the number of rows in each tbl file, and you have used the split command with the trailing ‘-’ to get the proper file name format on your S3 bucket in preparation for loading into Redshift.
Reference:
Please see the AWS Redshift Developer Guide titled Tutorial: Loading Data from Amazon S3 (https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-data.html), specifically step 2: Download the Data Files and Step 5: Run the Copy Commands where you’ll see that having the ‘-’ at the end of your split command will allow you to make your Redshift copy command more efficient.

Option A is incorrect because with this approach you don’t have a capability to perform the required transformations. You could write a lambda function to perform the transformations but the answer doesn’t specify these details.
Option B is incorrect because the answer is missing the Kinesis Agent part of the solution. You could write your Kinesis producer application to read the application log files, but using the Kinesis Agent is much more efficient.
Option C is correct. The Kinesis Agent ingests the application log data, the Kinesis Analytics application transforms the data, and Kinesis Analytics queries are used to build your dashboard.
Option D is incorrect since while a CloudWatch dashboard could be used to build this solution simply, it lacks the real-time capability. CloudWatch high-resolution metrics log in intervals of 1 second, 5 seconds, 10 seconds, 30 seconds, or multiples of 60 seconds. Also, this solution lacks the ability to perform the required transformations of the log data.
Reference:
Please see the Amazon CloudWatch FAQs (https://aws.amazon.com/cloudwatch/faqs/), the Amazon Kinesis Data Firehose Developer Guide titled Amazon Kinesis Data Firehose Data Transformation (https://docs.aws.amazon.com/firehose/latest/dev/data-transformation.html), the AWS blog titled Implement Serverless Log Analytics Using Kinesis Analytics (https://aws.amazon.com/blogs/big-data/implement-serverless-log-analytics-using-amazon-kinesis-analytics/), and the Amazon Kinesis Data Streams overview page (https://aws.amazon.com/kinesis/data-streams/)

Option A is incorrect because the Kinesis REST API is not the most efficient way to gather the IoT device data from your set of devices. Also, Apache DistCp does not offer the compression option that S3DistCp offers.
Option B is correct. The AWS IoT service ingests the device data, Kinesis Data Firehose streams the data to your S3 data lake, then the S3DistCp command is used to compress and move the data inno your EMR cluster
Option C is incorrect. The Kinesis Producer Library  is not the most efficient way to gather the IoT device data from your set of devices.
Option D is incorrect. The Kinesis Client Library is used to consume Kinesis Stream data, not to produce data for consumption into the data stream. Also, Apache DistCp does not offer the compression option that S3DistCp offers.
Reference:
Please see the AWS IoT overview page (https://aws.amazon.com/iot/), the Amazon Premium Support Knowledge Center article titled How can I copy large amounts of data from Amazon S3 into HDFS on my Amazon EMR cluster?
(https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/), the Amazon EMR Release Guide titled S3DistCp (s3-dist-cp)
(https://docs.aws.amazon.com/emr/latest/ReleaseGuide/UsingEMR_s3distcp.html), the AWS Big Data blog titled Seven Tips for Using S3DistCp on Amazon EMR to Move Data Efficiently Between HDFS and Amazon S3 (https://aws.amazon.com/blogs/big-data/seven-tips-for-using-s3distcp-on-amazon-emr-to-move-data-efficiently-between-hdfs-and-amazon-s3/), and the AWS Solutions page titled Real-Time IoT Device Monitoring with Kinesis Data Analytics (https://aws.amazon.com/solutions/real-time-iot-device-monitoring-with-kinesis/)

Option A is correct. This data collection system architecture is best suited to batch consumption of stream data. Crawling the S3 data using Glue and then using a Glue job to write the data to an S3 data lake to then be queried by Athena allows you to produce aggregate data analytics. These data can help you build your KPI dashboard.
Option B is incorrect. This data collection system architecture is best suited to real-time consumption of data. Batch sensor data is better processed with a Glue ETL job versus a Kinesis Data Analytics application.
Option C is incorrect. This type of data collection infrastructure is best used for streaming transactional data from existing relational data stores. There is no need for an RDS instance in this data collection system since we can use a data lake to house the historical data and use Amazon Athena to query the data lake.
Option D is incorrect. Kinesis Data Analytics cannot write directly to S3; it only writes to a Kinesis data stream, a Kinesis Data Firehose delivery stream, or a Lambda function.
Reference:
Please see the Amazon Kinesis Data Analytics for SQL Applications developer guide titled Configuring Application Output
(https://docs.aws.amazon.com/kinesisanalytics/latest/dev/how-it-works-output.html), the AWS Streaming Data page titled What is Streaming Data? (https://aws.amazon.com/streaming-data/), the AWS Database Migration Service FAQs (https://aws.amazon.com/dms/faqs/), the Amazon Kinesis Data Analytics FAQs (https://aws.amazon.com/kinesis/data-analytics/faqs/), the Amazon Kinesis Data Streams FAQs (https://aws.amazon.com/kinesis/data-streams/faqs/), , the Amazon Kinesis Data Firehose developer guide titles What is Amazon Kinesis Data Firehose? (https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html#data-flow-diagrams), the AWS Glue developer guide titled AWS Glue Concepts (https://docs.aws.amazon.com/glue/latest/dg/components-key-concepts.html), and the Amazon Kinesis Data Firehose FAQs (https://aws.amazon.com/kinesis/data-firehose/faqs/)

Option A is incorrect because none of the collection systems listed easily allow for the before-change and after-change views of your applications data store changes. Also, there is no data store other than S3 in the listed collection system components. S3 is not the most cost effective data store for this type of application.
Option B is correct. Your application will write its game activity data to your DynamoDB table which will have DynamoDB streams enabled. DynamoDB Streams will record both the new and old (or before and after) images of any item in the DynamoDB table that is changed. Your Lambda function will be triggered by DynamoDB Streams. Your Lambda function will use the Firehose client to write to your Firehose stream. Firehose will stream your data to Redshift. Quicksite will visualize your data in near-real-time.
Option C is incorrect. Kinesis Firehose does not have the capability to write directly to Aurora. You would have to write your stream data to S3 then write a Lambda function, triggered on each write, to consume the data stream and then write the stream data to your Aurora data store. You could also use the Amazon Database Migration service to move your data from S3 to Aurora. Also, you would have to write custom code to record the before-change information.
Option D is incorrect. Kinesis Data Streams does not have the capability to write directly to Aurora. You would have to write a Kinesis consumer client using the Kinesis Consumer Library (KCL) to consume the data stream and then write the stream data to your Aurora data store. Also, you would have to write custom code to record the before-change information.
Reference:
Please see the Amazon DynamoDB developer guide titled Capturing Table Activity with DynamoDB Streams
(https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html#Streams.Processing), the Medium.com article titled Data Transfer Dynamodb to Redshift
 (https://medium.com/@ananthsrinivas/data-transfer-dynamodb-to-redshift-5424d7fdf673), the Amazon Redshift overview page (https://aws.amazon.com/redshift/), the AWS Database blog titled Stream data into an Aurora PostgreSQL Database using AWS DMS and Amazon Kinesis Data Firehose (https://aws.amazon.com/blogs/database/stream-data-into-an-aurora-postgresql-database-using-aws-dms-and-amazon-kinesis-data-firehose/), the AWS Database blog titled Capturing Data Changes in Amazon Aurora Using AWS Lambda
 (https://aws.amazon.com/blogs/database/capturing-data-changes-in-amazon-aurora-using-aws-lambda/), the Kinesis Data Firehose overview page (https://aws.amazon.com/kinesis/data-firehose/), and the Kinesis Data Streams overview page (https://aws.amazon.com/kinesis/data-streams/)

Option A is incorrect because this implementation would be very inefficient. Also, you would be writing logic that the KPL gives you in its PutRecords operation.
Option B is incorrect. While Kinesis Data Streams does synchronously replicate your data across three availability zones, this capability would not give you the opportunity to recover from failed record puts into the stream since the failed records would not be replicated across the three availability zones.
Option C is correct. You would use the Kinesis Producer Library (KPL) PutRecords method in your KPL code to send click-stream records into your Kinesis Data Streams stream. The KPL PutRecords automatically adds any failed records back into the KPL buffer so it can be retried.
Option D is incorrect. The KPL PutRecords automatically adds any failed records back into the KPL buffer so it can be retried. You don’t need to implement retry logic in your code since the failed record is placed back into the KPL buffer. Your normal buffer processing logic will process the KPL buffer data without changes needed for retry.
Reference:
Please see the Amazon Kinesis Streams developer guide titled KPL Key Concepts
(https://docs.aws.amazon.com/streams/latest/dev/kinesis-kpl-concepts.html), the Amazon Kinesis Streams developer guide titled Developing Producers Using the Amazon Kinesis Producer Library (https://docs.aws.amazon.com/streams/latest/dev/developing-producers-with-kpl.html), the Amazon Kinesis Streams developer guide titled KPL Retries and Rate Limiting (https://docs.aws.amazon.com/streams/latest/dev/kinesis-producer-adv-retries-rate-limiting.html), the AWS Big Data blog titled Implementing Efficient and Reliable Producers with the Amazon Kinesis Producer Library
(https://aws.amazon.com/blogs/big-data/implementing-efficient-and-reliable-producers-with-the-amazon-kinesis-producer-library/), the AWS Real-time Analytics on AWS overview page (https://aws.amazon.com/big-data/real-time-analytics-featured-partners/), and the AWS Big Data blog titled Create real-time clickstream sessions and run analytics with Amazon Kinesis Data Analytics, AWS Glue, and Amazon Athena (https://aws.amazon.com/blogs/big-data/create-real-time-clickstream-sessions-and-run-analytics-with-amazon-kinesis-data-analytics-aws-glue-and-amazon-athena/)

Option A is incorrect. This data collection system architecture is better suited to batch consumption of stream data. Crawling the S3 data using Glue and then using a Glue job to write the data to an S3 data lake to then be queried by Athena would not allow you to produce real-time analytics. While Glue can process micro-batches, it does not handle streaming data.
Option B is correct. You can use a Kinesis Data Firehose stream to ingest the IoT data, then analyze and filter your data with Kinesis Data Analytics, then direct the analyzed data to another Kinesis Data Firehose stream to load the data into your data warehouse in RedShift. Finally, use QuickSight to produce your visualization and dashboard for your management team.
Option C is incorrect. This type of data collection infrastructure is best used for streaming transactional data from existing relational data stores. There is no need for an RDS instance in this data collection system since the data is transitory in nature.
Option D is incorrect. Kinesis Data Analytics cannot write directly to S3; it only writes to a Kinesis data stream, a Kinesis Data Firehose delivery stream, or a Lambda function.
Reference:
Please see the Amazon Kinesis Data Analytics for SQL Applications developer guide titled Configuring Application Output
(https://docs.aws.amazon.com/kinesisanalytics/latest/dev/how-it-works-output.html), the AWS Streaming Data page titled What is Streaming Data? (https://aws.amazon.com/streaming-data/), the AWS Database Migration Service FAQs (https://aws.amazon.com/dms/faqs/), the Amazon Kinesis Data Analytics FAQs (https://aws.amazon.com/kinesis/data-analytics/faqs/), the Amazon Kinesis Data Streams FAQs (https://aws.amazon.com/kinesis/data-streams/faqs/), the Amazon Kinesis Data Firehose developer guide titles What is Amazon Kinesis Data Firehose? (https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html#data-flow-diagrams), the AWS Glue developer guide titled AWS Glue Concepts (https://docs.aws.amazon.com/glue/latest/dg/components-key-concepts.html), and the Amazon Kinesis Data Firehose FAQs (https://aws.amazon.com/kinesis/data-firehose/faqs/)

Option A is incorrect. Apache Kafka/Amazon MSK allows you to process streaming data. It guarantees the correct order of delivery of your data messages, but it uses the “at-least-once” delivery method. At-least-once delivery means that the message will not be lost, but the message may be delivered to a consumer more than once.
Option B is correct. SQS in the FIFO mode guarantees the correct order of delivery of your data messages and it uses the “exactly-once” delivery method. Exactly-once means that all messages will be delivered exactly one time. No message losses, no duplicate data.
Option C is incorrect. SQS in the Standard mode does not guarantee the correct order of delivery of your data messages and it uses the “at-least-once” delivery method. At-least-once delivery means that the message will not be lost, but the message may be delivered to a consumer more than once.
Option D is incorrect. Kinesis Data Firehose does not guarantee the correct order of delivery of your data messages and it uses the “at-least-once” delivery method. At-least-once delivery means that the message will not be lost, but the message may be delivered to a consumer more than once.
Option E is incorrect. Kinesis Data Streams guarantees the correct order of delivery of your data messages, but it uses the “at-least-once” delivery method. At-least-once delivery means that the message will not be lost, but the message may be delivered to a consumer more than once.
Option F is correct. DynamoDB Streams guarantees the correct order of delivery of your data messages and it uses the “exactly-once” delivery method. Exactly-once means that all messages will be delivered exactly one time. No message losses, no duplicate data.
Reference:
Please see the Amazon Managed Streaming for Apache Kafka (Amazon MSK) overview page (https://aws.amazon.com/msk/), the Amazon Simple Queue Service developer guide titled Amazon SQS Standard Queues (https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html), the Amazon Simple Queue Service developer guide titled Amazon SQS FIFO (First-In-First-Out) Queues (https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html), the Amazon DynamoDB developer guide titled Capturing Table Activity with DynamoDB Streams (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html), the Amazon Kinesis Data Streams developer guide titled Handling Duplicate Records (https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html), the Amazon Kinesis Data Firehose FAQs (https://aws.amazon.com/kinesis/data-firehose/faqs/), and the Amazon Kinesis Data Streams FAQs (https://aws.amazon.com/kinesis/data-streams/faqs/)

Option A is incorrect. Neptune is a graph database engine optimized for storing billions of relationships and querying the graph data. Graph databases like Neptune are best leveraged for use cases like social networking, recommendation engines, and fraud detection, where you need to create relationships between data and quickly query these relationships. Your application is more operational in nature and therefore requires a database that fits that profile.
Option B is incorrect. While RDS is operational in nature, it is bounded by instance and storage size limits. Also, while offering a multi-availability zone (multi-AZ) capability, RDS does not scale globally as easily as DynamoDB. Therefore, DynamoDB is a better choice for your global availability requirements.
Option C is correct. DynamoDB offers single-digit millisecond latency at scale. It also scales horizontally for high performance at any size data store. Finally, DynamoDB offers global tables for multi-region replication of your data, which you’ll need for your globally dispersed user base and ski resort locations.
Option D is incorrect. ElastiCache is an in-memory caching system that, alone, would not have the persistence needed for your system.
Option E is incorrect. Redshift is a columnar storage database best used for data warehouse use cases. Since your application requires an operational data store, Redshift would not be the correct choice.
Option F is incorrect. S3 is used for structured and unstructured data. Querying S3 using Athena or Redshift Spectrum allow for relatively quick queries, but not fast enough for an operational application like your ski resort mobile application requirements.
Reference:
Please see the Amazon DynamoDB FAQs (https://aws.amazon.com/dynamodb/faqs/), the Amazon Neptune overview page (https://aws.amazon.com/neptune/), the Amazon DynamoDB developer guide titled Global Tables: Multi-Region Replication with DynamoDB (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html), the Amazon RDS FAQs (https://aws.amazon.com/rds/faqs/), the Amazon S3 FAQs (https://aws.amazon.com/s3/faqs/), the Amazon Redshift FAQs (https://aws.amazon.com/redshift/faqs/), and the Amazon ElastiCache FAQs (https://aws.amazon.com/elasticache/faqs/)

Option A is incorrect. While Kinesis Data Streams is the appropriate streaming solution for gathering the streaming player data and loading it onto your EMR cluster, then using Spark Streaming to transform the data into a format that is efficiently stored in ElastiCache Redis. There is no need for DynamoDB based on your data access and retrieval patterns for your application since your leaderboard application data is transient.
Option B is incorrect. Streaming your player data from Kinesis Data Firehose straight to S3 without any caching or transformation won’t give you your leaderboard functionality.
Option C is incorrect. While Kinesis Data Streams is the appropriate streaming solution for gathering the streaming player data and loading it onto your EMR cluster, then using Spark Streaming to transform the data into a format that is efficiently stored in ElastiCache. The Memcached version of ElastiCache does not allow you to easily implement the leaderboard functionality that ElastiCache Redis gives you. So this option is much less efficient.
Option D is correct. Kinesis Data Streams is the appropriate streaming solution for gathering the streaming player data and loading it onto your EMR cluster, then using Spark Streaming to transform the data into a format that is efficiently stored in ElastiCache Redis. You can use the Redis INCR and DECR functions to keep track of user points and the Redis Sorted Set data structure to maintain the leader list sorted by player. You can maintain your real-time ranked leader list by updating each user’s score each time it changes.
Option E is incorrect. Based on your data access and retrieval patterns, there is no need for an S3 storage layer in this architecture.
Reference:
Please see the Amazon ElastiCache for Redis overview page (https://aws.amazon.com/elasticache/redis/), the Amazon ElastiCache for Redis User Guide (https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/redis-ug.pdf), the RedisLabs Leaderboards page (https://redislabs.com/redis-enterprise/use-cases/leaderboards/), the AWS Database Blog page titled Build a real-time gaming leaderboard with Amazon ElastiCache for Redis (https://aws.amazon.com/blogs/database/building-a-real-time-gaming-leaderboard-with-amazon-elasticache-for-redis/), and the Amazon ElastiCache for Redis user guide titled Common ElastiCache Use Cases and How ElastiCache Can Help (https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/elasticache-use-cases.html)

Option A is incorrect. While Kinesis Data Streams can be used to ingest IoT sensor data, it is an unnecessary component in your data collection architecture since IoT Core can do the sensor data ingestion task.
Option B is incorrect. While Kinesis Data Firehose can be used to ingest IoT sensor data, it is an unnecessary component in your data collection architecture since IoT Core can do the sensor data ingestion task.
Option C is incorrect. This data collection architecture has unnecessary components. While Kinesis Data Streams can be used to ingest IoT sensor data, it is an unnecessary component in your data collection architecture since IoT Core can do the sensor data ingestion task. RedShift is not the optimal data store for your IoT sensor data in this scenario. RedShift is better suited for storing structured data, but you have both structured and unstructured data. 
Option D is correct. The simplest data collection architecture that meets your data lifecycle and usage patterns uses IoT Core to ingest the sensor data. Also, IoT Core is used to run a rules-based filtering and transformation set of functions. IoT Core then streams the sensor data to S3 where you house your data lake. You then use Athena to run your ad-hoc queries on your sensor data, taking advantage of Athena’s serverless query service so that you only pay for the service when you use it.
Option E is incorrect. This data collection architecture gives you a simple process flow to get your sensor data into your S3 data lake. However, it lacks the rules-based filtering and transformation set of functions. You would have to implement these functions in a Lambda function, which would make this data collection architecture less efficient than using the IoT Core service to address this requirement.
Reference:
Please see the AWS IoT Core overview page (https://aws.amazon.com/iot-core/), the AWS Big Data blog titled Integrating IoT Events into Your Analytic Platform
(https://aws.amazon.com/blogs/big-data/integrating-iot-events-into-your-analytic-platform/), the blog titled Athena Vs Redshift: An Amazonian Battle Or Performance And Scale (https://blog.panoply.io/an-amazonian-battle-comparing-athena-and-redshift), and the Amazon Athena overview page (https://aws.amazon.com/athena/)

Option A is correct. Redshift is the best choice for your data warehouse. Also, when configuring your Redshift warehouse, if you have less than 10 TBs of data DC2 nodes are the best price performer. However, if you expect your data to rapidly grow, as in this scenario, then RA3 nodes are the most cost effective choice.
Option B is incorrect. Redshift is the best choice for your data warehouse. Also, when configuring your Redshift warehouse, if you have less than 10 TBs of data DC2 nodes are the best price performer. However, if you expect your data to rapidly grow, as in this scenario, then RA3 nodes are the most cost effective choice.
Option C is incorrect. S3 is not a good choice for a data warehouse. Also, you do not choose the volume type when you create your S3 buckets. 
Option D is incorrect. S3 is not a good choice for a data warehouse. Also, you do not choose the volume type when you create your S3 buckets.
Option E is incorrect. Redshift is the best choice for your data warehouse. Also, when configuring your Redshift warehouse, if you have less than 10 TBs of data DC2 nodes are the best price performer. However, if you expect your data to rapidly grow, as in this scenario, then RA3 nodes are the most cost effective choice. The DS2 node type is now classified as a legacy node choice by Amazon. Amazon no longer recommends that you build new Redshift data warehouses using the DS2 node type.
Reference:
Please see the Data Lakes and Analytics on AWS page titled What is a Data Lake? (https://aws.amazon.com/big-data/datalakes-and-analytics/what-is-a-data-lake/), the Amazon Redshift Pricing page (https://aws.amazon.com/redshift/pricing/) and the World Health Organization Global Health Observatory data repository page (https://apps.who.int/gho/data/node.home)

Option A is incorrect. Since you are looking to use the CityDistrict and CrimeDate to retrieve your dashboard data, the combination of CityDistrict and CrimeDate won’t always be unique. A global secondary index is the best choice for this use case since the combination of primary key attributes does not require unique values.
Option B is correct. Since you are looking to use the CityDistrict and CrimeDate to retrieve your dashboard data, the combination of CityDistrict and CrimeDate won’t always be unique. A global secondary index is the best choice for this use case since the combination of primary key attributes does not require unique values.
Option C is incorrect. Scanning the entire table and then using the ProjectionExpression parameter to filter the returned data will be a much more expensive operation than using a secondary index.
Option D is incorrect. Scanning a secondary index and then using the ProjectionExpression parameter to filter the returned data will be a much more expensive operation than just using a secondary index. Also, the scenario doesn’t state that you have created a secondary index, so how could you scan it if you haven’t yet created it?
Reference:
Please see the Amazon DynamoDB developer guide titled Using Global Secondary Indexes in DynamoDB (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html), the Amazon DynamoDB developer guide titled Working with Scans in DynamoDB (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Scan.html), and the Amazon DynamoDB developer guide titled Local Secondary Indexes (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/LSI.html)

Option A is incorrect. With the KEY distribution strategy the Redshift leader node distributes the rows relative to the values in one column. This strategy is good for situations where you need to do joins across tables, but since your initial table sizes are small and will grow over time, there are better performing and more cost effective strategies you can use.
Option B is incorrect. With the EVEN distribution strategy, the Redshift leader node distributes the rows of your tables across the compute node slices using a round robin approach. This is not the best strategy if your tables need to participate in joins. This may be a good strategy for your tables once your tables increase in size as your new business grows, but since your initial table sizes are small, there are better performing and more cost effective strategies you can use.
Option C is incorrect. With the ALL distribution strategy, the Redshift leader node distributes the entire table to every compute node. Thus multiplying the storage required by the number of compute nodes you have configured in your Redshift cluster. This strategy is a good choice for tables that are not updated often and that are not updated with large change sets. This may be a good choice when you first create your tables, but since you expect rapid growth in your tables, this choice would not give you the optimum performance and cost over the life of your Redshift cluster.
Option D is correct. The AUTO distribution strategy Redshift assigns the best distribution strategy based on the table size. It then changes the distribution strategy as the changing table activity and size demands. So Redshift may initially assign an ALL distribution strategy to your table since it is small, then change the distribution strategy to EVEN as your table grows in size. When Redshift changes the distribution strategy the change happens very quickly (a few seconds) in the background.
Reference:
Please see the Amazon Redshift Database developer guide titled Choosing a Distribution Style (https://docs.aws.amazon.com/redshift/latest/dg/t_Distributing_data.html), the Amazon Redshift Database developer guide titled Data Warehouse System Architecture (https://docs.aws.amazon.com/redshift/latest/dg/c_high_level_system_architecture.html), and the Amazon Redshift Cluster Management guide titled Amazon Redshift Management Overview (https://docs.aws.amazon.com/redshift/latest/mgmt/overview.html)

Option A is incorrect. You do not need to use a JDBC connector to crawl S3 data stores. Your crawler can crawl S3 data stores through the native S3 interface.
Option B is correct. For data stores such as Redshift and RDS, you need to use a JDBC connector to crawl these types of data stores. If the username you provide to your JDBC connection does not have the appropriate permissions to access the data store, the connection will fail and Glue will not produce the inferred schema for that data store.
Option C is incorrect. Glue automatically runs its built-in classifiers if none of your custom classifiers return a certainty number equal to 1.
Option D is incorrect. You do not need to use a JDBC connector to crawl DynamoDB data stores. Your crawler can crawl DynamoDB data stores through the native DynamoDB interface.
Reference:
Please see the AWS Glue developer guide titled Populating the AWS Glue Data Catalog (https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html), the AWS Glue developer guide titled Adding Classifiers to a Crawler (https://docs.aws.amazon.com/glue/latest/dg/add-classifier.html)

Option A is incorrect. Redshift is a good choice for your partner interaction data because it requires sub-second response times. S3 Standard is a good choice for your partner metadata because it offers good response times (in minutes) at a much lower cost than Redshift. S3 Intelligent-Tiering is not the best choice for your former partner data because it is less cost optimized than the S3 Glacier tier for this type of infrequently accessed data. For example, when a data object is retrieved from the S3 Intelligent-Tier infrequently accessed tier, that object is moved to the frequently accessed tire. It then stays in the frequently accessed tier for 30 days.
Option B is incorrect. Using Redshift for all of your data storage and relying on cluster node types to optimize storage costs based on frequency is not a best practice use case for Redshift. This option will cost much more to maintain than the option with Redshift, S3 Standard, and S3 Glacier.
Option C is correct. Redshift is a good choice for your partner interaction data because it requires sub-second response times. S3 Standard is a good choice for your partner metadata because it offers good response times (minutes) at a much lower cost than Redshift. S3 Glacier is a good choice for your former partner data (hours) because the Glacier tier of S3 is the most inexpensive option for storing data like this that has very infrequent access and response times of an hour can be tolerated.
Option D is incorrect. Using RDS Aurora for your partner interaction data for this inherently data analytics warehouse type of use case is highly inefficient. Also, Redshift’s compressed, partitioned columnar storage format of your database tables optimizes your solution (and response times) for analytic query performance. This (analytics access) is listed as a requirement in the scenario.
Reference:
Please see the Amazon Redshift features page (https://aws.amazon.com/redshift/features/), the Amazon Redshift FAQs page (https://aws.amazon.com/redshift/faqs/), the Amazon Simple Storage Service developer guide titled Amazon S3 Storage Classes (https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-class-intro.html), the Amazon Redshift Pricing page (https://aws.amazon.com/redshift/pricing/), the Amazon Redshift Cluster Management Guide titled Amazon Redshift Clusters (https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html), the Amazon Aurora overview page (https://aws.amazon.com/rds/aurora/), and the Amazon Redshift Database developer guide titled Columnar Storage (https://docs.aws.amazon.com/redshift/latest/dg/c_columnar_storage_disk_mem_mgmnt.html)

Option A is incorrect. S3 BFS (Block File System) is a legacy storage system and is no longer recommended by AWS. One reason: it can cause race conditions within your EMR cluster.
Option B is incorrect. S3 EMRFS is good for Hadoop file systems that need fast access for analytics, however the HDFS Hadoop file system is faster. Also, choosing HDFS for your data sets that require persistence is not a good option since HDFS is ephemeral, its storage is reclaimed when your EMR cluster is terminated.
Option C is correct. Use the HDFS Hadoop file system for your hot data sets that are temporary in nature, use the S3 EMRFS Hadoop file system for less-hot data sets that require persistence.
Option D is incorrect. S3 BFS (Block File System) is a legacy storage system and is no longer recommended by AWS. Choosing HDFS for your data sets that require persistence is not a good option since HDFS is ephemeral, its storage is reclaimed when your EMR cluster is terminated.
Reference:
Please see the Amazon EMR FAQs page (https://aws.amazon.com/emr/faqs/), the Amazon EMR Management guide titled Working with Storage and File Systems (https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-file-systems.html), the Amazon EMR Features page (https://aws.amazon.com/emr/features/), and the Amazon EMR Management guide titled Supported Applications and Features (https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-applications.html)

Option A is correct. EMR Transient Clusters automatically terminate after all steps are complete. This will lower your operational costs by not leaving the EMR nodes running when they are not in use.
Option B is incorrect. EMR Long-running clusters must be manually terminated when they are no longer needed, therefore this option will not give you the same cost effectiveness as a Transient Cluster.
Option C is incorrect. EMR Core Nodes run HDFS and therefore if a Code Node is terminated through the spot instance process, you will lose your data stored in HDFS.
Option D is correct. EMR Task Nodes do not store data in HDFS. If you lose your Task Node through the spot instance process you will not lose data stored on HDFS.
Option E is incorrect. When you launch an EMR cluster via the AWS CLI, the default is to have auto-terminate disabled. This will in effect create a long running cluster.
Reference:
Please see the Amazon Redshift Database developer guide titled Loading Data from Amazon EMR (https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html), the Amazon EMR Management Guide titled Benefits of Using Amazon EMR (https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-overview-benefits.html), the Amazon EMR Management Guide titled Configuring a Cluster to Auto-Terminate or Continue (https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-longrunning-transient.html), and the Amazon EMR Management Guide titled Cluster Configuration Guidelines and Best Practices (https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html)

Option A is incorrect. JSON is not the most efficient format to use when using the COPY command to load data files into Redshift. Apache Parquet and ORC are better choices for loading data files into Redshift. Parquet and ORC are columnar data formats that allow you to copy your data more efficiently and cost-effectively into Redshift.
Option B is correct. Apache Parquet and ORC are better choices for loading data files into Redshift. Parquet and ORC are columnar data formats that allow you to copy your data more efficiently and cost-effectively into Redshift.
Option C is incorrect. RDS Aurora is not a good choice for housing your data warehouse. Redshift is better suited for data warehouse analytic applications.
Option D is incorrect. CSV is not the most efficient format to use when using the COPY command to load data files into Redshift. Apache Parquet and ORC are better choices for loading data files into Redshift. Parquet and ORC are columnar data formats that allow you to copy your data more efficiently and cost-effectively into Redshift.
Reference:
Please see the AWS What’s New article titled Amazon Redshift Can Now COPY from Parquet and ORC File Formats (https://aws.amazon.com/about-aws/whats-new/2018/06/amazon-redshift-can-now-copy-from-parquet-and-orc-file-formats/), the Amazon QuickSight user guide titled Creating a Dataset from a Database (https://docs.aws.amazon.com/quicksight/latest/user/create-a-database-data-set.html), and the Amazon Redshift Database developer guide titled COPY from Columnar Data Formats (https://docs.aws.amazon.com/redshift/latest/dg/copy-usage_notes-copy-from-columnar.html)

Option A is correct. AWS Glue allows you to create workflows using extract, transform, and load (ETL) activities using as many crawlers, jobs, and triggers nas you need. The Glue job that runs at the completion of the schema update uses the Redshift COPY command to load the trade data into Redshift.
Option B is incorrect. AWS Glue allows you to create workflows using extract, transform, and load (ETL) activities using as many crawlers, jobs, and triggers nas you need. The Glue job that runs at the completion of the schema update should use the Redshift COPY command to load the trade data into Redshift. The UNLOAD command is used to retrieve data from Redshift, not to move data into Redshift.
Option C is incorrect. Adding cron jobs to the workflow over complicates the data processing solution. The use of cron jobs is unnecessary since Glue workflows can orchestrate your entire workflow.
Option D is incorrect. AWS Glue allows you to create workflows using extract, transform, and load (ETL) activities using as many crawlers, jobs, and triggers nas you need. The Glue job that runs at the completion of the schema update should use the Redshift COPY command to load the trade data into Redshift. There is no PUT command to move data to or from Redshift. The commands used to move data to and from Redshift are COPY and UNLOAD.
Reference:
Please see the AWS Glue developer guide titled Overview of Workflows in AWS Glue (https://docs.aws.amazon.com/glue/latest/dg/workflows_overview.html), the AWS Glue developer guide titled Performing Complex ETL Activities Using Workflows in AWS Glue (https://docs.aws.amazon.com/glue/latest/dg/orchestrate-using-workflows.html), and the AWS Glue developer guide titled Moving Data to and from Amazon Redshift (https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-redshift.html)

Option A is incorrect. This Lambda based data processing solution would work but it is less efficient and will take longer to run than using Step Functions state machines to run the several ETL transformation jobs in parallel.
Option B is correct. Using Step Functions state machines to orchestrate this data processing workflow allows you to take advantage of processing all of your transformation ETL jobs in parallel. This makes your data processing workflow efficient and allows it to fit within your tight batch window.
Option C is incorrect. It is less efficient and will take longer to run than using Step Functions state machines to run the several ETL transformation jobs in parallel. Also, using a CSV file to load data into your Redshift cluster is slower and less efficient than using either the ORC or parquet formats. Finally, you use the COPY command to load data into your Redshift cluster, not the UNLOAD command.
Option D is incorrect. You use the COPY command to load data into your Redshift cluster, not the UNLOAD command.
Reference:
Please see the AWS Glue developer guide titled Performing Complex ETL Activities Using Workflows in AWS Glue (https://docs.aws.amazon.com/glue/latest/dg/orchestrate-using-workflows.html), the AWS Big Data blog titled Orchestrate multiple ETL jobs using AWS Step Functions and AWS Lambda (https://aws.amazon.com/blogs/big-data/orchestrate-multiple-etl-jobs-using-aws-step-functions-and-aws-lambda/), the AWS Glue developer guide titled Moving Data to and from Amazon Redshift (https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-redshift.html), the AWS announcement titled Amazon Redshift Can Now COPY from Parquet and ORC File Formats (https://aws.amazon.com/about-aws/whats-new/2018/06/amazon-redshift-can-now-copy-from-parquet-and-orc-file-formats/), and the AWS Big Data blog titled Orchestrate Amazon Redshift-Based ETL workflows with AWS Step Functions and AWS Glue (https://aws.amazon.com/blogs/big-data/orchestrate-amazon-redshift-based-etl-workflows-with-aws-step-functions-and-aws-glue/)

Option A is incorrect. Apache Oozie is a popular workflow scheduler for Hadoop jobs, but it has limited integration with AWS services and requires XML configuration which makes using it more complex than using Step Functions, thereby increasing the cost of the solution.
Option B is incorrect. Apache Airflow integrates with several AWS services, but it requires your client to run it on a server that they’ll also have to maintain. This will increase the cost compared to using Step Functions.
Option C is correct. Using Step Functions will allow your client to run their workflow as a serverless pipeline that runs their Spark ETL jobs using the Apache Livy REST service. This will allow for very quick development time and pay-as-you-use costs, which will be far less expensive than the other options.
Option D is incorrect. You could use Lambda to string together a pipeline. While this approach gives you a serverless pipeline, it lacks the job flow coordination features that Step Functions has. Your client would have to write these capabilities themselves, increasing the cost of their solution.
Option E is incorrect. AWS Database Migration Service (DMS) is primarily used to migrate databases to AWS. Your client could use DMS to load data from existing databases into S3 and then use Glue to run Spark ETL jobs, but this is not what the scenario describes.
Reference:
Please see the AWS Big Data blog titled Orchestrate Apache Spark applications using AWS Step Functions and Apache Livy (https://aws.amazon.com/blogs/big-data/orchestrate-apache-spark-applications-using-aws-step-functions-and-apache-livy/), the AWS News blog titled New – Using Step Functions to Orchestrate Amazon EMR Workloads (https://aws.amazon.com/blogs/aws/new-using-step-functions-to-orchestrate-amazon-emr-workloads/), the Apache Livy overview page (https://livy.apache.org/), and the AWS Big Data blog titled Load ongoing data lake changes with AWS DMS and AWS Glue (https://aws.amazon.com/blogs/big-data/loading-ongoing-data-lake-changes-with-aws-dms-and-aws-glue/)

Option A is incorrect. CloudTrail does not have event rules.
Option B is incorrect. While this would work, it is not as efficient as having automated retry logic via a Lambda function.
Option C is incorrect. CloudTrail does not have event rules.
Option D is correct. Using SNS to trigger a Lambda function on failure allows you to use automated retry logic in your data processing solution.
Option E is incorrect. This option would require you to build some mechanism to allow Spark jobs to be initiated via an SNS topic. This would not be as simple as writing a Lambda function and having it triggered by the SNS topic.
Reference:
Please see the Amazon Simple Notification Service developer guide titled Using Amazon SNS for system-to-system messaging with an AWS Lambda function as a subscriber (https://docs.aws.amazon.com/sns/latest/dg/sns-lambda-as-subscriber.html), the AWS Big Data blog titled Analyzing Data in S3 using Amazon Athena (https://aws.amazon.com/blogs/big-data/analyzing-data-in-s3-using-amazon-athena/), and the AWS Lambda developer guide titled Using AWS Lambda with Amazon SNS (https://docs.aws.amazon.com/lambda/latest/dg/with-sns.html)

Option A is correct. With CloudTrail you can configure your trail to use SNS topics. You use the aws cloudtrail create-trail CLI command to create the SNS topic. When events occur you use a Lambda function triggered by an SQS queue which receives the alert. The Lambda function filters for the events for which you are concerned. If you don’t filter the events you’ll receive alerts for every event generated by CloudTrail.
Option B is incorrect. CloudWatch is not the service to use when you are monitoring API calls. CloudTrail is the service to use for this purpose.
Option C is incorrect. This answer lacks the linkage of the SNS topic with the logging of events in the EMR logs.
Option D is incorrect. This answer lacks the filtering of CloudTrail messages. If you don’t filter the events you’ll receive alerts for every event generated by CloudTrail. This would make it hard for you to act on the events for which you are concerned.
Reference:
Please see the Amazon EMR Management guide titled Logging Amazon EMR API Calls in AWS CloudTrail (https://docs.aws.amazon.com/emr/latest/ManagementGuide/logging_emr_api_calls.html), the AWS CloudTrail user guide titled Configuring Amazon SNS Notifications for CloudTrail (https://docs.aws.amazon.com/awscloudtrail/latest/userguide/configure-sns-notifications-for-cloudtrail.html), the AWS CLI Command Reference titled create-trail (https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/create-trail.html), the AWS CloudTrail user guide titled Configuring CloudTrail to Send Notifications (https://docs.aws.amazon.com/awscloudtrail/latest/userguide/configure-sns-notifications-for-cloudtrail.html#configure-cloudtrail-to-send-notifications), and the Amazon EMR Management guide titled Conceptual Overview of Amazon EMR Integration with Lake Formation (https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-lf-conceptual.html)

Option A is incorrect. You could write an AWS Batch job that uses the dirtyjson library to clean your JSON, but you would have to spend development time building the code that leverages the dirtyjson library, costing you development time.
Option B is incorrect. The Spark DataFrame API requires a schema to know before you load your data. It also doesn’t handle cleaning up data as well as the Glue DynamicFrame class. The Spark DataaFrame makes two passes over the JSON dataset, costing you operational time and performance costs. Also, setting up an EMR cluster to run your job will cost you development time and you’ll have to pay for EC2 instances to run your EMR cluster, costing you infrastructure expenses.
Option C is incorrect. The json.load and json.loads libraries would not give you the capability to clean your semi-structured data. These libraries give you the capability to convert your JSON data into python objects. You would then have to write custom code to actually clean up the inconsistencies.
Option D is correct. The Glue DynamicFrame extension requires no schema; Glue determines the schema in real-time while handling schema inconsistencies using the resolveChoice, unnest, split_rows, relationalize, and other transforms.
Reference:
Please see the RealPython article titled Working with JSON Data in Python (https://realpython.com/python-json/), the pip project description of dirtyjson (https://pypi.org/project/dirtyjson/), the AWS Batch API Reference (https://docs.aws.amazon.com/batch/latest/APIReference/batch-api.pdf), the AWS Glue developer guide titled DynamicFrame Class (https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-crawler-pyspark-extensions-dynamic-frame.html), and the Spark SQL guide titled Spark SQL, DataFrames and Datasets Guide (https://spark.apache.org/docs/latest/sql-programming-guide.html)

Option A is incorrect. This approach will be too slow in transforming and then moving the request data to the transformed bucket. Starting up an EMR cluster and then submitting the Spark job will take far longer than using a long running EMR cluster.
Option B is incorrect. A Spark job running in Glue is batch oriented. You can only schedule ETL jobs at 5 minute intervals or greater. This option will be far slower than using a long running EMR cluster.
Option C is incorrect. This approach will be too slow in transforming and then moving the request data to the transformed bucket. Starting up an EMR cluster and then submitting the EMR Steps API job will take far longer than using a long running EMR cluster.
Option D is correct. A Livy server on a long running EMR cluster will handle requests much faster than starting an EMR cluster with each request or using an SQS polling structure.
Reference:
Please see the AWS Glue FAQs (https://aws.amazon.com/glue/faqs/), the Amazon EMR Release Guide titled Apache Livy (https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-livy.html), the AWS Big Data blog titled Build a Concurrent Data Orchestration Pipeline Using Amazon EMR and Apache Livy (https://aws.amazon.com/blogs/big-data/build-a-concurrent-data-orchestration-pipeline-using-amazon-emr-and-apache-livy/), and the Apache Livy Getting Started guide (https://livy.incubator.apache.org/get-started/)

Option A is correct. You are looking for the historical prevalence of thinness data for each country around the world. This is a perfect use of geospatial charts, where you want to show differences in data values across a geographical map.
Option B is incorrect. Use bubble charts to compare values for items in a dimension. A bubble is displayed on the chart at the point where the measures for an item intersect within a dimension. 
Option C is incorrect. Heat maps are used to show how two dimensions intersect. You use colors to show the range of distribution. You are looking to show the distribution of data values across a geographic map.
Option D is incorrect. Use tree maps to show how one or two data points in a dimension using rectangles. Every rectangle displayed on the tree shows one data point in the dimension. You are looking to show the distribution of data values across a geographic map.
Reference:
Please see the Amazon QuickSight user guide titled Using Tree Maps (https://docs.aws.amazon.com/quicksight/latest/user/tree-map.html), the Amazon QuickSight user guide titled Using Heat Maps (https://docs.aws.amazon.com/quicksight/latest/user/heat-map.html), the Amazon QuickSight user guide titled Using Geospatial Charts (Maps) (https://docs.aws.amazon.com/quicksight/latest/user/geospatial-charts.html), the Amazon QuickSight user guide titled Using Scatter Plots (https://docs.aws.amazon.com/quicksight/latest/user/scatter-plot.html), the Amazon QuickSight overview page (https://aws.amazon.com/quicksight/?c=a&sec=srv), and the World Health Organization’s Global Health Observatory data repository (https://apps.who.int/gho/data/view.main.NCDBMIMINUS210-19Cv?lang=en)

Option A is incorrect. This option does not give you the ability to analyze your football data in near real-time because you are transforming the data into ORC format, storing it on S3, and then attempting to query it across multiple ORC files.
Option B is correct. You can leverage a Lambda function together with Kinesis Data Firehose to transform your streaming football data prior to storage on the Elasticsearch cluster storage volumes. You can then use Elasticsearch together with Kibana to perform near real-time analytics on your streaming football data. 
Option C is incorrect. Kinesis Data Firehose doesn’t have the capability to write its streaming data to RDS. It can write streaming data to S3, Redshift, Elasticsearch, and Splunk
Option D is incorrect. This option does not give you the ability to analyze your football data in near real-time because you are transforming the data into parquet format, storing it on S3, and then attempting to query it across multiple parquet files.
Reference:
Please see the Amazon Elasticsearch Service FAQs (https://aws.amazon.com/elasticsearch-service/faqs/), the Amazon Athena FAQs (https://aws.amazon.com/athena/faqs/), the Kinesis Data Firehose overview page (https://aws.amazon.com/kinesis/data-firehose/), the Kinesis Data Streams overview page (https://aws.amazon.com/kinesis/data-streams/), the AWS Big Data blog titled Perform Near Real-time Analytics on Streaming Data with Amazon Kinesis and Amazon Elasticsearch Service (https://aws.amazon.com/blogs/big-data/perform-near-real-time-analytics-on-streaming-data-with-amazon-kinesis-and-amazon-elasticsearch-service/), the Kibana overview page (https://www.elastic.co/kibana), and the Wikipedia page on FIFA (https://en.wikipedia.org/wiki/FIFA)

Option A is incorrect. The actions listed in the Action part of the Statement are associated with the Effect of Allow, so these actions aren’t prevented unilaterally by the policy. The StringEquals condition controls the access.
Option B is incorrect. The actions listed in the Action part of the Statement are associated with the Effect of Allow, but those actions aren’t allowed unilaterally by the policy. The StringEquals condition controls the access.
Option C is correct. The StringEquals condition attempts to match dev or eng to the value of the department tag. If the department tag was not added to the EMR cluster or the department tag does not have the value of either dev or eng, then the policy does not apply and the user/group can’t perform the actions on the EMR cluster.
Option D is incorrect. The StringEquals condition attempts to match dev or eng to the value of the department tag. If the department tag has the value of either dev or eng, then the policy applies and the user/group can perform the actions on the EMR cluster.
Reference:
Please see the Amazon EMR management guide titled IAM Policies for Tag-Based Access to Clusters and EMR Notebooks (https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fine-grained-cluster-access.html), and the Amazon Elastic Map Reduce API reference titled Actions (https://docs.aws.amazon.com/emr/latest/APIReference/API_Operations.html)

Option A is correct. If a user adds a tag to the cluster to which their user policy allows access, they can circumvent your security policies. This policy prevents adding new tags to the EMR cluster that would open up access to users with access to resources with that tag.
Option B is incorrect. Adding any tag to your confidential EMR cluster won’t allow access to any user. It will only allow access to users who have a policy associated with their IAM user account that allows access to resources that allow access via that tag
Option C is correct. Removing the tags from your confidential EMR cluster will allow access to users even if they are not in the Quantitative Equity Group IAM group because the policy will no longer have any tags.
Option D is incorrect. The logic of this option is flawed. By removing a tag from your confidential EMR cluster, any user who is allowed access to resources that have that tag will be denied access to your confidential EMR cluster.
Option E is incorrect. The Deny AddTags/RemoveTags statement does not prevent users from creating new EMR clusters, nor does it prevent users from attempting to clone a new cluster from another.
Reference:
Please see the Amazon EMR management guide titled IAM Policies for Tag-Based Access to Clusters and EMR Notebooks (https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fine-grained-cluster-access.html), the Amazon Elastic Map Reduce API reference titled Actions (https://docs.aws.amazon.com/emr/latest/APIReference/API_Operations.html), the Amazon EMR management guide titled Tag Clusters (https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-tags.html), and the Amazon EMR management guide titled Adding Tags to an Existing Cluster (https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-tags-add.html)

Option A is incorrect. When you use SSE-S3 to encrypt your data, EMR first sends your data to S3, then S3 encrypts the data with a CMK. Your requirement is to encrypt the data before you send it to S3.
Option B is incorrect. When you use SSE-KMS to encrypt your data, EMR first sends your data to S3, then S3 encrypts the data with a CMK. Your requirement is to encrypt the data before you send it to S3.
Option C is correct. When you use CSE-KMS to encrypt your data, EMR first encrypts the data with a CMK, then sends it to Amazon S3 for storage. This meets your requirement of encrypting your data before you send it to S3.
Option D is incorrect. EMR does not have an encryption mode that uses SSE-C.
Reference:
Please see the AWS Big Data blog titled Best Practices for Securing Amazon EMR (https://aws.amazon.com/blogs/big-data/best-practices-for-securing-amazon-emr/), the AWS Key Management Service developer guide titled Encrypting data on the EMR file system (EMRFS) (https://docs.aws.amazon.com/kms/latest/developerguide/services-emr.html), the Amazon EMR Management guide titled Encryption Options (https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-data-encryption-options.html), and the blog titled HIPAA Data at Rest Encryption Requirements (https://www.zettaset.com/blog/hipaa-data-at-rest-encryption-requirements/)

Option A is incorrect. You can use AWS Shield to protect your retail website from distributed denial of service (DDoS) attacks, and Shield Advanced gives you a DDoS response team. However, Shield and Shield advanced won’t protect your PII credit card data from being exposed. You need to either encrypt your data or tokenize your customer’s PII data.
Option B is incorrect. You can use WAF to control the way traffic reaches your retail website by creating security rules that block common website attacks. However, WAF won’t protect your PII credit card data from being exposed. You need to either encrypt your data or tokenize your customer’s PII data.
Option C is correct. You can use tokenization instead of encryption when you only need to protect specific highly sensitive data for regulatory compliance requirements, such as PCI DSS.
Option D is incorrect. You can use GuardDuty to systematically monitor network traffic to detect anomalies in the behavior of your website users by using machine learning. However, GuardDuty won’t protect your PII credit card data from being exposed. You need to either encrypt your data or tokenize your customer’s PII data.
Option E is incorrect. Using KMS and encrypting your data in transit and at rest is more complex and costly than using tokenization on the specific PII data, the credit card data.
Reference:
Please see the AWS Big Data blog titled Best practices for securing sensitive data in AWS data stores (https://aws.amazon.com/blogs/database/best-practices-for-securing-sensitive-data-in-aws-data-stores/), the AWS WAF overview page (https://aws.amazon.com/waf/?nc=bc&pg=pr), the Wikipedia page titled Payment Card Industry Data Security Standard (https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard), the AWS GuardDuty overview page (https://aws.amazon.com/guardduty/), and the AWS Shield overview page (https://aws.amazon.com/shield/)

Option A is incorrect. IAM can be used to manage passwords for AWS user accounts, but it is not a good choice for managing parameters like database connection information, and you can’t take advantage of encryption of your parameters and secrets with IAM without additional work on your part. A parameter or secrets management service such as Secrets Manager is a better choice.
Option B is incorrect. Systems Manager Parameter Store is great for storing parameters and even passwords. It can encrypt all parameters it stores, but the Systems Manager Parameter Store does not have the capability to automatically rotate your database connection information.
Option C is incorrect. KMS encryption is an obvious choice for encrypting your data, but it does not have the parameter and secret management capabilities that Secrets Manager gives you.
Option D is correct. Secrets Manager gives you the capability to encrypt your parameters, randomly generate passwords, and automatically rotate your database connection information.
Reference:
Please see the AWS Secrets Manager FAQs (https://aws.amazon.com/secrets-manager/faqs/), the AWS Systems Manager FAQs (https://aws.amazon.com/systems-manager/faq/#Parameter_Store), the AWS Identity and Access Management user guide titled Managing Passwords (https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords.html), the Linux Academy article titled An Inside Look at AWS Secrets Manager vs Parameter Store (https://linuxacademy.com/blog/amazon-web-services-2/an-inside-look-at-aws-secrets-manager-vs-parameter-store/), and the AWS Security Blog titled Rotate Amazon RDS database credentials automatically with AWS Secrets Manager (https://aws.amazon.com/blogs/security/rotate-amazon-rds-database-credentials-automatically-with-aws-secrets-manager/)

Option A is incorrect. CloudTrail logs all API access to your cloud resources, but it does not give you the information you need to produce the Business Associate Addendum (BAA) HIPAA compliance report.
Option B is incorrect. CloudWatch logs many important metrics and alerts regarding your AWS resources and services, but  it does not give you the information you need to produce the Business Associate Addendum (BAA) HIPAA compliance report. Also, AWS Resource Access Manager gives you the ability to securely share AWS resources with another AWS account within your company, but it doesn’t allow you to monitor changes to your data lake S3 bucket ACLs and bucket policies for public read/write access violations.
Option C is correct. AWS Artifact gives you the capability to retrieve the Business Associate Addendum (BAA) HIPAA compliance report directly from AWS. Also, AWS Config monitors your AWS resource configuration changes. It allows you to take action or alert, using custom rules, on configuration changes that violate your policies.
Option D is incorrect. AWS Artifact gives you the capability to retrieve the Business Associate Addendum (BAA) HIPAA compliance report directly from AWS. However, AWS Resource Access Manager gives you the ability to securely share AWS resources with another AWS account or within your company, but it doesn’t allow you to monitor changes to your data lake S3 bucket ACLs and bucket policies for public read/write access violations.
Reference:
Please see the AWS Artifact FAQs (https://aws.amazon.com/artifact/faq/), the AWS Resource Access Manager overview page (https://aws.amazon.com/ram/?c=sc&sec=srv), the AWS Config overview page (https://aws.amazon.com/config/), and the AWS Security Blog titled How to Use AWS Config to Monitor for and Respond to Amazon S3 Buckets Allowing Public Access (https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/)

Option A is incorrect. This option is not the most cost effective; using DynamoDB instead of using your data lake S3 buckets to store the data adds another layer of complexity and data storage cost. Also, writing your compliance rules into a Lambda function is not as cost effective or scalable as using the AWS Macie service.
Option B is incorrect. This option is not cost effective because you would have to write your compliance rules into a Lambda function, which is not as cost effective or scalable as using the AWS Macie service.
Option C is correct. Use the AWS Macie service to guard against security violations by continuously scanning your S3 bucket data and your account settings. Macie uses machine learning to properly classify your PII data. Macie also monitors access activity for your data, looking for access abnormalities and data leaks.
Option D is incorrect. The AWS Macie service works with data stored in S3, not DynamoDB. Also this option is not the most cost effective; using DynamoDB instead of using your data lake S3 buckets to store the data adds another layer of complexity and data storage cost.
Reference:
Please see the AWS News blog titled New Amazon S3 Encryption and Security Features (https://aws.amazon.com/blogs/aws/new-amazon-s3-encryption-security-features/), the Amazon Macie overview page (https://aws.amazon.com/macie/), and the Amazon Macie FAQs page (https://aws.amazon.com/macie/faq/)

Option A is correct. Since your Splunk cluster is in a VPC, you need to make your Splunk cluster publically accessible with a public IP address. Additionally, you need to unblock the Kinesis Data Firehose address. Kinesis Data Firehose has a set group of IP addresses depending on which region in which you have configured your VPC. For example, if your VPC is in US East Virginia, then the IP address is one of these CIDR blocks: 34.238.188.128/26, 34.238.188.192/26, or 34.238.195.0/26
Option B is incorrect. Kinesis Data Firehose does send your streaming data to S3, the bucket policy will not allow you to open port access on the Splunk cluster.
Option C is incorrect. The Kinesis Data Firehose IAM role will not allow you to open port access on the Splunk cluster.
Option D is incorrect. The Splunk cluster ACL is used to control the IP addresses that can access your Splunk cluster. You need to open the security group housing your Splunk cluster to the Kinesis Data Firehose service address.
Reference:
Please see the Kinesis Data Firehose developer guide titled Controlling Access with Amazon Kinesis Data Firehose (https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-splunk-vpc), the AWS Big Data blog titled Power data ingestion into Splunk using Amazon Kinesis Data Firehose (https://aws.amazon.com/blogs/big-data/power-data-ingestion-into-splunk-using-amazon-kinesis-data-firehose/), and the Splunk docs page titled Securing Splunk Enterprise (https://docs.splunk.com/Documentation/Splunk/8.0.1/Security/Useaccesscontrollists)

Option A is correct. You can use a proxy server to avoid having to include all of your hedge fund manager’s IP addresses in your access policy. You only include the proxy server’s IP address in your IAM access policy with a policy statement segment like this:
{
…
“Effect”: “Allow”,
“Principal”: {
“AWS”: “*”
},
“Action”: “es:*”,
“Condition”: {
“IpAddress”: {
“aws:SourceIp”: [
“57.201.547.32”
]
}
}
…
}
Where 57.201.547.32 is the IP address of your proxy server.
Option B is incorrect. An open access IAM policy will allow any user on the internet to make requests to put, get, post, and delete data from your Elasticsearch domain. This option is not secure.
Option C is incorrect. You can only use security groups to control access to Elasticsearch domains that are configured in a VPC. Your Elasticsearch domain is a public domain Elasticsearch cluster.
Option D is correct. You can use Cognito and its user pools and identity pools to provide username and password access for Kibana users.
Option E is incorrect. You can only use security groups to control access to Elasticsearch domains that are configured in a VPC. Your Elasticsearch domain is a public domain Elasticsearch cluster.
Reference:
Please see the Amazon Elasticsearch Service developer guide titled Using a Proxy to Access Amazon ES from Kibana (https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-kibana.html#es-kibana-proxy), the Amazon Elasticsearch Service developer guide titled Amazon Cognito Authentication for Kibana (https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-cognito-auth.html), the Kibana overview page (https://aws.amazon.com/elasticsearch-service/the-elk-stack/kibana/), the Kibana Docs guide titled Explore Kibana using sample data (https://www.elastic.co/guide/en/kibana/current/tutorial-sample-data.html), and the AWS Database blog titled Set Access Control for Amazon Elasticsearch Service (https://aws.amazon.com/blogs/database/set-access-control-for-amazon-elasticsearch-service/)

Option A is correct. Using server side encryption through an AWS KMS CMK gives you the most secure encryption of the options provided.
Option B is incorrect. EMR does not support SSE-C
Option C is incorrect. You can not save encryption keys in your EMR cluster.
Option D is incorrect. Attempting to use Kinesis Analytics to encrypt your data is not a valid use of Kinesis Analytics. Also, you can not save your encryption keys in an S3 bucket.
Reference:
Please see the Amazon EMR management guide titled Create Keys and Certificates for Data Encryption (https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-enable.html#emr-awskms-keys), the AWS Key Management Service developer guide titled AWS Key Management Service concepts (https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys), the AWS Key Management Service developer guide titled How Amazon EMR uses AWS KMS (https://docs.aws.amazon.com/kms/latest/developerguide/services-emr.html), and the AWS Big Data blog titled Process Encrypted Data in Amazon EMR with Amazon S3 and AWS KMS (https://aws.amazon.com/blogs/big-data/process-encrypted-data-in-amazon-emr-with-amazon-s3-and-aws-kms/)

Option A is incorrect. Storage Gateway is used to move data from your data center to S3. You would not use Storage Gateway to ingest real-time streaming data. Also, using the INSERT Redshift command will be much slower than using the Redshift COPY command.
Option B is incorrect. Snowball@Edge is used to move bulk data from your data center to S3. You would not use Snowball@Edge to ingest real-time streaming data. Also, you use the UPDATE Redshift command to update values in table columns, not to move new data into your Redshift cluster.
Option C is incorrect. Kinesis Data Firehose is the correct choice to ingest your sports data into your S3 data lake. However, using the INSERT Redshift command will be much slower than using the Redshift COPY command.
Option D is correct. Kinesis Data Firehose is the correct choice to ingest your sports data into your S3 data lake. Also, the Redshift COPY command is the most performant way to load your data into your Redshift cluster.
Reference:
Please see the Amazon EMR management guide titled How to Get Data Into Amazon EMR (https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-get-data-in.html), the AWS Whitepaper titled Building Big Data Storage Solutions (Data Lakes) for Maximum Flexibility, specifically the section titled Data Ingestion Methods (https://docs.aws.amazon.com/whitepapers/latest/building-data-lakes/data-ingestion-methods.html), the Amazon Redshift database developer guide titled Step 6: Run the COPY command to load the data (https://docs.aws.amazon.com/redshift/latest/dg/load-from-emr-steps-run-copy.html), the Amazon Redshift database developer guide titled SQL Commands (https://docs.aws.amazon.com/redshift/latest/dg/c_SQL_commands.html), and the AWS Snowball developer guide titled What is an AWS Snowball Edge? (https://docs.amazonaws.cn/en_us/snowball/latest/developer-guide/whatisedge.html)

Option A is incorrect. The KPL rate limiting feature limits the shard throughput for a producer. Rate limiting uses a token algorithm, but it doesn’t have the concept of a token limit. It uses a threshold limit, which by default is set to 50% higher than the shard limit.
Option B is correct. Lowering the rate limiting threshold is an approach you could use to reduce retry spamming, but the recommended approach is to expand the capacity of your Kinesis Data Stream while also implementing a suitable partition key strategy.
Option C is incorrect. You are using the default settings for your PutRecords KPL calls. The threshold limit default is 50% higher than the shard limit. So if you set the threshold to 50% you haven’t really changed anything. Also, the recommended approach to reduce retry spamming is to expand the capacity of your Kinesis Data Stream while also implementing a suitable partition key strategy.
Option D is incorrect. You could lower the rate limiting threshold from the default 50% to 30%, but the recommended approach to reduce retry spamming is to expand the capacity of your Kinesis Data Stream while also implementing a suitable partition key strategy.
Reference:
Please see the Amazon Kinesis Data Streams developer guide titled Developing Producers Using the Amazon Kinesis Producer Library (https://docs.aws.amazon.com/streams/latest/dev/developing-producers-with-kpl.html), the AWS Big Data blog titled Implementing Efficient and Reliable Producers with the Amazon Kinesis Producer Library (https://aws.amazon.com/blogs/big-data/implementing-efficient-and-reliable-producers-with-the-amazon-kinesis-producer-library/), and the Amazon Kinesis Data Streams developer guide titled KPL Retries and Rate Limiting (https://docs.aws.amazon.com/streams/latest/dev/kinesis-producer-adv-retries-rate-limiting.html)

Option A is incorrect. This approach does not take advantage of the KCL application state tracking feature. Using a Lambda function to handle read failures is redundant and inefficient.
Option B is incorrect. The KCL application state tracking feature is implemented in a unique DynamoDB table that is associated with the KCL consumer application. The table is created using the name of the KCL consumer application. The feature does not use a global DynamoDB table.
Option C is correct. The KCL application state tracking feature is implemented in a unique DynamoDB table that is associated with the KCL consumer application. The table is created using the name of the KCL consumer application.
Option D is incorrect. The KCL application state tracking feature is implemented in a unique DynamoDB table that is associated with the KCL consumer application. The table is created using the name of the KCL consumer application. The DynamoDB table is not associated with the shard.
Reference:
Please see the Amazon Kinesis Data Streams developer guide titled Tracking Amazon Kinesis Data Streams Application State (https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-ddb.html), the Amazon Kinesis Data Streams developer guide titled Developing Custom Consumers with Shared Throughput Using KCL (https://docs.aws.amazon.com/streams/latest/dev/shared-throughput-kcl-consumers.html#shared-throughput-kcl-consumers-overview), and the Amazon Kinesis Data Streams developer guide titled Reading Data from Amazon Kinesis Data Streams (https://docs.aws.amazon.com/streams/latest/dev/building-consumers.html)

Option A is correct. Using the KPL aggregation feature allows you to overcome the 1,000 records per second limitation by combining your market data records in your KPL code before you write them to your Kinesis Data Streams stream. Aggregating them into 10 chunks removes the 1,000 records per second constraint. Kinesis Data Firehose de-aggregates the records before delivering them to your Lambda function, which transforms the data before saving it to S3.
Option B is incorrect. You are only using one Kinesis Data Firehose stream, so you would not run into the quota limit per region.
Option C is incorrect. The messaging fanout pattern for Lambda using SNS is useful for designing loosely coupled interaction between your Lambda functions. This pattern will not help you solve the throughput limitation of your data collection pipeline.
Option D is incorrect. Even if you compress your 1,500 records to get their combined message size per second under 1 MB, you will still be attempting to send more than the 1,000 records per second limit through your Kinesis Data Streams shard.
Reference:
Please see the Amazon Kinesis Data Streams developer guide titled Using the KPL with Kinesis Data Firehose (https://docs.aws.amazon.com/streams/latest/dev/kpl-with-firehose.html), the Amazon Kinesis Data Firehose developer guide titled Writing to Kinesis Data Firehose Using Kinesis Data Streams (https://docs.aws.amazon.com/firehose/latest/dev/writing-with-kinesis-streams.html), the Amazon Kinesis Data Streams developer guide titled Aggregation (https://docs.aws.amazon.com/streams/latest/dev/kinesis-kpl-concepts.html#kinesis-kpl-concepts-aggretation), the Amazon Kinesis Data Streams developer guide titled Developing Producers Using the Amazon Kinesis Producer Library (https://docs.aws.amazon.com/streams/latest/dev/developing-producers-with-kpl.html), the Amazon Kinesis Data Firehose developer guide titled Amazon Kinesis Data Firehose Quota (https://docs.aws.amazon.com/firehose/latest/dev/limits.html), the Service Quotas user guide titled What is Service Quotas? (https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html), and the AWS Compute blog titled Messaging Fanout Pattern for Serverless Architectures Using Amazon SNS (https://aws.amazon.com/blogs/compute/messaging-fanout-pattern-for-serverless-architectures-using-amazon-sns/)

Option A is incorrect. If your transform job is accessing your source columns, then you are able to reach your source data repository, RDS in this instance. The ApplyMapping transform is a built-in transform that Glue provides.
Option B is incorrect. Glue crawlers connect to RDS using a JDBC connection, not a native interface.
Option C is correct. Glue crawlers need all TCP ports open on the security group where the data source resides, your RDS instance in this scenario. To protect your database security group from outside access via a TCP port, you also configure a self-referencing inbound rule for all TCP ports.
Option D is incorrect. If your Glue crawler has reached your RDS instance and has attempted to infer its schema, then the crawler has gained access to the resource. Therefore, a resource unavailable message would not be appropriate.
Reference:
Please see the AWS Glue developer guide titled Troubleshooting Errors in AWS Glue (https://docs.aws.amazon.com/glue/latest/dg/glue-troubleshooting-errors.html#error-resource-unavailable), the AWS Glue developer guide titled Troubleshooting Connection Issues in AWS Glue (https://docs.aws.amazon.com/glue/latest/dg/troubleshooting-connection.html), the AWS Glue developer guide titled Setting Up a VPC to Connect to JDBC Data Stores (https://docs.aws.amazon.com/glue/latest/dg/setup-vpc-for-glue-access.html), the AWS Glue developer guide titled Defining Crawlers (https://docs.aws.amazon.com/glue/latest/dg/add-crawler.html), the AWS Glue developer guide titled Built-in Transforms (https://docs.aws.amazon.com/glue/latest/dg/built-in-transforms.html), and the AWS Glue developer guide titled Populating the AWS Glue Data Catalog (https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)

Option A is incorrect. This architecture has unnecessary points of latency in the flow. The S3 bucket-to-Lambda interaction coupled with the Lambda-AWS Batch interaction will introduce significant latency in a data collection system that needs to feed real-time analytics.
Option B is incorrect. This option also introduces unnecessary latency into the data collection system. The S3 and Lambda components are unnecessary; you can move your data from AWS IoT directly to Kinesis Data Firehose.
Option C is correct. Using Kinesis Data Firehose to stream your IoT data received from AWS IoT, transforming the data using Lambda, and copying the data into Redshift is the most efficient option.
Option D is incorrect. DynamoDB is not a valid destination data store for Kinesis Data Firehose. Kinesis Data Firehose can stream data to S3, Redshift, Elasticsearch, or Splunk.
Reference:
Please see the AWS Batch overview page (https://aws.amazon.com/batch/), the AWS IoT overview page (https://aws.amazon.com/iot/), the AWS Kinesis Data Firehose developer guide titled Select Destination (https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html), the Amazon Kinesis Data Firehose developer guide titled Writing to Kinesis Data Firehose Using AWS IoT (https://docs.aws.amazon.com/firehose/latest/dev/writing-with-iot.html), and the Amazon Kinesis Data Firehose FAQs (https://aws.amazon.com/kinesis/data-firehose/faqs/)

Option A is incorrect. This option is functionally incorrect. Your Kinesis Producer Library application cannot write directly to Redshift. The KPL app has to write to a Kinesis Data Streams shard, which is not present in the proposed architecture.
Option B is incorrect. This option is overly complicated. Storing your IoT data on S3 and triggering a Lambda function are unnecessary steps. Also, to COPY the data from Firehose to Redshift, and intermediary S3 bucket is needed.
Option C is incorrect. Since you don’t need to transform your IoT data, the Lambda function is not required.
Option D is correct. AWS IoT can be configured to have an action to send the streamed IoT data directly to a Kinesis Data Firehose stream. The Firehose stream can then store the streamed data into an S3 bucket and then issue the Redshift COPY command to load the data into your Redshift cluster.
Reference:
Please see the Amazon Kinesis Data Firehose developer guide titled What is Amazon Kinesis Data Firehose? (https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html#data-flow-diagrams), the Amazon Kinesis Data Firehose developer guide titled Writing to Kinesis Data Firehose Using AWS IoT (https://docs.aws.amazon.com/firehose/latest/dev/writing-with-iot.html), the AWS IoT overview page (https://aws.amazon.com/iot/), and the Amazon Kinesis Data Firehose FAQs (https://aws.amazon.com/kinesis/data-firehose/faqs/)

Option A is incorrect. To stream application log data to a Kinesis stream, the most efficient way is to use the Amazon Kinesis Agent. Also, a KPL application can only send data to a Kinesis Data Streams shard, not a Kinesis Data Firehose.
Option B is correct. The Amazon Kinesis Agent is the most efficient way to collect data from application log files and send the data to a Kinesis Data Firehose stream. To transform the log data, Kinesis uses a Lambda function. Once the Lambda function has transformed the data, the Lambda function returns the transformed data record to Kinesis Data Firehose which writes the transformed record to your S3 destination. Kinesis Data Firehose can also be configured to write the original source data record to another S3 bucket.
Option C is incorrect. This option is missing a step. The Lambda function doesn’t write the transformed record to your S3 destination, the Lambda function returns the transformed data record to Kinesis Data Firehose which writes the transformed record to your S3 destination.
Option D is incorrect. This option is missing a step. Kinesis Data Firehose cannot transform your records without the use of a Lambda function. To transform the log data, Kinesis uses a Lambda function. Once the Lambda function has transformed the data, the Lambda function returns the transformed data record to Kinesis Data Firehose which writes the transformed record to your S3 destination.
Reference:
Please see the Amazon Kinesis Data Firehose developer guide titled What is Amazon Kinesis Data Firehose? (https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html#data-flow-diagrams), the Amazon Kinesis Data Firehose developer guide titled Writing to Kinesis Data Firehose Using Kinesis Agent (https://docs.aws.amazon.com/firehose/latest/dev/writing-with-agents.html), the Amazon Kinesis Data Firehose developer guide titled Amazon Kinesis Data Firehose Data Transformation (https://docs.aws.amazon.com/firehose/latest/dev/data-transformation.html), and the Medium article titled Amazon Kinesis Firehose- Send your Apache logs to S3 (https://medium.com/tensult/amazon-kinesis-firehose-send-your-apache-logs-to-s3-26876f7cac84)

Option A is incorrect. Using Glue to extract, transform, and load your data from your on-prem Oracle database to your PostgreSQL RDS instance is not the most efficient option. This option requires you to code the Glue ETL transformation job. The option using AWS DMS requires much less effort on your part.
Option B is incorrect. When moving from on-prem to RDS, the Amazon Schema Conversion tool only converts the source schema to the target schema. You would also need to use a database migration service together with SCT to complete your task.
Option C is correct. This AWS DMS service is the correct choice since it is the most efficient at migrating on-prem heterogeneous databases to RDS. Since DMS has data transformation replication tasks, you can perform your primary key and data type changes directly within your DMS data migration.
Option D is incorrect. The Kinesis Agent is used to monitor files. You wouldn’t use it to try to monitor and capture changes to your Oracle database instance. Also, you would have to somehow get your foundational data, the data that hasn’t changed, from your Oracle instance to your PostgreSQL RDS instance. This approach would be much less efficient than the DMS approach.
Reference:
Please see the AWS Database Migration Service user guide titled Creating Tasks for Ongoing Replication Using AWS DMS (https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Task.CDC.html), the AWS Database Migration Service user guide titled Specifying Table Selection and Transformations by Table Mapping Using JSON (https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TableMapping.html#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation), the AWS Database Migration Service user guide titled Using Table Mapping to Specify Task Settings (https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TableMapping.html#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations), the AWS Database Migration Service user guide titled How AWS Database Migration Service Works (https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Introduction.html), the AWS Schema Conversion Tool user guide titled Converting Database Schemas Using the AWS Schema Conversion Tool (https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Converting.html), the AWS Database blog titled How to extract, transform, and load data for analytic processing using AWS Glue (Part 2) (https://aws.amazon.com/blogs/database/how-to-extract-transform-and-load-data-for-analytic-processing-using-aws-glue-part-2/), the AWS Big Data blog titled How to access and analyze on-premises data stores using AWS Glue (https://aws.amazon.com/blogs/big-data/how-to-access-and-analyze-on-premises-data-stores-using-aws-glue/), the AWS Prescriptive Guidance Oracle database migration guide titled Heterogeneous database migration (https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-oracle-database/heterogenous-migration.html), and the AWS Kinesis Data Firehose developer guide titled Writing to Kinesis Data Firehose Using Kinesis Agent (https://docs.aws.amazon.com/firehose/latest/dev/writing-with-agents.html)

Option A is correct. One of the ways your migration tasks can slow down is because your source latency is high. To discover the problem and understand how to fix it, you use your CloudWatch log entries to find the delay in capturing from your source. One example is transactions that have started, but have not committed.
Option B is incorrect. AWS DMS does not require that the source database and the target database be of the same instance type. Also, if you change your target instance type from Aurar to some other type you will no longer be able to take advantage of Aurora’s global database feature.
Option C is incorrect. According to the AWS documentation, in order to use your DB subnet group, it needs to be in at least two Availability Zones. Your subnet group is already across two availability zones.
Option D is incorrect. The DMS replication instance can run on an EC2 instance in either your default VPC or another VPC in your account.
Option E is correct. Another way your migration tasks can run slow is when your target latency is high. To discover the problem and understand how to fix it, you use your CloudWatch log entries to find the delay in applying changes to your target. An example is when you have no primary keys or indexes on the target.
Reference:
Please see the Amazon Aurora overview page (https://aws.amazon.com/rds/aurora/), the AWS knowledge center page titled How can I troubleshoot high target latency on an AWS DMS task? (https://aws.amazon.com/premiumsupport/knowledge-center/dms-high-target-latency/), the AWS Database Migration Service user guide titled Monitoring AWS DMS Tasks (https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.Metrics.Task), the Amazon Aurora user guide for Aurora titled Working with a DB Instance in a VPC (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html), the Amazon Aurora user guide for Aurora titled Scenarios for Accessing a DB Instance in a VPC (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_VPC.Scenarios.html), the AWS Database Migration Service overview page (https://aws.amazon.com/dms/), and the AWS Database Migration Service user guide titled Setting Up a Network for a Replication Instance (https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.VPC.html)

Option A is incorrect. The one problem with this option is that the Glue Workflow requires that you start the crawler on demand from the Workflows page on the AWS Glue console. This is not an automated step in your workflow so this option does not satisfy your requirements, nor is it the most efficient option.
Option B is incorrect. This option automates all of the steps in your crawl, extract, transform, load process. However, it requires you to write a Lambda function to trigger your ETL job. This is not as efficient as using the Glue triggers approach described in option D.
Option C is incorrect. This option describes the most efficient approach, the use of Glue triggers, but it has the wrong state for watching the Glue crawler. There is no COMPLETED state. The proper state is SUCCEEDED.
Option D is correct. This option describes the most efficient approach, the use of Glue triggers, to start both the crawler and the ETL job automatically.
Reference:
Please see the AWS Glue developers guide titled AWS Glue Concepts (https://docs.aws.amazon.com/glue/latest/dg/components-key-concepts.html), the AWS Knowledge Center article titled How can I automatically start an AWS Glue job when a crawler run completes? (https://aws.amazon.com/premiumsupport/knowledge-center/start-glue-job-run-end/), the AWS Knowledge Center article titled How can I use AWS Glue workflows to automatically start a job when a crawler run completes? (https://aws.amazon.com/premiumsupport/knowledge-center/start-glue-job-after-crawler-workflow/), the AWS Knowledge Center article titled How can I use a Lambda function to automatically start an AWS Glue job when a crawler run completes? (https://aws.amazon.com/premiumsupport/knowledge-center/start-glue-job-crawler-completes-lambda/), the AWS Glue developers guide titled Starting Jobs and Crawlers Using Triggers (https://docs.aws.amazon.com/glue/latest/dg/trigger-job.html), the AWS Glue developers guide titled Performing Complex ETL Activities Using Workflows in AWS Glue (https://docs.aws.amazon.com/glue/latest/dg/orchestrate-using-workflows.html), the AWS Glue developers guide titled Overview of Workflows in AWS Glue (https://docs.aws.amazon.com/glue/latest/dg/workflows_overview.html), and the AWS Glue developers guide titled AWS Glue Triggers (https://docs.aws.amazon.com/glue/latest/dg/about-triggers.html)