Correct option:

Network ACLs are stateless, so you must allow both inbound and outbound traffic. Enable outbound traffic to fix the connectivity issue - 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:

1.Inbound traffic on the port that the service is listening on

2.Outbound traffic to 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 becomes the destination port for return traffic from the service. Outbound traffic to 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 to the ephemeral port range.

Incorrect options:

Security Groups are stateless, so you must allow both inbound and outbound traffic. Enable outbound traffic to fix the connectivity issue - This statement is incorrect. Security groups are stateful, so allowing inbound traffic to the necessary ports enables the connection.

Internet Gateway should be configured to access Amazon EC2 instance from the internet - If you accept traffic from the internet, then you also must establish a route through an internet gateway. The use case does not mention anything about access over the internet, hence this option is not the right choice.

Use multiple Availability Zone deployments so you have high availability - AWS best practices suggest using multiple Availability Zone deployments for high availability. However, the connection to services running on EC2 instances should be possible irrespective of the deployment type chosen. Hence, this option is not correct for the given issue.

Reference:

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules

Correct options:

Enable CloudTrail log file integrity validation - Validated log files are invaluable in security and forensic investigations. For example, a validated log file enables you to assert positively that the log file itself has not changed, or that particular user credentials performed specific API activity. The CloudTrail log file integrity validation process also lets you know if a log file has been deleted or changed, or assert positively that no log files were delivered to your account during a given period of time.

When you enable log file integrity validation, CloudTrail creates a hash for every log file that it delivers. Every hour, CloudTrail also creates and delivers a file that references the log files for the last hour and contains a hash of each. This file is called a digest file. CloudTrail signs each digest file using the private key of a public and private key pair. After delivery, you can use the public key to validate the digest file. CloudTrail uses different key pairs for each AWS region.

Use Amazon S3 MFA Delete on the S3 bucket that holds CloudTrail logs and digest files - The digest files are delivered to the same Amazon S3 bucket associated with your trail as your CloudTrail log files. If your log files are delivered from all regions or from multiple accounts into a single Amazon S3 bucket, CloudTrail will deliver the digest files from those regions and accounts into the same bucket.

Configuring multi-factor authentication (MFA) ensures that any attempt to change the versioning state of your bucket or permanently delete an object version requires additional authentication. This helps prevent any operation that could compromise the integrity of your log files, even if a user acquires the password of an IAM user that has permission to permanently delete Amazon S3 objects.

Incorrect options:

Enable Versioning on Amazon S3 buckets that store CloudTrail logs and digest files - Versioning in Amazon S3 is a means of keeping multiple variants of an object in the same bucket. You can use the S3 Versioning feature to preserve, retrieve, and restore every version of every object stored in your buckets. With versioning, you can recover from both unintended user actions and application failures. Versioning would allow you to change the logs without raising any alarm/warning/notice.

Integrate with Amazon CloudWatch alarms to generate an alarm whenever changes are made to CloudTrail log files - CloudTrail and CloudWatch are closely integrated and it is possible to implement something like this. However, this requires additional effort compared to the correct options.

To prevent access rights violation, use AWS root user account to manage CloudTrail logs - Root user account should not be used for any operational use cases as a security best practice, so this option is incorrect.

References:

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-intro.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/best-practices-security.html

Correct option:

Use AWS Key Management Service (SSE-KMS) for encrypting objects in Amazon S3 buckets - When you use server-side encryption with AWS KMS (SSE-KMS), you can use the default AWS managed CMK, or you can specify a customer-managed CMK that you have already created. If you want to use a customer-managed CMK for SSE-KMS, create the CMK before you configure SSE-KMS. Then, when you configure SSE-KMS for your bucket, specify the existing customer-managed CMK.

Creating your own customer-managed CMK gives you more flexibility and control. For example, you can create, rotate, and disable customer-managed CMKs. You can also define access controls and audit the customer-managed CMKs that you use to protect your data. You can use AWS KMS to manage the lifecycle of the key material within AWS.

