Correct option:

Network Load Balancer

Network Load Balancer is best suited for use-cases involving low latency and high throughput workloads that involve scaling to millions of requests per second. Network Load Balancer operates at the connection level (Layer 4), routing connections to targets - Amazon EC2 instances, microservices, and containers – within Amazon Virtual Private Cloud (Amazon VPC) based on IP protocol data.

Incorrect options:

Application Load Balancer - Application Load Balancer operates at the request level (layer 7), routing traffic to targets – EC2 instances, containers, IP addresses, and Lambda functions based on the content of the request. Ideal for advanced load balancing of HTTP and HTTPS traffic, Application Load Balancer provides advanced request routing targeted at the delivery of modern application architectures, including microservices and container-based applications.

Application Load Balancer is not a good fit for the low latency and high throughput scenario mentioned in the given use-case.

Classic Load Balancer - Classic Load Balancer provides basic load balancing across multiple Amazon EC2 instances and operates at both the request level and connection level. Classic Load Balancer is intended for applications that were built within the EC2-Classic network. Classic Load Balancer is not a good fit for the low latency and high throughput scenario mentioned in the given use-case.

Infrastructure Load Balancer - There is no such thing as Infrastructure Load Balancer and this option just acts as a distractor.

Reference:

https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html

Correct option:

Multi-AZ follows synchronous replication and spans at least two Availability Zones within a single region. Read replicas follow asynchronous replication and can be within an Availability Zone, Cross-AZ, or Cross-Region

Amazon RDS Multi-AZ deployments provide enhanced availability and durability for RDS database (DB) instances, making them a natural fit for production database workloads. When you provision a Multi-AZ DB Instance, Amazon RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different Availability Zone (AZ). Multi-AZ spans at least two Availability Zones within a single region.

Amazon RDS Read Replicas provide enhanced performance and durability for RDS database (DB) instances. They make it easy to elastically scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads. For the MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server database engines, Amazon RDS creates a second DB instance using a snapshot of the source DB instance. It then uses the engines' native asynchronous replication to update the read replica whenever there is a change to the source DB instance.

Amazon RDS replicates all databases in the source DB instance. Read replicas can be within an Availability Zone, Cross-AZ, or Cross-Region.

Exam Alert:

Please review this comparison vis-a-vis Multi-AZ vs Read Replica for RDS: 

https://aws.amazon.com/rds/features/multi-az/

Incorrect Options:

Multi-AZ follows asynchronous replication and spans one Availability Zone within a single region. Read replicas follow synchronous replication and can be within an Availability Zone, Cross-AZ, or Cross-Region

Multi-AZ follows asynchronous replication and spans at least two Availability Zones within a single region. Read replicas follow synchronous replication and can be within an Availability Zone, Cross-AZ, or Cross-Region

Multi-AZ follows asynchronous replication and spans at least two Availability Zones within a single region. Read replicas follow asynchronous replication and can be within an Availability Zone, Cross-AZ, or Cross-Region

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

References:

https://aws.amazon.com/rds/features/multi-az/

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

Correct option:

Create a CNAME record

A CNAME record maps DNS queries for the name of the current record, such as acme.example.com, to another domain (example.com or example.net) or subdomain (acme.example.com or zenith.example.org).

CNAME records can be used to map one domain name to another. Although you should keep in mind that the DNS protocol does not allow you to create a CNAME record for the top node of a DNS namespace, also known as the zone apex. For example, if you register the DNS name example.com, the zone apex is example.com. You cannot create a CNAME record for example.com, but you can create CNAME records for www.example.com, newproduct.example.com, and so on.

Please review the major differences between CNAME and Alias Records:

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html

Incorrect options:

Create an A record - Used to point a domain or subdomain to an IP address. 'A record' cannot be used to map one domain name to another.

Create a PTR record - A Pointer (PTR) record resolves an IP address to a fully-qualified domain name (FQDN) as an opposite to what A record does. PTR records are also called Reverse DNS records. 'PTR record' cannot be used to map one domain name to another.

Create an Alias Record - Alias records let you route traffic to selected AWS resources, such as CloudFront distributions and Amazon S3 buckets. They also let you route traffic from one record in a hosted zone to another record. 3rd party websites do not qualify for these as we have no control over those. 'Alias record' cannot be used to map one domain name to another.

Reference:

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html

Correct option:

If you attempt to delete a stack with termination protection enabled, the deletion fails and the stack - including its status - remains unchanged

You cannot delete stacks that have termination protection enabled. If you attempt to delete a stack with termination protection enabled, the deletion fails and the stack - including its status - remains unchanged. Disable termination protection on the stack, then perform the delete operation again.

This includes nested stacks whose root stacks have termination protection enabled. Disable termination protection on the root stack, then perform the delete operation again. It is strongly recommended that you do not delete nested stacks directly, but only delete them as part of deleting the root stack and all its resources.

Complete steps for Stack deletion: 

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html

Incorrect options:

The AWS user who initiated the stack deletion does not have enough permissions - If the user does not have enough permissions to delete the stack, an error explaining the same is displayed and the stack will be in the DELETE_FAILED state.

