Correct options:

The bucket owner has no permissions on those objects created by other AWS accounts

The bucket owner has no permissions on those objects created by other AWS accounts and is not the owner of objects created by other AWS accounts.

The AWS account that created the objects must first grant permission to the bucket owner for delegating permissions to other entities

The bucket owner has no permissions on those objects created by other AWS accounts. So for the bucket owner to grant permissions on objects it does not own, the object owner, the AWS account that created the objects, must first grant permission to the bucket owner. The bucket owner can then delegate those permissions.

Incorrect options:

The bucket owner is the owner of all objects in the bucket, irrespective of the AWS account that uploaded the objects - The bucket owner has no permissions on those objects created by other AWS accounts and is not the owner of objects created by other AWS accounts.

The owner should provide cross-account delegation to users in other AWS accounts - Bucket owner account can delegate permissions to users in its own account, but it cannot delegate permissions to other AWS accounts, because cross-account delegation is not supported.

The root user has access to all objects created under it. Use root user to delegate necessary permissions on objects in the S3 bucket - AWS strongly recommends that you do not use the root user for your everyday tasks, even the administrative ones. Root user credentials should only be used to perform a few account and service management tasks. In addition, the root user cannot do cross-account delegation for objects created by another AWS account.

Reference:

https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html

Correct options:

Use the elasticfilesystem:Encrypted IAM condition key in AWS IAM identity-based policies to mandate users for creating only encrypted-at-rest Amazon EFS file systems

You can create an AWS Identity and Access Management (IAM) identity-based policy to control whether users can create Amazon EFS file systems that are encrypted at rest. The Boolean condition key elasticfilesystem:Encrypted specifies the type of file system, encrypted or unencrypted, that the policy applies to. You use the condition key with the elasticfilesystem:CreateFileSystem action and the policy effect, allow or deny, to create a policy for creating encrypted or unencrypted file systems.

Define Service Control Policies (SCPs) inside AWS Organizations to enforce EFS encryption for all AWS accounts in your organization

Service control policies (SCPs) are a type of organization policy that you can use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization.

An SCP restricts permissions for IAM users and roles in member accounts, including the member account's root user. 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. You can also define service control policies (SCPs) inside AWS Organizations to enforce EFS encryption for all AWS accounts in your organization.

Incorrect options:

Encryption at rest is enabled by default when creating a new EFS file system using the AWS CLI. Mandate usage of CLI for creating new EFS file systems - This statement is incorrect. Encryption at rest is not enabled by default when creating a new file system using the AWS CLI.

Encryption at rest is enabled by default when creating a new EFS file system using the AWS SDKs. Mandate usage of SDKs for creating new EFS file systems - This statement is incorrect. Encryption at rest is not enabled by default when creating a new file system using the SDKs or the API.

Use AWS Config to enforce the creation of only encrypted EFS file systems - AWS Config rules and conformance packs provide information about whether your resources are compliant with the configuration rules you specify. They will evaluate resource configurations against the Config rules either periodically or upon detecting configuration changes, or both, depending upon how you have configured the rule. They do not guarantee that resources will be compliant or prevent users from taking non-compliant actions.

References:

https://docs.aws.amazon.com/efs/latest/ug/using-iam-to-enforce-encryption-at-rest.html

https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html

Correct option:

DynamoDB Streams and AWS Lambda can be used to integrate DynamoDB seamlessly with the relational system

DynamoDB can take advantage of DynamoDB Streams and AWS Lambda to integrate seamlessly with one or more existing relational database systems. For this kind of integration to be implemented, essentially three kinds of interoperation must be provided:

1.Fill the DynamoDB cache incrementally - When an item is queried, look for it first in DynamoDB. If it is not there, look for it in the SQL system, and load it into DynamoDB.

2.Write through a DynamoDB cache - When a customer changes a value in DynamoDB, a Lambda function is triggered to write the new data back to the SQL system.

3.Update DynamoDB from the SQL system - When internal processes such as inventory management or pricing change a value in the SQL system, a stored procedure is triggered to propagate the change to the DynamoDB materialized view.

Integrating DynamoDB with relational systems: 

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-hybrid.html#bp-hybrid-problems

Incorrect options:

DynamoDB Accelerator (DAX) can be used to seamlessly integrate the relational system with DynamoDB - DAX is a DynamoDB-compatible caching service that enables you to benefit from fast in-memory performance for demanding applications. In most cases, the DynamoDB response times can be measured in single-digit milliseconds. However, there are certain use cases that require response times in microseconds. For these use cases, DynamoDB Accelerator (DAX) delivers fast response times for accessing eventually consistent data. DAX cannot integrate a relational database with DynamoDB.

Configure Kinesis Data Streams to carry real-time updates from the relational system to DynamoDB - Amazon Kinesis Data Streams (KDS) is a massively scalable and durable real-time data streaming service. KDS can continuously capture gigabytes of data per second from hundreds of thousands of sources such as website clickstreams, database event streams, financial transactions, social media feeds, IT logs, and location-tracking events. The data collected is available in milliseconds to enable real-time analytics use cases. Such a KDS based solution would only facilitate updates from the relational system to DynamoDB, so this option is incorrect.

Configure Amazon ElastiCache to use in-memory caching to integrate relational databases with DynamoDB - The in-memory caching provided by Amazon ElastiCache can be used to significantly improve latency and throughput for many read-heavy application workloads or compute-intensive workloads. In-memory caching improves application performance by storing critical pieces of data in memory for low-latency access. ElastiCache cannot integrate relational databases with DynamoDB.

References:

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-hybrid.html#bp-hybrid-problems

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.html

Correct option:

Include the PutObjectAcl permission on all exported objects after the export is complete

When you export your DynamoDB tables from Account A to an S3 bucket in Account B, the objects are still owned by Account A. The AWS Identify Access Management (IAM) users in Account B can't access the objects by default. The export function doesn't write data with the access control list (ACL) bucket-owner-full-control. As a workaround to this object ownership issue, include the PutObjectAcl permission on all exported objects after the export is complete. This workaround grants access to all exported objects for the bucket owners in Account B.

Incorrect options:

Configure the export function to write data with the access control list (ACL) bucket-owner-full-control - This is incorrect. The export function doesn't write data with the access control list (ACL) bucket-owner-full-control.

Use AWS Data Pipeline to export account A DynamoDB table to an S3 bucket in account B - You can also use AWS Data Pipeline to move DynamoDB tables to another AWS account. Data Pipeline is the easiest method to move the tables but provides fewer options for customization. But, this choice is incorrect since the question is about fixing access issues and not about migration.

Use AWS Glue crawler to directly import the data into DynamoDB tables of account B - Cross-account access to the Data Catalog is not supported when using an AWS Glue crawler.

References:

https://aws.amazon.com/premiumsupport/knowledge-center/dynamodb-cross-account-migration/

https://docs.aws.amazon.com/glue/latest/dg/cross-account-access.html

Correct option:

Configure Amazon EFS access points - Amazon EFS access points are application-specific entry points into an EFS file system that makes it easier to manage application access to shared datasets. Access points can enforce a user identity, including the user's POSIX groups, for all file system requests that are made through the access point. Access points can also enforce a different root directory for the file system so that clients can only access data in the specified directory or its subdirectories.

You can use AWS Identity and Access Management (IAM) policies to enforce specific applications to use a specific access point. By combining IAM policies with access points, you can easily provide secure access to specific datasets for your applications.

You can use an access point to enforce user and group information for all file system requests made through the access point. To enable this feature, you need to specify the operating system identity to enforce when you create the access point.

Incorrect options:

Configure Amazon EFS mount targets - Mounting attaches the filesystem of an external device to the filesystem of a system. It instructs the operating system that the filesystem is ready to use and associate it with a particular point in the system's hierarchy. Mounting will make files, directories, and devices available to the users.

With Amazon EFS, you can create a file system, mount the file system on an Amazon EC2 instance, and then read and write data to and from your file system. You can mount an Amazon EFS file system in your VPC, through the Network File System (NFSv4) protocol.

A mount target provides an IP address for an NFSv4 endpoint at which you can mount an Amazon EFS file system. You use the EFS mount helper when mounting a file system using an access point. EFS mount targets cannot be used to manage application access to shared datasets for the given use case.

Use Amazon VPC Gateway endpoints - A VPC endpoint enables private connections between your VPC and supported AWS services and VPC endpoint services powered by AWS PrivateLink. Gateway endpoint is a type of VPC endpoint that supports only two AWS services - Amazon S3 and DynamoDB.

Implement Amazon EBS Multi-Attach - Amazon EBS Multi-Attach enables you to attach a single Provisioned IOPS SSD (io1 or io2) volume to multiple instances that are in the same Availability Zone. You can attach multiple Multi-Attach enabled volumes to an instance or set of instances. EBS, however, is block-level storage and not a file system storage solution.

References:

https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html

https://docs.aws.amazon.com/efs/latest/ug/how-it-works.html

Correct option:

Use AWS KMS with automatic key rotation

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. You have three mutually exclusive options, depending on how you choose to manage the encryption keys: Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3), Server-Side Encryption with Customer Master Keys (CMKs) Stored in AWS Key Management Service (SSE-KMS), Server-Side Encryption with Customer-Provided Keys (SSE-C).

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 don't specify a customer managed CMK, Amazon S3 automatically creates an AWS managed CMK in your AWS account the first time that you add an object encrypted with SSE-KMS to a bucket. By default, Amazon S3 uses this CMK for SSE-KMS.

You can choose to have AWS KMS automatically rotate CMKs every year, provided that those keys were generated within AWS KMS HSMs.

Incorrect options:

Encrypt the data before sending it to Amazon S3 - The act of encrypting data before sending it to Amazon S3 is called Client-Side encryption. You will have to handle the key generation, maintenance, and rotation process. This is not the easiest way to encrypt S3 data at rest. Hence, this is not the right choice here.

Import a custom key into AWS KMS and automate the key rotation on an annual basis by using a Lambda function - When you import a custom key, you are responsible for maintaining a copy of your imported keys in your key management infrastructure so that you can re-import them at any time. Also, automatic key rotation is not supported for imported keys. Using Lambda functions to rotate keys is a possible solution, but not an optimal one for the current use case.

Use SSE-C with automatic key rotation on an annual basis - With Server-Side Encryption with Customer-Provided Keys (SSE-C), you manage the encryption keys and Amazon S3 manages the encryption, as it writes to disks, and decryption when you access your objects. The keys are not stored anywhere in Amazon S3. There is no automatic key rotation facility for this option.

Reference:

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

Correct option:

EBS HDD volume - st1 - Amazon EBS allows you to create storage volumes and attach them to Amazon EC2 instances. Once attached, you can create a file system on top of these volumes, run a database, or use them in any other way you would use block storage.

Amazon EBS provides a range of options that allow you to optimize storage performance and cost for your workload. These options are divided into two major categories: SSD-backed storage for transactional workloads, such as databases and boot volumes (performance depends primarily on IOPS), and HDD-backed storage for throughput intensive workloads, such as MapReduce and log processing (performance depends primarily on MB/s).

ST1 is backed by hard disk drives (HDDs) and is ideal for frequently accessed, throughput intensive workloads with large datasets and large I/O sizes, such as MapReduce, Kafka, log processing, data warehouse, and ETL workloads. These volumes deliver performance in terms of throughput, measured in MB/s, and include the ability to burst up to 250 MB/s per TB, with a baseline throughput of 40 MB/s per TB and a maximum throughput of 500 MB/s per volume.

Incorrect options:

EBS SSD volume - io1 - When attached to EBS-optimized EC2 instances, io1 and io2 volumes are designed to achieve single-digit millisecond latencies, as well as deliver the provisioned performance 99.9% of the time. This is costlier than Throughput Optimized HDD (st1) and hence is not the right choice for the current use-case (there is no need for single-digit millisecond latencies).

EBS SSD volume - gp2 - General-purpose volumes (gp3 and gp2) are backed by solid-state drives (SSDs) and are suitable for a broad range of transactional workloads, virtual desktops, medium-sized single instance databases, latency-sensitive interactive applications, dev/test environments, and boot volumes. gp2 ts priced at $0.08/GB-month, whereas st1 is $0.045/GB-month, making it a better fit for the current use case.

EBS HDD volume - sc1 - SC1 is backed by hard disk drives (HDDs) and provides the lowest cost per GB of all EBS volume types. It is ideal for less frequently accessed workloads with large, cold datasets. sc1 is cheaper than st1, but not ideal for frequently accessed data, which will be the case in the current use case. Hence, sc1 is not an option.

Reference:

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

Correct option:

The object(s) requested were not found on the origin server and the origin server generated the 404 error, which is returned by CloudFront - CloudFront always caches a few of the HTTP 4xx and 5xx status codes returned by your origin. CloudFront doesn't generate 404 responses. If a requested object isn't found in a CloudFront cache, the request is sent to the origin and the origin generates the 404 response if the object is not found on the origin server as well.

Incorrect options:

The object(s) requested were not found by CloudFront and CloudFront generated the 404 error to be returned to the requesting service - 404 error is not generated by CloudFront, it is generated by the origin server when it cannot find the requested object.

404 error is generated by cache miss on CloudFront distribution - If the requested object is not in the cache (a cache miss), then CloudFront sends a request to the origin to get the object. After getting the object, CloudFront returns it to the viewer and stores it in the edge location’s cache. A cache miss does not result in an error.

CloudFront distribution is unable to connect to the origin server to fetch the requested objects - An HTTP 502 status code (Bad Gateway) is generated when CloudFront isn't able to serve the requested object because it is unable to connect to the origin server.

Reference:

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

Correct option:

CloudFront cache behavior needs to be configured to forward all cookies to origin - By default, CloudFront doesn’t consider cookies when processing requests and responses, or when caching your objects in edge locations. If CloudFront receives two requests that are identical except for what’s in the Cookie header, then, by default, CloudFront treats the requests as identical and returns the same object for both requests.

You can configure CloudFront to forward to your origin some or all of the cookies in viewer requests, and to cache separate versions of your objects based on the cookie values that it forwards. When you do this, CloudFront uses some or all of the cookies in viewer requests — whichever ones it’s configured to forward—to uniquely identify an object in the cache.

To configure cookie forwarding, you update your distribution’s cache behavior. You can configure each cache behavior to do one of the following:

1.Forward all cookies to your origin – CloudFront includes all cookies sent by the viewer when it forwards requests to the origin. When your origin returns a response, CloudFront caches the response using the cookie names and values in the viewer request.

2.Forward a whitelist of cookies that you specify – CloudFront removes any cookies that the viewer sends that aren’t on the whitelist before it forwards a request to the origin. CloudFront caches the response using the names and values of the whitelisted cookies in the viewer request.

3.Don’t forward cookies to your origin – CloudFront doesn’t cache your objects based on cookies sent by the viewer. In addition, CloudFront removes cookies before forwarding requests to your origin and removes Set-Cookie headers from responses before returning responses to your viewers.

Incorrect options:

Sticky sessions need to be enabled on CloudFront distribution too for avoiding re-authentication error - This statement is incorrect, given only as a distractor.

Use CloudFront Origin Shield feature to forward authentication information to ALB - CloudFront Origin Shield is an additional layer in the CloudFront caching infrastructure that helps to minimize your origin’s load, improve its availability, and reduce its operating costs. With CloudFront Origin Shield, you get the following benefits: Better cache hit ratio, Reduced origin load, and Better network performance. Using CloudFront Origin Shield will not address the requirement for authentication.

Configure CloudFront to cache resources at edge locations to minimize the necessity for re-authentication - 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. CloudFront uses edge locations inherently. Caching resources at edge locations will not address the requirement for authentication.

Reference:

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

Correct option:

Calculate the sum of 'ClientConnections' metric to know the number of instances connected - To track the number of Amazon EC2 instances that are connected to a file system, you can monitor the Sum statistic of the ClientConnections metric. To calculate the average ClientConnections for periods greater than one minute, divide the sum by the number of minutes in the period.

Incorrect options:

Calculate the average of the 'TotalIOBytes' metric to know the number of active connections - To determine the throughput, you can monitor the daily Sum statistic of the TotalIOBytes metric to see your throughput.

Calculate the mean of the 'BurstCreditBalance' metric to know the number of instances connected - You can see your burst credit balance by monitoring the BurstCreditBalance metric for your file system.

Calculate the sum of 'InstanceConnections' metric to know the number of instances connected - There is no such thing as 'InstanceConnections' metric, this option has been added as a distractor.

Reference:

https://docs.aws.amazon.com/efs/latest/ug/how_to_use_metrics.html