Correct option:

Initialize the EBS volume or pre-warm it before moving the volumes to production

There is a significant increase in latency when you first access each block of data on a new EBS volume that was created from a snapshot. You can avoid this performance lag by using one of the following options:

Access each block before putting the volume into production. This process is called initialization (formerly known as pre-warming).

Enable fast snapshot to restore on a snapshot to ensure that the EBS volumes created from it are fully-initialized at creation and instantly deliver all of their provisioned performance.

Incorrect options:

Increase read-ahead for high-throughput, read-heavy workloads on st1 and sc1 - Some workloads are read-heavy and access the block device through the operating system page cache (for example, from a file system). In this case, to achieve the maximum throughput, AWS recommends that you configure the read-ahead setting to 1 MiB. This is a per-block-device setting that should only be applied to your HDD volumes.

Use RAID 0 to maximize utilization of instance resources - Some instance types can drive more I/O throughput than what you can provision for a single EBS volume. You can join multiple volumes together in a RAID 0 configuration to use the available bandwidth for these instances.

Use an Amazon EBS–optimized instance - An Amazon EBS–optimized instance uses an optimized configuration stack and provides additional, dedicated capacity for Amazon EBS I/O. This optimization provides the best performance for your EBS volumes by minimizing contention between Amazon EBS I/O and other traffic from your instance.

All of the three options above are meant to improve the performance of EBS volumes in general. But, the requirement for the given use case is best achieved by just pre-warming the volumes.

References:

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

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

Correct options:

You cannot use ACM certificates for email encryption - Indeed, ACM certificates cannot be used for email encryption.

ACM provides certificates for SSL/TLS protocols only - AWS Certificate Manager (ACM) handles the complexity of creating, storing, and renewing public and private SSL/TLS X.509 certificates and keys that protect your AWS websites and applications. Therefore, ACM does not provide certificates for anything other than the SSL/TLS protocols.

Exceptions for ACM certifications:

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

Incorrect options:

ACM helps you request certificates for Amazon-owned domain names - You cannot request certificates for Amazon-owned domain names such as those ending in amazonaws.com, cloudfront.net, or elasticbeanstalk.com.

You can install an ACM certificate on your application running on an Amazon EC2 instance - You cannot directly install ACM certificates on your Amazon Elastic Compute Cloud (Amazon EC2) website or application. You can, however, use your certificate with any integrated service like Amazon CloudFront, Elastic Load Balancer, etc.

The private key for an ACM certificate can only be downloaded from an AWS root user account - This is incorrect. You cannot download the private key for an ACM certificate.

Reference:

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

Correct option:

Allowing you to assign IAM Roles to EC2 if they start with RDS-

To configure many AWS services, you must pass an IAM role to the service. This allows the service to later assume the role and perform actions on your behalf. You only have to pass the role to the service once during set-up, and not every time that the service assumes the role.

To pass a role (and its permissions) to an AWS service, a user must have permission to pass the role to the service. This helps administrators ensure that only approved users can configure a service with a role that grants permissions. To allow a user to pass a role to an AWS service, you must grant the PassRole permission to the user's IAM user, role, or group.

For the given policy, the first statement block applies only to EC2 specific actions, and the second statement block applies to roles only starting with RDS-, so the overall policy allows you to assign IAM Roles to EC2 if they start with "RDS-".

Incorrect options:

Allowing you to give any role to RDS instances

Allowing you to give any role to EC2 instances

Allowing you to give RDS full access to EC2 instances

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

Reference:

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

Correct option:

Security Groups are stateful, so allowing inbound traffic to the necessary ports enables the connection. Network ACLs are stateless, so you must allow both inbound and outbound traffic - Security groups are stateful, so allowing inbound traffic to the necessary ports enables the connection. Network ACLs are stateless, so you must allow both inbound and outbound traffic.

To enable the connection to a service running on an instance, the associated network ACL must allow both inbound traffic on the port that the service is listening on as well as allow outbound traffic from ephemeral ports. When a client connects to a server, a random port from the ephemeral port range (1024-65535) becomes the client's source port.

The designated ephemeral port then becomes the destination port for return traffic from the service, so outbound traffic from the ephemeral port must be allowed in the network ACL.

By default, network ACLs allow all inbound and outbound traffic. If your network ACL is more restrictive, then you need to explicitly allow traffic from the ephemeral port range.

If you accept traffic from the internet, then you also must establish a route through an internet gateway. If you accept traffic over VPN or AWS Direct Connect, then you must establish a route through a virtual private gateway.

Incorrect options:

Network ACLs are stateful, so allowing inbound traffic to the necessary ports enables the connection. Security Groups are stateless, so you must allow both inbound and outbound traffic - This is incorrect as already discussed.

IAM Role defined in the Security Group is different from the IAM Role that is given access in the Network ACLs - This is a made-up option and just added as a distractor.