Some resources must be empty before they can be deleted. Such resources will not be deleted if they are not empty and stack deletion fails without any error - Some resources must be empty before they can be deleted. For example, you must delete all objects in an Amazon S3 bucket or remove all instances in an Amazon EC2 security group before you can delete the bucket or security group. Otherwise, stack deletion fails and the stack will be in the DELETE_FAILED state.

Dependent resources should be deleted first, before deleting the rest of the resources in the stack. If this order is not followed, then stack deletion fails without an error - Any error during stack deletion will result in the stack being in the DELETE_FAILED state.

Reference:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html

Correct options:

Before you start using your Application Load Balancer, you must add one or more listeners - A listener checks for connection requests from clients, using the protocol and port that you configure. The rules that you define for a listener determine how the load balancer routes requests to its registered targets. Each rule consists of a priority, one or more actions, and one or more conditions. When the conditions for a rule are met, then its actions are performed. You must define a default rule for each listener, and you can optionally define additional rules.

You configure target groups of an ALB by attaching them to the listeners - Each target group is used to route requests to one or more registered targets. When you create each listener rule, you specify a target group and conditions. When a rule condition is met, traffic is forwarded to the corresponding target group. You can create different target groups for different types of requests.

Load Balancer basic components: 

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html

Incorrect options:

The targets of a target group in an ALB should all belong to the same Availability Zone - A load balancer serves as the single point of contact for clients. The load balancer distributes incoming application traffic across multiple targets, such as EC2 instances, in multiple Availability Zones. This increases the availability of your application.

A target can be registered with only one target group at any given time - Each target group routes requests to one or more registered targets, such as EC2 instances, using the protocol and port number that you specify. You can register a target with multiple target groups.

When you create a listener, you define actions and conditions for the default rule - When you create a listener, you define actions for the default rule. Default rules can't have conditions. If the conditions for none of a listener's rules are met, then the action for the default rule is performed.

Reference:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html

Correct option:

AWS Config will not send a new notification

AWS Config sends notifications only when the compliance status changes. If a resource was previously non-compliant and is still non-compliant, Config will not send a new notification. If the compliance status changes to “compliant”, you will receive a notification for the change in status.

Incorrect options:

AWS Config will send a notification with the current status of the resource - As discussed above, this is incorrect.

Once a resource is marked non-compliant, the Config rule will not run on the resource again till the state changes - This statement is incorrect. The Config rule continues to be evaluated on the resource.

AWS Config will not record configuration changes that did not result from API activity on the resource. Hence, the Config rule is not triggered - AWS Config records configuration changes that did not result from API activity on the configured resource.

Reference:

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

Correct option:

{

 "Statement": [

   {

     "Sid": "AllowEveryoneReadOnlyAccess",

     "Effect": "Allow",

     "Principal": "*",

     "Action": [ "s3:GetObject", "s3:ListBucket" ],

     "Resource": ["urn:aws:s3:::mybucket","urn:aws:s3:::mybucket/*"]

   }

 ]

}

This policy is the right fit for providing read-only access to all users.

