Correct options:

Create an application that will traverse the S3 bucket, issue a Byte Range Fetch for the first 250 bytes, and store that information in ElasticSearch

Amazon Simple Storage Service (Amazon S3) is an object storage service that offers industry-leading scalability, data availability, security, and performance.

Amazon Elasticsearch Service (Amazon ES) is a managed service that makes it easy to deploy, operate, and scale Elasticsearch clusters in the AWS Cloud. Elasticsearch is a popular open-source search and analytics engine for use cases such as log analytics, real-time application monitoring, and clickstream analysis. With Amazon ES, you get direct access to the Elasticsearch APIs; existing code and applications work seamlessly with the service.

https://aws.amazon.com/elasticsearch-service/

Using the Range HTTP header in a GET Object request, you can fetch a byte-range from an object, transferring only the specified portion. You can use concurrent connections to Amazon S3 to fetch different byte ranges from within the same object. This helps you achieve higher aggregate throughput versus a single whole-object request. Fetching smaller ranges of a large object also allows your application to improve retry times when requests are interrupted.

A byte-range request is a perfect way to get the beginning of a file and ensuring we remain efficient during our scan of our S3 bucket. You can then store the relevant information in the form of a JSON document in ElasticSearch.

Create an application that will use the S3 Select ScanRange parameter to get the first 250 bytes and store that information in ElasticSearch

With Amazon S3 Select, you can scan a subset of an object by specifying a range of bytes to query using the ScanRange parameter. This capability lets you parallelize scanning the whole object by splitting the work into separate Amazon S3 Select requests for a series of non-overlapping scan ranges. Use the Amazon S3 Select ScanRange parameter and Start at (Byte) and End at (Byte). You can then store the relevant information in the form of a JSON document in ElasticSearch.

https://docs.aws.amazon.com/AmazonS3/latest/dev/selecting-content-from-objects.html

Incorrect options:

Use the ElasticSearch Import feature to load the entire data from S3 to ElasticSearch and then ElasticSearch would automatically build the index - This option has been added as a distractor as there is no ElasticSearch Import feature to load data from S3.

Create an application that will traverse the S3 bucket, read the entire files one by one, extract the first 250 bytes, and store that information in ElasticSearch - If you build an application that loads all the files from S3, that would work, but you would read 50TB of data and that may be very expensive and slow. So this option is incorrect.

Use the Database Migration Service to load the entire data from S3 to ElasticSearch and then ElasticSearch would automatically build the index - Although you could use Database Migration Service to load the entire data from S3 to ElasticSearch, but you would read 50TB of data and that may be very expensive and slow. So this option is incorrect.

References:

https://docs.aws.amazon.com/AmazonS3/latest/dev/optimizing-performance-guidelines.html#optimizing-performance-guidelines-get-range

https://docs.aws.amazon.com/AmazonS3/latest/dev/selecting-content-from-objects.html

https://aws.amazon.com/elasticsearch-service/

Correct options:

By default, Lambda functions always operate from an AWS-owned VPC and hence have access to any public internet address or public AWS APIs. Once a Lambda function is VPC-enabled, it will need a route through a NAT gateway in a public subnet to access public resources - Lambda functions always operate from an AWS-owned VPC. By default, your function has full ability to make network requests to any public internet address — this includes access to any of the public AWS APIs. For example, your function can interact with AWS DynamoDB APIs to PutItem or Query for records. You should only enable your functions for VPC access when you need to interact with a private resource located in a private subnet. An RDS instance is a good example.

Once your function is VPC-enabled, all network traffic from your function is subject to the routing rules of your VPC/Subnet. If your function needs to interact with a public resource, you will need a route through a NAT gateway in a public subnet.

https://aws.amazon.com/blogs/architecture/best-practices-for-developing-on-aws-lambda/

Since Lambda functions can scale extremely quickly, it's a good idea to deploy a CloudWatch Alarm that notifies your team when function metrics such as ConcurrentExecutions or Invocations exceeds the expected threshold - Since Lambda functions can scale extremely quickly, this means you should have controls in place to notify you when you have a spike in concurrency. A good idea is to deploy a CloudWatch Alarm that notifies your team when function metrics such as ConcurrentExecutions or Invocations exceeds your threshold. You should create an AWS Budget so you can monitor costs on a daily basis.

If you intend to reuse code in more than one Lambda function, you should consider creating a Lambda Layer for the reusable code - You can configure your Lambda function to pull in additional code and content in the form of layers. A layer is a ZIP archive that contains libraries, a custom runtime, or other dependencies. With layers, you can use libraries in your function without needing to include them in your deployment package. Layers let you keep your deployment package small, which makes development easier. A function can use up to 5 layers at a time.

You can create layers, or use layers published by AWS and other AWS customers. Layers support resource-based policies for granting layer usage permissions to specific AWS accounts, AWS Organizations, or all accounts. The total unzipped size of the function and all layers can't exceed the unzipped deployment package size limit of 250 MB.

Incorrect options:

Lambda allocates compute power in proportion to the memory you allocate to your function. AWS, thus recommends to over provision your function time out settings for the proper performance of Lambda functions - Lambda allocates compute power in proportion to the memory you allocate to your function. This means you can over-provision memory to run your functions faster and potentially reduce your costs. However, AWS recommends that you should not over-provision your function time out settings. Always understand your code performance and set a function time out accordingly. Over-provisioning function timeout often results in Lambda functions running longer than expected and unexpected costs.

The bigger your deployment package, the slower your Lambda function will cold-start. Hence, AWS suggests packaging dependencies as a separate package from the actual Lambda package - This statement is added as a distractor. All the dependencies can be packaged into the single Lambda deployment package without any performance impact.

Serverless databases and Lambda complement each other and you should install databases on the Lambda functions - This statement is incorrect. AWS Lambda does not support installation of databases.

References:

https://aws.amazon.com/blogs/architecture/best-practices-for-developing-on-aws-lambda/

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

Correct option:

API Gateway creates RESTful APIs that enable stateless client-server communication and API Gateway also creates WebSocket APIs that adhere to the WebSocket protocol, which enables stateful, full-duplex communication between client and server

Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. APIs act as the front door for applications to access data, business logic, or functionality from your backend services. Using API Gateway, you can create RESTful APIs and WebSocket APIs that enable real-time two-way communication applications.

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

API Gateway creates RESTful APIs that: Are HTTP-based. Enable stateless client-server communication. Implement standard HTTP methods such as GET, POST, PUT, PATCH, and DELETE.

API Gateway creates WebSocket APIs that: Adhere to the WebSocket protocol, which enables stateful, full-duplex communication between client and server. Route incoming messages based on message content.

So API Gateway supports stateless RESTful APIs as well as stateful WebSocket APIs. Therefore this option is correct.

Incorrect options:

API Gateway creates RESTful APIs that enable stateful client-server communication and API Gateway also creates WebSocket APIs that adhere to the WebSocket protocol, which enables stateful, full-duplex communication between client and server

API Gateway creates RESTful APIs that enable stateless client-server communication and API Gateway also creates WebSocket APIs that adhere to the WebSocket protocol, which enables stateless, full-duplex communication between client and server

API Gateway creates RESTful APIs that enable stateful client-server communication and API Gateway also creates WebSocket APIs that adhere to the WebSocket protocol, which enables stateless, full-duplex communication between client and server

These three options contradict the earlier details provided in the explanation. To summarize, API Gateway supports stateless RESTful APIs and stateful WebSocket APIs. Hence these options are incorrect.

https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html

Reference:

https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html

Correct option:

Configure DMS data validation on the migration task so it can compare the source and target data for the DMS task and report any mismatches

You can use AWS DMS data validation to ensure that your data has migrated accurately from the source to the target. DMS compares the source and target records and then reports any mismatches. In addition, for a CDC-enabled task, AWS DMS compares the incremental changes and reports any mismatches. As part of data validation, DMS compares each row in the source with its corresponding row at the target and verifies that those rows contain the same data. For this comparison, DMS issues appropriate queries to retrieve the data. These queries consume additional resources at the source and the target as well as additional network resources.

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html

Incorrect options:

Use the table metrics of the DMS task to verify the statistics for tables being migrated including the DDL statements completed - You can use table metrics to capture statistics such as insert, update, delete, and DDL statements completed for the tables being migrated. This option will not help you compare the source and target data for the DMS task and report any mismatches.

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.Metrics

Configure DMS premigration assessment on the migration task so the assessment can compare the source and target data and report any mismatches - A premigration assessment evaluates specified components of a database migration task to help identify any problems that might prevent a migration task from running as expected. This assessment gives you a chance to identify issues before you run a new or modified task. You can then fix problems before they occur while running the migration task itself. This can avoid delays in completing a given database migration needed to repair data and your database environment. This option will not help you compare the source and target data for the DMS task and report any mismatches.

Use AWS Schema Conversion Tool for the migration task so it can compare the source and target data and report any mismatches - You can use the AWS Schema Conversion Tool (AWS SCT) to convert your existing database schema from one database engine to another. You can convert relational OLTP schema or data warehouse schema. Your converted schema is suitable for an Amazon Relational Database Service (Amazon RDS) MySQL, MariaDB, Oracle, SQL Server, PostgreSQL DB, an Amazon Aurora DB cluster, or an Amazon Redshift cluster. This option will not help you compare the source and target data for the DMS task and report any mismatches.

References:

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.Metrics

Correct options:

Multi-AZ deployments for both RDS MySQL and Aurora MySQL follow synchronous replication

Read Replicas can be manually promoted to a standalone database instance for RDS MySQL whereas Read Replicas for Aurora MySQL can be promoted to the primary instance

The primary and standby DB instances are upgraded at the same time for RDS MySQL Multi-AZ. All instances are upgraded at the same time for Aurora MySQL

RDS Read replicas are a special type of DB instances that make use of the built-in replication functionality for RDS. The source DB instance becomes the primary DB instance. Updates made to the primary DB instance are asynchronously copied to the read replica. When you create a read replica, you first specify an existing DB instance as the source. Then Amazon RDS takes a snapshot of the source instance and creates a read-only instance from the snapshot. Amazon RDS then uses the asynchronous replication method for the DB engine to update the read replica whenever there is a change to the primary DB instance.

Aurora Replicas are independent endpoints in an Aurora DB cluster, best used for scaling read operations and increasing availability. Up to 15 Aurora Replicas can be distributed across the Availability Zones that a DB cluster spans within an AWS Region. The DB cluster volume is made up of multiple copies of the data for the DB cluster. However, the data in the cluster volume is represented as a single, logical volume to the primary instance and to Aurora Replicas in the DB cluster.

In a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone. The primary DB instance is synchronously replicated across Availability Zones to a standby replica to provide data redundancy, eliminate I/O freezes, and minimize latency spikes during system backups. Aurora stores copies of the data in a DB cluster across multiple Availability Zones in a single AWS Region. When data is written to the primary DB instance, Aurora synchronously replicates the data across Availability Zones to six storage nodes associated with your cluster volume.

To increase availability, you can use Aurora Replicas as failover targets. That is, if the primary instance fails, an Aurora Replica is promoted to the primary instance. There is a brief interruption during which read and write requests made to the primary instance fail with an exception, and the Aurora Replicas are rebooted.

For RDS MySQL in Multi-AZ configuration, database engine version upgrades happen on both the primary and standby DB instances at the same time. For Aurora MySQL, all instances are upgraded at the same time.

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.html

Incorrect options:

Database engine version upgrades happen on primary for Aurora MySQL whereas all instances are updated together for RDS MySQL

Read Replicas can be manually promoted to a standalone database instance for Aurora MySQL whereas Read Replicas for RDS MySQL can be promoted to the primary instance

Multi-AZ deployments for Aurora MySQL follow synchronous replication whereas Multi-AZ deployments for RDS MySQL follow asynchronous replication

These three options contradict the explanation provided above, so these are incorrect.

References:

https://aws.amazon.com/rds/features/read-replicas/

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.html

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraHighAvailability.html

Correct option:

Create separate cache behaviors for static and dynamic content. Remove the Date HTTP header from the whitelist headers section on both of the cache behaviors. Remove the session cookie from the whitelist cookies section for static content as well as the Authorization HTTP header from the whitelist headers section for cache behavior configured for static content

CloudFront is a web service that speeds up the distribution of your static and dynamic web content by routing each user request through the AWS backbone network to the edge location that can best serve your content.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html

One of the purposes of using CloudFront is to reduce the number of requests that your origin server must respond to directly. With CloudFront caching, more objects are served from CloudFront edge locations, which are closer to your users. This reduces the load on your origin server and reduces latency. The proportion of requests that are served from caches to all requests is called the cache hit ratio.

To improve the cache hit ratio when CloudFront is configured to cache based on cookie values you should create separate cache behaviors for static and dynamic content, and configure CloudFront to forward cookies to your origin only for dynamic content. So, for the given use-case, you should remove the session cookie from the whitelist cookies section for static content.

To improve the cache hit ratio when CloudFront is configured to cache based on request headers, you should set up CloudFront to forward and cache based on only specified headers instead of forwarding and caching based on all headers. So, you can remove Authorization HTTP header from the whitelist headers section for cache behavior configured for static content. In addition, AWS recommends not to configure caching based on values in the Date and User-Agent headers, because these headers have numerous possible values and caching based on their values could cause CloudFront to forward significantly more requests to your origin.

 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html

 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html

Incorrect options:

Create separate cache behaviors for static and dynamic content. Remove the Date as well as Host HTTP headers from the whitelist headers section on both of the cache behaviors. Remove the session cookie from the whitelist cookies section for static content as well as the Authorization HTTP header from the whitelist headers section for cache behavior configured for static content - As mentioned in the explanation above, AWS recommends not to configure caching based on values in the Date and User-Agent headers, because these headers have numerous possible values and caching based on their values could cause CloudFront to forward significantly more requests to your origin. However, this rule should not be applied to the Host HTTP headers as well as these do not have numerous distinct values. So, this option is incorrect.

Remove the Date and Authorization HTTPS headers from the whitelist headers section of the cache behavior. Then update the cache behavior to use presigned cookies for authorization - One of the key requirements mandates that the web application needs user authorization and session tracking for dynamic content, so you should not remove the Authorization HTTPS headers from the whitelist headers section of the cache behavior. In addition, AWS recommends not to configure caching based on values in the Date and User-Agent headers only. These headers have numerous possible values and caching based on their values could cause CloudFront to forward significantly more requests to your origin.

Remove the Host HTTP header from the whitelist headers section and remove the session cookie from the whitelist cookies section for the default cache behavior. Enable automatic object compression and use Lambda@Edge viewer request events for user authorization - This option suggests removing Host HTTP headers from the default cache behavior although AWS recommends only removing the Date and User-Agent headers because these headers have numerous possible values and caching based on their values could cause CloudFront to forward significantly more requests to your origin. So this option is incorrect.

References:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-headers-behavior

Correct option:

Order three AWS Snowball Edge appliances, split and transfer the data to these three appliances and ship them to AWS which will then copy the data from the Snowball Edge appliances to S3

The AWS Snowball Edge is a type of Snowball device with on-board storage and compute power for select AWS capabilities. Each Snowball Edge device can transport data at speeds faster than the internet. This transport is done by shipping the data in the appliances through a Regional carrier. The appliances are rugged shipping containers, complete with E Ink shipping labels. Snowball Edge devices have three options for device configurations – storage optimized, compute optimized, and with GPU.

Snowball Edge is the optimal choice if you need to securely and quickly transfer dozens of terabytes to petabytes of data to AWS. The AWS Snow Family is ideal for customers moving large batches of data at once. The AWS Snowball has a typical 5-7 days turnaround time. As each Snowball Edge device can handle 80TB of data, you can order 3 such devices to take care of the data transfer for the given use-case.

Incorrect options:

Leverage the 1Gbps IPSec based AWS VPN connection to transfer the data to S3 over the public internet

The given use-case requires transferring 200 TB of archived data within the shortest possible duration. Now, the IPSec based AWS VPN connection assures a speed of 1 Gbps (Gigabits per second). As 1 Byte = 8 bits, therefore you can transfer 0.125 GBps (Gigabytes per second).

So the hourly data transfer is 0.1256060 = 450 GB or approximately 0.45 TB.

So the approximate daily data transfer is 0.45 * 24 = ~ 10 TB

Therefore, the entire archived dataset of 200 TB can be transferred in 20 days. As explained above, using Snowball appliances, you can complete this data transfer in just 5-7 days. So this option is incorrect.

Leverage the 500 Mbps Direct Connect connection to transfer the data to S3 over the dedicated connection - We established above that a 1GBps connection would take 20 days to transfer the dataset, so the 500 Mbps Direct Connect connection would take 40 days to transfer the dataset. So this option is incorrect.

Exam Alert:

The exam would probe you on multiple scenarios around competing options to migrate data from on-premises data centers to AWS Cloud. You should remember that a 1Gbps connection at full utilization can transfer approximately 10 TB of data in a day. You will see questions that tweak the available connection bandwidth or change the available utilization, so you just need to factor these changes into the above-mentioned unit rate to identify the correct answer.

Leverage S3 Transfer Acceleration to transfer the data to S3 - S3 Transfer Acceleration enables fast, easy, and secure transfers of files over long distances between your client and your Amazon S3 bucket. S3 Transfer Acceleration leverages Amazon CloudFront’s globally distributed AWS Edge Locations.

You should note that S3 Transfer Acceleration over a fully-utilized 1 Gbps line can only transfer up to 75 TBs in a week's duration. So this option is not correct for the given use-case.

https://aws.amazon.com/s3/faqs/#Amazon_S3_Transfer_Acceleration

References:

https://aws.amazon.com/s3/faqs/#Amazon_S3_Transfer_Acceleration

Correct options:

If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user or role can't perform that action

SCPs affect all users and roles in attached accounts, including the root user

SCPs do not affect service-linked role

Service control policies (SCPs) are one type of policy that can be used to manage your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization, allowing you to ensure your accounts stay within your organization’s access control guidelines.

In SCPs, you can restrict which AWS services, resources, and individual API actions the users and roles in each member account can access. You can also define conditions for when to restrict access to AWS services, resources, and API actions. These restrictions even override the administrators of member accounts in the organization.

Please note the following effects on permissions vis-a-vis the SCPs:

If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user or role can't perform that action.

SCPs affect all users and roles in the attached accounts, including the root user.

SCPs do not affect any service-linked role.

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html

Incorrect options:

If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user or role can still perform that action

SCPs affect all users and roles in attached accounts, excluding the root user

SCPs affect service-linked roles

These three options contradict the explanation provided above, so these options are incorrect.

Reference:

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html

Correct options:

Create an inbound endpoint on Route 53 Resolver and then DNS resolvers on the on-premises network can forward DNS queries to Route 53 Resolver via this endpoint

Create an outbound endpoint on Route 53 Resolver and then Route 53 Resolver can conditionally forward queries to resolvers on the on-premises network via this endpoint

Amazon Route 53 is a highly available and scalable cloud Domain Name System (DNS) web service. Amazon Route 53 effectively connects user requests to infrastructure running in AWS – such as Amazon EC2 instances – and can also be used to route users to infrastructure outside of AWS. By default, Route 53 Resolver automatically answers DNS queries for local VPC domain names for EC2 instances. You can integrate DNS resolution between Resolver and DNS resolvers on your on-premises network by configuring forwarding rules.

To resolve any DNS queries for resources in the AWS VPC from the on-premises network, you can create an inbound endpoint on Route 53 Resolver and then DNS resolvers on the on-premises network can forward DNS queries to Route 53 Resolver via this endpoint.

Resolver Inbound Endpoint : https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html

To resolve DNS queries for any resources in the on-premises network from the AWS VPC, you can create an outbound endpoint on Route 53 Resolver and then Route 53 Resolver can conditionally forward queries to resolvers on the on-premises network via this endpoint. To conditionally forward queries, you need to create Resolver rules that specify the domain names for the DNS queries that you want to forward (such as example.com) and the IP addresses of the DNS resolvers on the on-premises network that you want to forward the queries to.

Resolver Outbound Endpoint : https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html

Incorrect options:

Create an outbound endpoint on Route 53 Resolver and then DNS resolvers on the on-premises network can forward DNS queries to Route 53 Resolver via this endpoint - DNS resolvers on the on-premises network can forward DNS queries to Route 53 Resolver via an inbound endpoint. Hence, this option is incorrect.

Create an inbound endpoint on Route 53 Resolver and then Route 53 Resolver can conditionally forward queries to resolvers on the on-premises network via this endpoint - Route 53 Resolver can conditionally forward queries to resolvers on the on-premises network via an outbound endpoint. Hence, this option is incorrect.

Create a universal endpoint on Route 53 Resolver and then Route 53 Resolver can receive and forward queries to resolvers on the on-premises network via this endpoint - There is no such thing as a universal endpoint on Route 53 Resolver. This option has been added as a distractor.

References:

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html

https://aws.amazon.com/blogs/networking-and-content-delivery/automating-dns-infrastructure-using-route-53-resolver-endpoints/

Correct option:

Replatform the IT infrastructure to AWS Cloud by leveraging AWS OpsWorks as a configuration management service to automate the configurations of servers on AWS

Replatforming is a migration strategy where you don't change the core architecture but leverage some cloud optimizations. Here are the six most common application migration strategies:

https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/

For the given use-case, you can leverage AWS OpsWorks to automate the configurations of your servers. OpsWorks lets you use Chef and Puppet to automate how servers are configured, deployed, and managed across your Amazon EC2 instances or on-premises compute environments. Specifically, OpsWorks for Chef Automate provides a fully managed Chef server and suite of automation tools that give you workflow automation for continuous deployment, automated testing for compliance and security, and a user interface that gives you visibility into your nodes and their status.

The migration results in an optimized IT infrastructure as OpsWorks for Chef Automate provides a configuration management experience that is fully compatible with Chef, including all community scripts and tooling, but without the operational overhead of managing the underlying Chef server.

Incorrect options:

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

How Config Works:  https://aws.amazon.com/config/

Rehost the IT infrastructure to AWS Cloud by leveraging AWS OpsWorks as a configuration management service to automate the configurations of servers on AWS - This option is incorrect because the correct migration strategy used for this use-case is Replatforming, as described in the explanation above. Rehosting refers to a migration strategy where no cloud optimizations are done and the application is migrated as-is.

Rehost the IT infrastructure to AWS Cloud by leveraging AWS Elastic Beanstalk as a configuration management service to automate the configurations of servers on AWS - As explained above, Rehosting is not the correct migration strategy for the given use-case. Elastic Beanstalk makes it easier for developers to quickly deploy and manage applications in the AWS Cloud. Developers simply upload their application, and Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring. You cannot use Elastic Beanstalk as a configuration management service to automate the configurations of servers on AWS.

References:

https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/

https://aws.amazon.com/opsworks/

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

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