Rules associated with Network ACLs should never be modified from the command line. An attempt to modify rules from the command line blocks the rule and results in an erratic behavior - This option is a distractor. AWS does not support modifying rules of Network ACLs from the command line tool.

Reference:

https://aws.amazon.com/premiumsupport/knowledge-center/resolve-connection-sg-acl-inbound/

Correct option:

Configure ASG to scale based on demand - When you configure dynamic scaling ( Scaling on Demand), you define how to scale the capacity of your Auto Scaling group in response to changing demand.

For example, let's say that you have a web application that currently runs on two instances, and you want the CPU utilization of the Auto Scaling group to stay at around 50 percent when the load on the application changes. This gives you extra capacity to handle traffic spikes without maintaining an excessive number of idle resources.

You can configure your Auto Scaling group to scale dynamically to meet this need by creating a scaling policy. Amazon EC2 Auto Scaling can then scale out your group (add more instances) to deal with high demand at peak times, and scale in your group (run fewer instances) to reduce costs during periods of low utilization.

Incorrect options:

Configure ASG to use predictive scaling - You can also use Amazon EC2 Auto Scaling in combination with AWS Auto Scaling to scale resources across multiple services. AWS Auto Scaling can help you maintain optimal availability and performance by combining predictive scaling and dynamic scaling (proactive and reactive approaches, respectively) to scale your Amazon EC2 capacity faster. Scaling based on demand is a direct way to achieve the current requirement and hence is the correct option.

Configure ASG to scale based on a schedule - Scaling by schedule means that scaling actions are performed automatically as a function of time and date. This is useful when you know exactly when to increase or decrease the number of instances in your group, simply because the need arises on a predictable schedule.

Configure ASG to scale based on events - This is a made-up option and given only as a distractor.

References:

https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html

https://docs.aws.amazon.com/autoscaling/ec2/userguide/scaling_plan.html

Correct option:

You cannot manually associate or disassociate a public IP address from your instance - A public IP address is assigned to your instance from Amazon's pool of public IPv4 addresses, and is not associated with your AWS account. You cannot manually associate or disassociate a public IP address from your instance.

By default, Amazon EC2 and Amazon VPC use the IPv4 addressing protocol; you can't disable this behavior - Amazon EC2 and Amazon VPC support both the IPv4 and IPv6 addressing protocols. By default, Amazon EC2 and Amazon VPC use the IPv4 addressing protocol; you can't disable this behavior. When you create a VPC, you must specify an IPv4 CIDR block (a range of private IPv4 addresses). You can optionally assign an IPv6 CIDR block to your VPC and subnets, and assign IPv6 addresses from that block to instances in your subnet.

If the public IP address of your instance in a VPC has been released, it will not receive a new one if there is more than one network interface attached to your instance - If the public IP address of your instance in a VPC has been released, it will not receive a new one if there is more than one network interface attached to your instance. If your instance's public IP address is released while it has a secondary private IP address that is associated with an Elastic IP address, the instance does not receive a new public IP address.

Incorrect options:

AWS releases your instance's public IP address when it is stopped or terminated. However, the IP address is retained if the instance is hibernated - AWS releases your instance's public IP address when it is stopped, hibernated, or terminated. Your stopped or hibernated instance receives a new public IP address when it is started.

An instance can have both - a public IP address and an Elastic IP address with it - AWS releases your instance's public IP address when you associate an Elastic IP address with it. When you disassociate the Elastic IP address from your instance, it receives a new public IP address.

By default, AWS assigns a public IP address to instances launched in both default and non-default VPCs - When you launch an instance in a default VPC, AWS assigns it a public IP address by default. When you launch an instance into a non-default VPC, the subnet has an attribute that determines whether instances launched into that subnet receive a public IP address from the public IPv4 address pool. By default, AWS does not assign a public IP address to instances launched in a non-default subnet.

Reference:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html

Correct option:

Create the rule with configuration change and periodic triggers - When you add a rule to your account, you can specify when you want AWS Config to run the rule; this is called a trigger. AWS Config evaluates your resource configurations against the rule when the trigger occurs. There are two types of triggers:

1.Configuration changes: AWS Config runs evaluations for the rule when certain types of resources are created, changed, or deleted.

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

If you choose configuration changes and periodic, AWS Config invokes your Lambda function when it detects a configuration change and also at the frequency that you specify. This is the requirement for the current use case.

Incorrect options:

Create the rule with configuration change - AWS Config runs evaluations for the rule when certain types of resources are created, changed, or deleted. This will meet the trigger on trail creation requirement. But, the requirement to run the rule every 8 hours will not be met.

Create the rule with periodic triggers - AWS Config runs evaluations for the rule at a frequency that you choose (for example, every 24 hours). This will not cater to the requirement of triggering the rule when a trail is created. Hence, this is not the right choice.

Create two rules, one with configuration change and the other with periodic triggers - This will be a management overhead and hence is not an optimal solution.

Reference:

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

Correct option:

The number of HTTP 4XX client error codes that originate from the load balancer - HTTPCode_ELB_4XX_Count metric stands for the number of HTTP 4XX client error codes that originate from the load balancer. This count does not include response codes generated by targets.

Client errors are generated when requests are malformed or incomplete. These requests were not received by the target, other than in the case where the load balancer returns an HTTP 460 error code. This count does not include any response codes generated by the targets.

Incorrect options:

The number of HTTP 4XX response codes generated by ELB targets - As discussed above, this is incorrect.

The number of TLS connections initiated by the client that did not establish a session with the load balancer - ClientTLSNegotiationErrorCount metric stands for the number of TLS connections initiated by the client that did not establish a session with the load balancer due to a TLS error. Possible causes include a mismatch of ciphers or protocols or the client failing to verify the server certificate and closing the connection.

The number of requests where the load balancer chose a new target because it couldn't use an existing sticky session - The metric NonStickyRequestCount represents the number of requests where the load balancer chose a new target because it couldn't use an existing sticky session.

Reference:

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

Correct option:

CloudHSM

AWS CloudHSM is a service for creating and managing cloud-based hardware security modules. A hardware security module (HSM) is a specialized security device that generates and stores cryptographic keys.

You should use AWS CloudHSM when you need to manage the HSMs that generate and store your encryption keys. In AWS CloudHSM, you create and manage HSMs, including creating users and setting their permissions. You also create the symmetric keys and asymmetric key pairs that the HSM stores.

Incorrect options:

KMS - If you need to secure your encryption keys in a service backed by FIPS-validated HSMs, but you do not need to manage the HSM, you should use AWS Key Management Service (KMS).

When you encrypt data, you need to protect your encryption key. If you encrypt your key, you need to protect its encryption key. Eventually, you must protect the highest level encryption key (known as a master key) in the hierarchy that protects your data. That's where AWS KMS comes in.

KMS lets you create, store, and manage customer master keys (CMKs) securely. Your CMKs never leave AWS KMS unencrypted. To use a CMK in a cryptographic operation, you call KMS.

KMS does not offer a self-managed encryption module.

S3 SSE - Server-side encryption protects data at rest. Amazon S3 encrypts each object with a unique key. As an additional safeguard, it encrypts the key itself with a master key that it rotates regularly. Amazon S3 server-side encryption uses one of the strongest block ciphers available to encrypt your data, 256-bit Advanced Encryption Standard (AES-256).

S3 SSE does not offer a self-managed encryption module.

GuardDuty - GuardDuty is a threat detection service that monitors malicious activity and unauthorized behavior to protect your AWS account. GuardDuty analyzes billions of events across your AWS accounts from AWS CloudTrail (AWS user and API activity in your accounts), Amazon VPC Flow Logs (network traffic data), and DNS Logs (name query patterns). GuardDuty cannot be used to segregate the environment your employees work in based on the department they belong to.

How GuardDuty Works: 

https://aws.amazon.com/guardduty/

References:

https://docs.aws.amazon.com/cloudhsm/latest/userguide/introduction.html

https://docs.aws.amazon.com/crypto/latest/userguide/awscryp-choose-hsm.html

https://docs.aws.amazon.com/crypto/latest/userguide/awscryp-choose-kms.html

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

Correct option:

CloudTrail can deliver log files from multiple regions to a single Amazon S3 bucket

You can configure CloudTrail to deliver log files from multiple regions to a single S3 bucket for a single account. For example, you have a trail in the US West (Oregon) Region that is configured to deliver log files to an S3 bucket, and a CloudWatch Logs log group. When you change an existing single-region trail to log all regions, CloudTrail logs events from all regions in your account. CloudTrail delivers log files to the same S3 bucket and CloudWatch Logs log group. As long as CloudTrail has permission to write to an S3 bucket, the bucket for a multi-region trail does not have to be in the trail's home region.

In the console, by default, you create a trail that logs events in all AWS Regions. This is a recommended best practice by AWS. Once you apply a trail in all regions, CloudTrail will create a new trail in all regions by replicating the trail configuration. CloudTrail will record and process the log files in each region and will deliver log files containing account activity across all AWS regions to a single S3 bucket and a single CloudWatch Logs log group. If you specified an optional SNS topic, CloudTrail will deliver SNS notifications for all log files delivered to a single SNS topic.

Incorrect options:

CloudTrail cannot log from multiple regions of an AWS account - As discussed above, this statement is incorrect.

CloudTrail can deliver logs to S3 buckets in the trail's home region. Configure an Amazon S3 bucket for each region to receive logs from all regions - As long as CloudTrail has permissions to write to an S3 bucket, the bucket for a multi-region trail does not have to be in the trail's home region.

It is not possible to enable CloudTrail in all regions of an AWS account from the console. This can only be done through CLI - This is incorrect. In the console, by default, you create a trail that logs events in all AWS Regions. To log events in a single region, you use the AWS CLI.

References:

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-concepts.html#cloudtrail-concepts-regional-and-global-services