Correct option:

Upload the compressed file using multipart upload with S3 transfer acceleration

Amazon S3 Transfer Acceleration enables fast, easy, and secure transfers of files over long distances between your client and an S3 bucket. Transfer Acceleration takes advantage of Amazon CloudFront’s globally distributed edge locations. As the data arrives at an edge location, data is routed to Amazon S3 over an optimized network path.

Multipart upload allows you to upload a single object as a set of parts. Each part is a contiguous portion of the object's data. You can upload these object parts independently and in any order. If transmission of any part fails, you can retransmit that part without affecting other parts. After all parts of your object are uploaded, Amazon S3 assembles these parts and creates the object. If you're uploading large objects over a stable high-bandwidth network, use multipart uploading to maximize the use of your available bandwidth by uploading object parts in parallel for multi-threaded performance. If you're uploading over a spotty network, use multipart uploading to increase resiliency to network errors by avoiding upload restarts.

Incorrect options:

Upload the compressed file in a single operation - In general, when your object size reaches 100 MB, you should consider using multipart uploads instead of uploading the object in a single operation. Multipart upload provides improved throughput - you can upload parts in parallel to improve throughput. Therefore, this option is not correct.

Upload the compressed file using multipart upload - Although using multipart upload would certainly speed up the process, combining with S3 transfer acceleration would further improve the transfer speed. Therefore just using multipart upload is not the correct option.

FTP the compressed file into an EC2 instance that runs in the same region as the S3 bucket. Then transfer the file from the EC2 instance into the S3 bucket - This is a roundabout process of getting the file into S3 and added as a distractor. Although it is technically feasible to follow this process, it would involve a lot of scripting and certainly would not be the fastest way to get the file into S3.

References:

https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html

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

Correct option:

Use the local directory /tmp

This is 512MB of temporary space you can use for your Lambda functions.

Incorrect options:

Create a tmp/ directory in the source zip file and use it - This option has been added as a distractor, as you can't access a directory within a zip file.

Use the local directory /opt - This option has been added as a distractor. This path is not accessible.

Use an S3 bucket - This won't be temporary after the Lambda function is deleted, so this option is incorrect.

Reference:

https://docs.aws.amazon.com/lambda/latest/dg/limits.html

Correct option:

!ImportValue

The intrinsic function Fn::ImportValue returns the value of an output exported by another stack. You typically use this function to create cross-stack references.

Incorrect options:

!Ref - Returns the value of the specified parameter or resource.

!GetAtt - Returns the value of an attribute from a resource in the template.

!Sub - Substitutes variables in an input string with values that you specify.

Reference:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-importvalue.html

Correct option:

SSE-KMS

You have the following options for protecting data at rest in Amazon S3:

Server-Side Encryption – Request Amazon S3 to encrypt your object before saving it on disks in its data centers and then decrypt it when you download the objects.

Client-Side Encryption – Encrypt data client-side and upload the encrypted data to Amazon S3. In this case, you manage the encryption process, the encryption keys, and related tools.

Server-Side Encryption with Customer Master Keys (CMKs) stored in AWS Key Management Service (SSE-KMS) is similar to SSE-S3. SSE-KMS provides you with an audit trail that shows when your CMK was used and by whom. Additionally, you can create and manage customer-managed CMKs or use AWS managed CMKs that are unique to you, your service, and your Region.

Please review these three options for Server Side Encryption on S3:

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

Incorrect options:

SSE-C When retrieving objects encrypted server-side with SSE-C, 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

Client-Side Encryption - You can encrypt the data client-side and upload the encrypted data to Amazon S3. In this case, you manage the encryption process, the encryption keys, and related tools.

SSE-S3 - When you use Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3), each object is encrypted with a unique key. As an additional safeguard, it encrypts the key itself with a master key that it regularly rotates. So this option is incorrect.

Reference:

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

Correct option:

Set up an EC2 service role with read-only permissions for the S3 bucket and attach the role to the EC2 instance profile

As an AWS security best practice, you should not create an IAM user and pass the user's credentials to the application or embed the credentials in the application. Instead, create an IAM role that you attach to the EC2 instance to give temporary security credentials to applications running on the instance. When an application uses these credentials in AWS, it can perform all of the operations that are allowed by the policies attached to the role.

So for the given use-case, you should create an IAM role with read-only permissions for the S3 bucket and apply it to the EC2 instance profile.

via - https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html

Incorrect options:

Set up an IAM user with read-only permissions for the S3 bucket. Configure AWS credentials for this user via AWS CLI on the EC2 instance

Set up an IAM user with read-only permissions for the S3 bucket. Configure the IAM user credentials in the user data of the EC2 instance

As mentioned in the explanation above, it is dangerous to pass an IAM user's credentials to the application or embed the credentials in the application or even configure these credentials in the user data of the EC2 instance. So both these options are incorrect.

Set up an S3 service role with read-only permissions for the S3 bucket and attach the role to the EC2 instance profile - As the application is running on EC2 instances, therefore you need to set up an EC2 service role, not an S3 service role.