Resource: Buckets, objects, access points, and jobs are the Amazon S3 resources for which you can allow or deny permissions. In a policy, you use the Amazon Resource Name (ARN) to identify the resource. urn:aws:s3:::mybucket","urn:aws:s3:::mybucket/* are the resources for which the policy is defined.

Effect: Effect is the effect will be when the user requests the specific action—this can be either allow or deny. If you do not explicitly grant access to (allow) a resource, access is implicitly denied. You can also explicitly deny access to a resource.

Action: For each resource, Amazon S3 supports a set of operations called actions. GetObject and ListBucket actions help list the objects in the bucket and access the objects.

Principal: The account or user who is allowed access to the actions and resources in the statement. In a bucket policy, the principal is the user, account, service, or other entity that is the recipient of this permission. * signifies that any principal can access this S3 bucket.

Incorrect options:

{

 "Statement": [

   {

     "Sid": "AllowEveryoneReadOnlyAccess",

     "Effect": "Allow",

     "Principal": "*",

     "Action": [ "s3:ReadObject", "s3:ListBucket" ],

     "Resource": ["urn:aws:s3:::mybucket"]

   }

 ]

}

There is no action like s3:ReadObject. Hence, this policy is incorrect.

{

 "Statement": [

   {

     "Sid": "ReadOnlyAccess",

     "Effect": "read-only",

     "Principal": "*.*",

     "Action": [ "s3:GetObject", "s3:ListBucket" ],

     "Resource": ["urn:aws:s3:::mybucket*"]

   }

 ]

}

Effect can be either allow or deny. read-only is not a valid effect and hence this policy is incorrect.

{

 "Statement": [

   {

     "Sid": "AllowEveryoneReadOnlyAccess",

     "Effect": "deny",

     "Principal": ".",

     "Action": [ "s3:GetObject", "s3:GetBucket" ],

     "Resource": ["urn:aws:s3:::mybucket"]

   }

 ]

}

There is no GetBucket action. Moreover, deny will not provide the necessary permissions, as is the need for the use case.

Reference:

https://docs.amazonaws.cn/en_us/AmazonS3/latest/userguide/access-policy-language-overview.html

Correct option:

Amazon-issued certificates can’t be installed on an EC2 instance. To enable end-to-end encryption, you must use a third-party SSL certificate - Amazon-issued certificates can’t be installed on an EC2 instance. To enable end-to-end encryption for the given use case, you must use a third-party SSL certificate which should be installed on the EC2 instances. Then, associate the third-party certificate with a load balancer by importing it into AWS Certificate Manager (ACM).

Please check the first link in the reference section to know the detailed steps involved in implementing the above solution.

Incorrect options:

Import the Amazon-issued SSL certificate for the Load Balancer to the Amazon EC2 instances via the CLI - As discussed above, Amazon-issued certificates can’t be installed on an EC2 instance.

Use AWS Certificate Manager service to expose the existing certificate of Load Balancer to Amazon EC2 instances - AWS Certificate Manager (ACM) does not support installing Amazon-issued certificates on an EC2 instance. ACM certificates are supported by the following services: Elastic Load Balancing, Amazon CloudFront, AWS Elastic Beanstalk, AWS App Runner, Amazon API Gateway, AWS Nitro Enclaves, and AWS CloudFormation.

Use a self-signed certificate on Amazon EC2 instance to secure data - A self-signed certificate is acceptable for testing but not production. If you expose your self-signed certificate to the internet, visitors to your site would receive warm greetings in the form of security warnings.

References:

https://aws.amazon.com/premiumsupport/knowledge-center/acm-ssl-certificate-ec2-elb/

https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html

Correct option:

The ACM certificate wasn't requested in the same AWS Region as your load balancer

To use a third-party certificate with a load balancer, you can either import the certificate into ACM or upload a certificate to AWS Identity and Access Management (IAM).

You won't find the imported certificate or ACM certificate if: 1. The certificate imported into ACM is using an algorithm other than 1024-bit RSA or 2048-bit RSA.

The ACM certificate wasn't requested in the same AWS Region as your load balancer or CloudFront distribution.

ACM certificates must be requested or imported in the same AWS Region as your Classic Load Balancer or Application Load Balancer.

Incorrect options:

To use the ACM certificates with ALB, the certificates must be imported or requested in the US East (N. Virginia) Region only - This statement is incorrect. To use the ACM certificates with Amazon CloudFront (and not an ALB), the certificates must be imported or requested in the US East (N. Virginia) Region.

ACM is not directly integrated with ALB. You need to use Amazon CloudFront for using ACM certificates with ALB - This is incorrect. ACM is integrated with Elastic Load Balancing. ACM certificates are supported by the following services: Elastic Load Balancing, Amazon CloudFront, AWS Elastic Beanstalk, AWS App Runner, Amazon API Gateway, AWS Nitro Enclaves, and AWS CloudFormation.

ALB does not directly support ACM certificates. The certificate has to be installed on Amazon EC2 instance(s) backing the ALB - As discussed above, ACM supports ALB, so this option is incorrect.

References:

https://aws.amazon.com/premiumsupport/knowledge-center/acm-export-certificate/

https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html

Correct option:

Use the AWS Health API, to integrate health data and notifications with your existing in-house management tools

AWS Personal Health Dashboard provides a personalized view of the health of the specific services that are powering your workloads and applications. Personal Health Dashboard proactively notifies you when AWS experiences any events that may affect you, helping provide quick visibility and guidance to help you minimize the impact of events in progress, and plan for any scheduled changes, such as AWS hardware maintenance.

The AWS Health API provides programmatic access to the AWS Health information that appears in the AWS Personal Health Dashboard. You can use the API operations to get information about events that might affect your AWS services and resources.

You must have a Business or Enterprise Support plan from AWS Support to use the AWS Health API. If you call the AWS Health API from an AWS account that doesn't have a Business or Enterprise Support plan, you receive a SubscriptionRequiredException error.

Incorrect options:

Use the Service Health Dashboard to view the status of each AWS service and their impact on your AWS resources - The Service Health Dashboard is a good way to view the overall status of each AWS service, but does not provide specific information in terms of how the health of those services is impacting your resources.

Use the Trusted Advisor notification feature to help you stay up-to-date with the current status of your AWS resources - The Trusted Advisor notification feature helps you stay up-to-date with your AWS resource deployment. You will be notified by weekly email when you opt-in for this service. However, the notification is about the resource deployment status and not the resource current status which is the main requirement for the given use case.

Run diagnostics directly inside AWS Personal Health Dashboard with the help of Lambda functions and integrate the outcome with your existing in-house management tools - At this time, running diagnostics directly inside AWS Personal Health Dashboard is not possible. However, you could attach a diagnostics automation script that will be executed by Lambda when an event occurs provided that the event is wired appropriately.

References:

https://docs.aws.amazon.com/health/latest/APIReference/Welcome.html

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