When you configure server-side encryption using AWS KMS (SSE-KMS), you can configure your bucket to use S3 Bucket Keys for SSE-KMS. This bucket-level key for SSE-KMS can reduce your KMS request costs by up to 99 percent by decreasing the request traffic from Amazon S3 to AWS KMS.

https://docs.aws.amazon.com/whitepapers/latest/kms-best-practices/aws-managed-and-customer-managed-cmks.html

Incorrect options:

Use Amazon S3-Managed Keys (SSE-S3) for encrypting objects in Amazon S3 buckets - 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 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).

There are no new charges for using server-side encryption with Amazon S3-managed keys (SSE-S3). However, requests to configure and use SSE-S3 incur standard Amazon S3 request charges. Audit trail and lifecycle management is not possible with SSE-S3. So this option is incorrect.

Use Customer-Provided Keys (SSE-C) for encrypting objects in Amazon S3 buckets - Using server-side encryption with customer-provided encryption keys (SSE-C) allows you to set your own encryption keys. With the encryption key you provide as part of your request, Amazon S3 manages the encryption as it writes to disks and decryption when you access your objects.

When you upload an object, Amazon S3 uses the encryption key you provide to apply AES-256 encryption to your data and removes the encryption key from memory. When you retrieve an object, you must provide the same encryption key as part of your request. Amazon S3 first verifies that the encryption key you provided matches and then decrypts the object before returning the object data to you. In SSE-C, the customer needs to manage and maintain encryption keys and decryption keys, which are passed with every request. Although you could develop a solution on client side that supports lifecycle management and audit for the cryptographic key material, however, it would take significant development and maintenance time. Hence this option is not the right fit for the given use case.

Use client-side encryption to have full control over encryption and decryption process - Server-side encryption is the encryption of data at its destination by the application or service that receives it. Amazon S3 encrypts your data at the object level as it writes it to disks in its data centers and decrypts it for you when you access it.

Whereas, in client-side Encryption, you encrypt data on the client-side and upload the encrypted data to Amazon S3. In this case, you manage the encryption process, the encryption keys, and related tools. The given use case mandates that the encryption should happen on S3, so this option is ruled out.

References:

https://docs.aws.amazon.com/whitepapers/latest/kms-best-practices/aws-managed-and-customer-managed-cmks.html

https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html

https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingEncryption.html

Correct option:

You cannot disable Availability Zones for a Network Load Balancer after you create it - You enable one or more Availability Zones for your load balancer when you create it. If you enable multiple Availability Zones for your load balancer, this increases the fault tolerance of your applications. You cannot disable Availability Zones for a Network Load Balancer after you create it, but you can enable additional Availability Zones.

Incorrect options:

The Elastic IP address of the subnet specified for the Availability Zone needs to be detached in order to disable the Availability Zone - When you create an internet-facing load balancer, you can optionally specify one Elastic IP address per subnet. You cannot change these Elastic IP addresses after you create the load balancer.

The subnet specified for the given Availability Zone needs to be deleted in order to disable the Availability Zone - When you enable an Availability Zone, you specify one subnet from that Availability Zone. Elastic Load Balancing creates a load balancer node in the Availability Zone and a network interface for the subnet. Deleting a subnet will not disable the AZ.

All the targets in the Availability Zone need to be deleted so that the Availability Zone can be disabled for the NLB - This is incorrect. Deleting the targets will not disable the AZ.

Reference:

https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html

Correct options:

For stored volumes gateways, you can recover data from your most recent Amazon EBS snapshot of the volume - If your gateway or virtual machine malfunctions, you can recover data that has been uploaded to AWS and stored on a volume in Amazon S3. For cached volumes gateways, you recover data from a recovery snapshot. For stored volumes gateways, you can recover data from your most recent Amazon EBS snapshot of the volume. For tape gateways, you recover one or more tapes from a recovery point to a new tape gateway.

If your file system gets corrupted, you can use the fsck command to repair it - If your file system gets corrupted, you can use the fsck command to check your file system for errors and repair it. If you can repair the file system, you can then recover your data from the volumes on the file system.

Incorrect options:

Recover the failed Gateway VM from your Amazon EC2 Amazon Machine Image (AMI)

Recover the failed Gateway VM from a snapshot that is created by your hypervisor

These two options are incorrect. Storage Gateway doesn’t support recovering a gateway VM from a snapshot that is created by your hypervisor or from your Amazon EC2 Amazon Machine Image (AMI). If your gateway VM malfunctions, you need to activate a new gateway and recover your data to that gateway using the instructions provided by AWS.

If the status of your volume is IRRECOVERABLE, you can no longer recover data from this volume - If the status of your volume is IRRECOVERABLE, you can no longer use this volume. For stored volumes, you can retrieve your data from the irrecoverable volume to a new volume by using the following steps:

1.Create a new volume from the disk that was used to create the irrecoverable volume.

2.Preserve existing data when you are creating the new volume.

3.Delete all pending snapshot jobs for the irrecoverable volume.

4.Delete the irrecoverable volume from the gateway.

Reference:

https://docs.aws.amazon.com/storagegateway/latest/userguide/recover-data-from-gateway.html

Correct option:

Amazon ElastiCache for Memcached - Amazon ElastiCache is a web service that makes it easy to deploy, operate, and scale an in-memory data store and cache in the cloud. The service improves the performance of web applications by allowing you to retrieve information from fast, managed, in-memory data stores, instead of relying entirely on slower disk-based databases.

Memcached is a widely adopted memory object caching system. ElastiCache is protocol compliant with Memcached, so popular tools that you use today with existing Memcached environments will work seamlessly with the service.

Amazon ElastiCache automatically detects and replaces failed nodes, reducing the overhead associated with self-managed infrastructures and providing a resilient system that mitigates the risk of overloaded databases, which slow website and application load times. Through integration with Amazon CloudWatch, Amazon ElastiCache provides enhanced visibility into key performance metrics associated with your Redis or Memcached nodes.

Amazon ElastiCache supports the Memcached and Redis cache engines. Each engine provides some advantages. Choose Memcached if the following apply to you: 1. You need the simplest model possible. 2. You need to run large nodes with multiple cores or threads. 3. You need the ability to scale out and in, adding and removing nodes as demand on your system increases and decreases. 4. You need to cache objects.

Comparing caching solutions from AWS: 

https://aws.amazon.com/caching/

Incorrect options:

Amazon ElastiCache for Redis - Redis is a fast, open-source, in-memory data store and cache. Amazon ElastiCache for Redis is a Redis-compatible in-memory service that delivers the ease-of-use and power of Redis along with the availability, reliability, and performance suitable for the most demanding applications. Redis is extremely powerful and offers a lot of features compared to Memcached. Therefore, it's a little complex compared to Memcached.

Amazon DynamoDB Accelerator (DAX) - Amazon DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache for DynamoDB that delivers up to a 10x performance improvement – from milliseconds to microseconds – even at millions of requests per second. DAX does all the heavy lifting required to add in-memory acceleration to your DynamoDB tables, without requiring developers to manage cache invalidation, data population, or cluster management.

Amazon CloudFront - Amazon CloudFront is a global content delivery network (CDN) service that accelerates the delivery of your websites, APIs, video content, or other web assets. It integrates with other Amazon Web Services products to give developers and businesses an easy way to accelerate content to end-users with no minimum usage commitments. CloudFront offers caching solutions at the web application level, whereas Amazon ElastiCache offers at database level too, which is the current requirement.

References:

https://aws.amazon.com/caching/

https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/SelectEngine.html

Correct option:

AWS OpsHub

The Snow Family Devices offers a user-friendly tool, AWS OpsHub for Snow Family, that you can use to manage your devices and local AWS services. You use AWS OpsHub on a client computer to perform tasks such as unlocking and configuring single or clustered devices, transferring files, and launching and managing instances running on Snow Family Devices. You can use AWS OpsHub to manage both the Storage Optimized and Compute Optimized device types and the Snow device. The AWS OpsHub application is available at no additional cost to you.

AWS OpsHub takes all the existing operations available in the Snowball API and presents them as a graphical user interface. This interface helps you quickly migrate data to the AWS Cloud and deploy edge computing applications on Snow Family Devices.

When your Snow device arrives at your site, you download, install, and launch the AWS OpsHub application on a client machine, such as a laptop. After installation, you can unlock the device and start managing it and using supported AWS services locally. AWS OpsHub provides a dashboard that summarizes key metrics such as storage capacity and active instances on your device. It also provides a selection of AWS services that are supported on the Snow Family Devices. Within minutes, you can begin transferring files to the device.

Incorrect options:

AWS Control Tower - For customers with multiple AWS accounts and teams, cloud setup and governance can be complex and time-consuming, slowing down the very innovation you’re trying to speed up. AWS Control Tower provides the easiest way to set up and govern a secure, multi-account AWS environment, called a landing zone. AWS Control Tower creates your landing zone using AWS Organizations, bringing ongoing account management and governance as well as implementation best practices based on AWS’s experience working with thousands of customers as they move to the cloud. With AWS Control Tower, builders can provision new AWS accounts in a few clicks, while you have peace of mind knowing that your accounts conform to company-wide policies.

Service Workbench on AWS - Service Workbench on AWS is a cloud solution that enables IT teams, to provide secure, repeatable, and federated control of access to data, tooling, and compute power that researchers need. research missions and completing essential work in minutes, not months, in configured research environments.

With Service Workbench on AWS, researchers can quickly and securely stand up research environments and conduct experiments with peers from other institutions. By automating the creation of baseline research setups, simplifying data access, and providing price transparency, researchers and IT departments save time, which they can reinvest in following cloud best practices and achieving research reproducibility.

AWS OpsWorks - AWS OpsWorks is a configuration management service that provides managed instances of Chef and Puppet. Chef and Puppet are automation platforms that allow you to use code 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.

Reference:

https://docs.aws.amazon.com/snowball/latest/developer-guide/aws-opshub.html

Correct option:

Configure Amazon S3 Access Points on S3 buckets - Amazon S3 Access Points is a feature of S3 that simplifies managing data access at scale for applications using shared data sets on S3. Access points are unique hostnames that customers create to enforce distinct permissions and network controls for any request made through the access point. Customers with shared data sets including data lakes, media archives, and user-generated content can easily scale access for hundreds of applications by creating individualized access points with names and permissions customized for each application. Any access point can be restricted to a Virtual Private Cloud (VPC) to firewall S3 data access within customers’ private networks, and AWS Service Control Policies can be used to ensure all access points are VPC restricted. S3 Access Points are now available in all regions at no additional cost.

Each S3 Access Point is configured with an access policy specific to a use case or application. For example, you can create an access point for your S3 bucket that grants access to groups of users or applications for your data lake. An S3 Access Point could support a single user or application, or groups of users or applications, allowing separate management of each access point.

Every access point is associated with a single bucket and contains a network origin control and a Block Public Access control. For example, you can create an access point with a network origin control that only permits storage access from your Virtual Private Cloud, a logically isolated section of the AWS Cloud. You can also create an access point with the access point policy configured to only allow access to objects with a defined prefix, such as “finance”.

Because each access point contains a unique DNS name, you can now address existing and new buckets with any name of your choice that is unique within the AWS account and region. Using access points that are restricted to a VPC, you can now have an easy, auditable way to make sure S3 data stays within your VPC. Additionally, you can now use AWS Service Control Policies to require any new access point in their organization to be restricted to VPC only access.

How S3 Access Points work: 

https://aws.amazon.com/s3/features/access-points/

When to use S3 Access Points: 

https://aws.amazon.com/s3/features/access-points/

Incorrect options:

Configure Amazon S3 VPC Endpoints for the buckets - A VPC endpoint enables private connections between your VPC and supported AWS services and VPC endpoint services powered by AWSPrivateLink. A VPC endpoint does not require an internet gateway, virtual private gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in your VPC do not require public IP addresses to communicate with resources in the service. VPC endpoints cannot be used to manage access to shared data on S3.

Configure S3 Acceleration on the S3 bucket - Amazon S3 Transfer Acceleration can speed up content transfers to and from Amazon S3 by as much as 50%-500% for long-distance transfer of larger objects. Customers who have either web or mobile applications with widespread users or applications hosted far away from their S3 bucket can experience long and variable upload and download speeds over the Internet. S3 Transfer Acceleration (S3TA) reduces the variability in Internet routing, congestion, and speeds that can affect transfers, and logically shortens the distance to S3 for remote applications. S3TA cannot be used to manage access to shared data on S3.

Configure S3 Batch Operations to manage access to shared data on S3 - S3 Batch Operations is an Amazon S3 data management feature that lets you manage billions of objects at scale with just a few clicks in the Amazon S3 Management Console or a single API request. With this feature, you can make changes to object metadata and properties or perform other storage management tasks, such as copying objects between buckets, replacing object tag sets, modifying access controls, and restoring archived objects from S3 Glacier — instead of taking months to develop custom applications to perform these tasks. S3 Batch Operations cannot be used to manage access to shared data on S3.

Reference:

https://aws.amazon.com/s3/features/access-points/

Correct option:

Both the policies deny all update actions on the database with the MyDatabase logical ID. And they allow all update actions on all other stack resources

Policy-1 denies all update actions on the database with the MyDatabase logical ID. It allows all update actions on all other stack resources with an Allow statement. The Allow statement doesn't apply to the MyDatabase resource because the Deny statement always overrides allow actions.

You can achieve the same result by using a default denial. When you set a stack policy, AWS CloudFormation denies any update that is not explicitly allowed. Policy-2 allows updates to all resources except for the MyDatabase, which is denied by default.

If a stack policy includes overlapping statements (both allowing and denying updates on a resource), a Deny statement always overrides an Allow statement. To ensure that a resource is protected, use a Deny statement for that resource.

Incorrect options:

Policy-1 denies updates on MyDatabase, whereas, Policy-2 allows updates on MyDatabase

Policy-2 denies updates on MyDatabase, whereas, Policy-1 allows updates on MyDatabase

Both the policies allow updates on all resources

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

References:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/protect-stack-resources.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html#nested

Correct option:

Create a new gateway with the cache space that you need

Don't remove disks that are allocated as cache disks for an existing gateway—doing this can break your gateway's functionality. You can't decrease the size of a cache disk after it's allocated to an existing gateway. Instead, you must create a new gateway with the cache space that you need. Then, you can migrate your data to the new gateway.

Incorrect options:

Remove the disk(s) that are allocated as cache disks for the existing gateway and resize the disk to the capacity needed - As discussed above, removing cache disks can break the gateway's functionality and hence is not the right option.

Shut down the gateway before removing the disk. After the gateway is shut down, you can remove the cache disk and attach a different one - For disks that are allocated as upload buffer for an existing gateway, you need to first shut down the gateway before removing the disk. After the gateway is shut down, you can remove the upload buffer disk. Then, you can allocate a new disk with the reduced upload buffer size. This works for only disks allocated as upload buffers and not for cache disks.

Reduce the extra storage on the cache disk by decreasing the upload buffer size from Storage Gateway console - This is a made-up option, given only as a distractor.

References:

https://docs.aws.amazon.com/storagegateway/latest/userguide/ManagingLocalStorage-common.html

https://docs.aws.amazon.com/storagegateway/latest/userguide/migrate-data.html