Reference:

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

Correct option:

AWS FIFO queues are designed to enhance messaging between applications when the order of operations and events has to be enforced.

via - https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html

MessageGroupId

The message group ID is the tag that specifies that a message belongs to a specific message group. Messages that belong to the same message group are always processed one by one, in a strict order relative to the message group (however, messages that belong to different message groups might be processed out of order).

Incorrect options:

MessageDeduplicationId - The message deduplication ID is the token used for the deduplication of sent messages. If a message with a particular message deduplication ID is sent successfully, any messages sent with the same message deduplication ID are accepted successfully but aren't delivered during the 5-minute deduplication interval.

MessageOrderId - This is a made-up option and has been added as a distractor.

MessageHash - This is a made-up option and has been added as a distractor.

References:

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html

Correct option:

AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume.

How Lambda function works: 

via - https://aws.amazon.com/lambda/

Put the function and the dependencies in one folder and zip them together

A deployment package is a ZIP archive that contains your function code and dependencies. You need to create a deployment package if you use the Lambda API to manage functions, or if you need to include libraries and dependencies other than the AWS SDK. You can upload the package directly to Lambda, or you can use an Amazon S3 bucket, and then upload it to Lambda. If the deployment package is larger than 50 MB, you must use Amazon S3. This is the standard way of packaging Lambda functions.

Incorrect options:

Zip the function as-is with a package.json file so that AWS Lambda can resolve the dependencies for you

Upload the code through the AWS console and upload the dependencies as a zip

Zip the function and the dependencies separately and upload them in AWS Lambda as two parts

These three options are incorrect as there's only one way of deploying a Lambda function, which is to provide the zip file with all dependencies that it'll need.

Reference:

https://docs.aws.amazon.com/lambda/latest/dg/nodejs-create-deployment-pkg.html

Correct option:

The S3 bucket policy authorizes reads

When evaluating an IAM policy of an EC2 instance doing actions on S3, the least-privilege union of both the IAM policy of the EC2 instance and the bucket policy of the S3 bucket are taken into account.

For the given use-case, as IAM role has been removed, therefore only the S3 bucket policy comes into effect which authorizes reads.

Here is a great reference blog for understanding the various scenarios for using IAM policy vs S3 bucket policy - https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/

Incorrect options:

The EC2 instance is using cached temporary IAM credentials - As the IAM instance role has been removed that wouldn't be the case

Removing an instance role from an EC2 instance can take a few minutes before being active - It is immediately active and even if it wasn't, it wouldn't make sense as we can still do reads but not writes.

When a read is done on a bucket, there's a grace period of 5 minutes to do the same read again - This is not true. Every single request is evaluated against IAM in the AWS model.

Reference:

https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/

Correct option:

Implement a Dead Letter Queue

Dead-letter queues can be used by other queues (source queues) as a target for messages that can't be processed (consumed) successfully. Dead-letter queues are useful for debugging your application or messaging system because they let you isolate problematic messages to determine why their processing doesn't succeed.

Sometimes, messages can’t be processed because of a variety of possible issues, such as when a user comments on a story but it remains unprocessed because the original story itself is deleted by the author while the comments were being posted. In such a case, the dead-letter queue can be used to handle message processing failures.

How do dead-letter queues work?

via - https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html

Use-cases for dead-letter queues:

via - https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html

Amazon SQS supports dead-letter queues, which other queues (source queues) can target for messages that cannot be processed (consumed) successfully. Dead-letter queues are useful for debugging your application or messaging system because they let you isolate problematic messages to determine why their processing doesn't succeed.

Incorrect:

Use DeleteMessage - This API call deletes the message in the queue but does not help you find the issue.

Reduce the VisibilityTimeout - Amazon SQS uses a visibility timeout to prevent other consumers from receiving and processing the same message. The default visibility timeout for a message is 30 seconds. The minimum is 0 seconds. The maximum is 12 hours. If you reduce the VisibilityTimeout, more consumers will get the failed message

Increase the VisibilityTimeout - It won't help because you don't need more time but rather an isolated place to debug.

Reference:

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html

Correct option:

It should be accessible by one admin only after enabling Multi-factor authentication

AWS Root Account Security Best Practices:  via - https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials

If you continue to use the root user credentials, we recommend that you follow the security best practice to enable multi-factor authentication (MFA) for your account. Because your root user can perform sensitive operations in your account, adding a layer of authentication helps you to better secure your account. Multiple types of MFA are available.

Incorrect options:

It should be accessible by 3 to 6 members of the IT team - Only the owner of the AWS account should have access to the root account credentials. You should create an IT group with admin permissions via IAM and then assign a few users to this group.

It should be accessible using the access key id and secret access key - AWS recommends that you should not use the access key id and secret access key for the AWS account root user.

It should be accessible by no one, throw away the passwords after creating the account - You will still need to store the password somewhere for your root account.

Reference:

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials