Correct options:

Setup a lifecycle policy to transition the raw zone data into Glacier Deep Archive after 1 day of object creation

You can manage your objects so that they are stored cost-effectively throughout their lifecycle by configuring their Amazon S3 Lifecycle. An S3 Lifecycle configuration is a set of rules that define actions that Amazon S3 applies to a group of objects. For example, you might choose to transition objects to the S3 Standard-IA storage class 30 days after you created them, or archive objects to the S3 Glacier storage class one year after creating them.

For the given use-case, the raw zone consists of the source data, so it cannot be deleted due to compliance reasons. Therefore, you should use a lifecycle policy to transition the raw zone data into Glacier Deep Archive after 1 day of object creation.

Please read more about S3 Object Lifecycle Management: via - https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html

Use Glue ETL job to write the transformed data in the curated zone using a compressed file format

AWS Glue is a fully managed extract, transform, and load (ETL) service that makes it easy for customers to prepare and load their data for analytics.

You cannot transition the curated zone data into Glacier Deep Archive because it is used by the business analysts for ad-hoc querying. Therefore, the best optimization is to have the curated zone data stored in a compressed format via the Glue job. The compressed data would reduce the storage cost incurred on the data in the curated zone.

Please see this example for a Glue ETL Pipeline: https://aws.amazon.com/glue/

Incorrect options:

Create a Lambda function based job to delete the raw zone data after 1 day - As mentioned in the use-case, the source data needs to be kept for a minimum of 5 years for compliance reasons. Therefore the data in the raw zone cannot be deleted after 1 day.

Setup a lifecycle policy to transition the curated zone data into Glacier Deep Archive after 1 day of object creation - You cannot transition the curated zone data into Glacier Deep Archive because it is used by the business analysts for ad-hoc querying. Hence this option is incorrect.

Use Glue ETL job to write the transformed data in the curated zone using CSV format - It is cost-optimal to write the data in the curated zone using a compressed format instead of CSV format. The compressed data would reduce the storage cost incurred on the data in the curated zone. So, this option is incorrect.

References:

https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html

https://aws.amazon.com/glue/

Correct option:

To use private hosted zones, DNS hostnames and DNS resolution should be enabled for the VPC - DNS hostnames and DNS resolution are required settings for private hosted zones. DNS queries for private hosted zones can be resolved by the Amazon-provided VPC DNS server only. As a result, these options must be enabled for your private hosted zone to work.

DNS hostnames: For non-default virtual private clouds that aren't created using the Amazon VPC wizard, this option is disabled by default. If you create a private hosted zone for a domain and create records in the zone without enabling DNS hostnames, private hosted zones aren't enabled. To use a private hosted zone, this option must be enabled.

DNS resolution: Private hosted zones accept DNS queries only from a VPC DNS server. The IP address of the VPC DNS server is the reserved IP address at the base of the VPC IPv4 network range plus two. Enabling DNS resolution allows you to use the VPC DNS server as a Resolver for performing DNS resolution. Keep this option disabled if you're using a custom DNS server in the DHCP Options set, and you're not using a private hosted zone.

Incorrect options:

The private and public hosted zones should not have overlapping namespaces - If you have private and public hosted zones that have overlapping namespaces, such as example.com and accounting.example.com, Resolver routes traffic based on the most specific match. It won't result in an error.

Name server (NS) record and Start Of Authority (SOA) records should have the correct configurations - When you create a hosted zone, Amazon Route 53 automatically creates a name server (NS) record and a start of authority (SOA) record for the zone for public hosted zone. The current requirement is about the private hosted zone, hence this is a wrong choice.

There is a private hosted zone and a Resolver rule that routes traffic to your network for the same domain name resulting in an ambiguous routing rule - If you have a private hosted zone (example.com) and a Resolver rule that routes traffic to your network for the same domain name, the Resolver rule takes precedence. It doesn't result in any error.

References:

https://aws.amazon.com/premiumsupport/knowledge-center/vpc-enable-private-hosted-zone/

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-considerations.html

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-public-considerations.html

Correct option:

Create a Read Replica in the same Region as the Master database and point the analytics workload there

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. Read replicas can be within an Availability Zone, Cross-AZ, or Cross-Region.

Creating a Read Replica within the same Region is the correct answer. As we want to minimize the costs, we need to launch the Read Replica in the same Region, because we have to pay for inter-Region data transfer, whereas the transfer of data within a single Region is free.

Incorrect options:

Enable Multi-AZ for the RDS database and run the analytics workload on the standby database - 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.

Enabling Multi-AZ helps make our database highly-available, but the standby database is not accessible and cannot be used for reads or write. It's just a database that will become primary when the other database encounters a failure. So this option is not correct.

Migrate the analytics application to AWS Lambda - AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume. Running the application on AWS Lambda will not help, as it will still run against the main database and slow down the application.

For Disaster Recovery purposes, create a Read Replica in another Region as the Master database and point the analytics workload there - This option is not correct because we have to pay for inter-Region data transfer for the Read Replica, whereas the transfer of data within a single Region is free. Disaster Recover is not within the scope of the requirements mentioned for the given-use. The correct solution needs to optimize costs.

References:

https://aws.amazon.com/rds/faqs/

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

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

Correct option:

Use AWS DataSync to automate and accelerate online data transfers to the given AWS storage services

AWS DataSync is an online data transfer service that simplifies, automates, and accelerates copying large amounts of data to and from AWS storage services over the internet or AWS Direct Connect.

AWS DataSync fully automates and accelerates moving large active datasets to AWS, up to 10 times faster than command-line tools. It is natively integrated with Amazon S3, Amazon EFS, Amazon FSx for Windows File Server, Amazon CloudWatch, and AWS CloudTrail, which provides seamless and secure access to your storage services, as well as detailed monitoring of the transfer.

DataSync uses a purpose-built network protocol and scale-out architecture to transfer data. A single DataSync agent is capable of saturating a 10 Gbps network link. DataSync fully automates the data transfer. It comes with retry and network resiliency mechanisms, network optimizations, built-in task scheduling, monitoring via the DataSync API and Console, and CloudWatch metrics, events, and logs that provide granular visibility into the transfer process. DataSync performs data integrity verification both during the transfer and at the end of the transfer.

How DataSync Works : https://aws.amazon.com/datasync/

Incorrect options:

Use AWS Snowball Edge Storage Optimized device to automate and accelerate online data transfers to the given AWS storage services - Snowball Edge Storage Optimized is the optimal choice if you need to securely and quickly transfer dozens of terabytes to petabytes of data to AWS. It provides up to 80 TB of usable HDD storage, 40 vCPUs, 1 TB of SATA SSD storage, and up to 40 Gb network connectivity to address large scale data transfer and pre-processing use cases. As each Snowball Edge Storage Optimized device can handle 80TB of data, you can order 10 such devices to take care of the data transfer for all applications. The original Snowball devices were transitioned out of service and Snowball Edge Storage Optimized are now the primary devices used for data transfer. You may see the Snowball device on the exam, just remember that the original Snowball device had 80TB of storage space.

AWS Snowball Edge is suitable for offline data transfers, for customers who are bandwidth constrained or transferring data from remote, disconnected, or austere environments. Therefore, it cannot support automated and accelerated online data transfers.

Use AWS Transfer Family to automate and accelerate online data transfers to the given AWS storage services - The AWS Transfer Family provides fully managed support for file transfers directly into and out of Amazon S3. Therefore, it cannot support migration into the other AWS storage services mentioned in the given use-case (such as EFS and Amazon FSx for Windows File Server).

Use File Gateway to automate and accelerate online data transfers to the given AWS storage services - AWS Storage Gateway's file interface, or file gateway, offers you a seamless way to connect to the cloud to store application data files and backup images as durable objects on Amazon S3 cloud storage. File gateway offers SMB or NFS-based access to data in Amazon S3 with local caching. It can be used for on-premises applications, and for Amazon EC2-based applications that need file protocol access to S3 object storage. Therefore, it cannot support migration into the other AWS storage services mentioned in the given use-case (such as EFS and Amazon FSx for Windows File Server).

References:

https://aws.amazon.com/datasync/faqs/

https://aws.amazon.com/storagegateway/file/

https://aws.amazon.com/aws-transfer-family/

Correct option:

Use VPC sharing to share one or more subnets with other AWS accounts belonging to the same parent organization from AWS Organizations

VPC sharing (part of Resource Access Manager) allows multiple AWS accounts to create their application resources such as EC2 instances, RDS databases, Redshift clusters, and Lambda functions, into shared and centrally-managed Amazon Virtual Private Clouds (VPCs).

To set this up, the account that owns the VPC (owner) shares one or more subnets with other accounts (participants) that belong to the same organization from AWS Organizations. After a subnet is shared, the participants can view, create, modify, and delete their application resources in the subnets shared with them. Participants cannot view, modify, or delete resources that belong to other participants or the VPC owner.

You can share Amazon VPCs to leverage the implicit routing within a VPC for applications that require a high degree of interconnectivity and are within the same trust boundaries. This reduces the number of VPCs that you create and manage while using separate accounts for billing and access control.

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html

Incorrect options:

Use VPC sharing to share a VPC with other AWS accounts belonging to the same parent organization from AWS Organizations - Using VPC sharing, an account that owns the VPC (owner) shares one or more subnets with other accounts (participants) that belong to the same organization from AWS Organizations. The owner account cannot share the VPC itself. Therefore this option is incorrect.

Use VPC peering to share one or more subnets with other AWS accounts belonging to the same parent organization from AWS Organizations - A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. Instances in either VPC can communicate with each other as if they are within the same network. VPC peering does not facilitate centrally managed VPCs. Therefore this option is incorrect.

https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html

Use VPC peering to share a VPC with other AWS accounts belonging to the same parent organization from AWS Organizations - A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. Instances in either VPC can communicate with each other as if they are within the same network. VPC peering does not facilitate centrally managed VPCs. Moreover, an AWS owner account cannot share the VPC itself with another AWS account. Therefore this option is incorrect.

References:

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html

https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html

Correct options:

In the other AWS accounts, configure an IAM role that has minimal permissions. Add the Lambda execution role of the centralized account as a trusted entity

In the centralized account, configure an IAM role that has the Lambda service as a trusted entity. Add an inline policy to assume the roles of the other AWS accounts

Here are some basics on IAM roles. An IAM role has three places where it uses policies:

Permission policies (inline and attached) – These policies define the permissions that a principal assuming the role is able (or restricted) to perform, and on which resources.

Permissions boundary – A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity’s permissions boundary allows it to perform only the actions that are allowed by both its identity-based permission policies and its permissions boundaries.

Trust relationship – This policy defines which principals can assume the role, and under which conditions. This is sometimes referred to as a resource-based policy for the IAM role. This policy is simply referred to as the ‘trust policy’.

How to delegate access across AWS accounts using IAM roles: https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

For the given use case, you can configure the Lambda functions in the centralized account to have their execution role allow the function to assume an IAM role in the other AWS accounts via an inline policy. Then you need to modify your cross-account IAM role's trust policy to allow your Lambda function's execution role to assume the role. A Lambda function can assume an IAM role in another AWS account to do either of the following: Access resources — such as accessing an Amazon Simple Storage Service (Amazon S3) bucket. Do tasks — such as starting and stopping EC2 instances.

Incorrect options:

In the centralized account, configure an IAM role that has roles of the other accounts as trusted entities. Provide least possible privileges to this role

In the other AWS accounts, configure an IAM role that has permissions to assume the role of the centralized account. Add the Lambda service as a trusted entity

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

In the other AWS accounts, configure a service-linked role for the Lambda function of the centralized account. Provide least possible privileges to this role - AWS Lambda doesn't have service-linked roles, so this option has been added as a distractor.

References:

https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/

Correct option:

Enable default encryption on the Amazon S3 bucket that uses Amazon S3-managed keys (SSE-S3) encryption (AES-256) for audit logging. Use Amazon Redshift Spectrum to query the data for monthly audits

Audit logging is not turned on by default in Amazon Redshift. When you turn on logging on your cluster, Amazon Redshift creates and uploads logs to Amazon S3 that capture data from the time audit logging is enabled to the present time. Each logging update is a continuation of the information that was already logged.

Audit logging to Amazon S3 is an optional, manual process. When you enable logging on your cluster, you are enabling logging to Amazon S3 only. Currently, you can only use Amazon S3-managed keys (SSE-S3) encryption (AES-256) for audit logging.

Amazon Redshift Spectrum is a feature of Amazon Redshift that lets you run queries against your data lake in Amazon S3, with no data loading or ETL required. When you issue an SQL query, it goes to the Amazon Redshift endpoint, which generates and optimizes a query plan. Amazon Redshift determines what data is local and what is in Amazon S3, generates a plan to minimize the amount of S3 data that needs to be read, and requests Amazon Redshift Spectrum workers out of a shared resource pool to read and process data from S3.

https://aws.amazon.com/blogs/big-data/amazon-redshift-spectrum-extends-data-warehousing-out-to-exabytes-no-loading-required/

Incorrect options:

Enable default encryption on the Amazon S3 bucket that uses Amazon S3-managed keys (SSE-S3) encryption (AES-256) for audit logging. Copy the data into the Amazon Redshift cluster from Amazon S3 when data needs to be queried for monthly audits - Copying data into the Redshift cluster for enabling monthly audits would turn out to be a costly solution. Using Redshift Spectrum is the right fit for the given scenario.

Enable encryption on the Amazon S3 bucket that uses Amazon Server-Side Encryption with KMS keys Stored in AWS Key Management Service (SSE-KMS) for audit logging. Use Amazon QuickSight to query the data for monthly audits

Enable encryption on the Amazon S3 bucket that uses Amazon Server-Side Encryption with KMS keys Stored in AWS Key Management Service (SSE-KMS) for audit logging. Use Amazon Redshift Spectrum to query the data for monthly audits

Currently, you can only use Amazon S3-managed keys (SSE-S3) encryption (AES-256) for audit logging. Hence, both these options are incorrect.

References:

https://aws.amazon.com/blogs/big-data/amazon-redshift-spectrum-extends-data-warehousing-out-to-exabytes-no-loading-required/

https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing.html

https://docs.aws.amazon.com/redshift/latest/dg/c-using-spectrum.html

Correct option:

Storage Gateway doesn't automatically update the cache when you upload a file directly to Amazon S3. Perform a RefreshCache operation to see the changes on the file share

Storage Gateway updates the file share cache automatically when you write files to the cache locally using the file share. However, Storage Gateway doesn't automatically update the cache when you upload a file directly to Amazon S3. When you do this, you must perform a RefreshCache operation to see the changes on the file share. If you have more than one file share, then you must run the RefreshCache operation on each file share.

You can refresh the cache using the Storage Gateway console and the AWS Command Line Interface (AWS CLI).

Incorrect options:

Uploading files from your file gateway to Amazon S3 when S3 Versioning is enabled results in cache update issues. Disable versioning on the S3 bucket - Carefully consider the use of S3 Versioning and Cross-Region Replication (CRR) in Amazon S3 when you're uploading data from your file gateway. Uploading files from your file gateway to Amazon S3 when S3 Versioning is enabled results in at least two versions of an S3 object. This option is not relevant to the given issue and has just been added as a distractor.

Storage Gateway doesn't automatically update the cache when you upload a file directly to Amazon S3. Perform a ResetCache operation to see the changes on the file share - 'ResetCache', resets all cache disks that have encountered an error, and make the disks available for reconfiguration as cache storage. When a cache is reset, the gateway loses its cache storage. At this point, you can reconfigure the disks as cache disks. This operation is only supported in the cached volume and tape gateway types.

Configure correct permissions in Amazon S3 bucket policy to allow automatic refresh of cache - This statement is incorrect and has just been added as a distractor.

References:

https://docs.aws.amazon.com/filegateway/latest/files3/GettingStartedCreateFileShare.html

https://aws.amazon.com/premiumsupport/knowledge-center/storage-gateway-s3-changes-not-showing/

https://docs.aws.amazon.com/filegateway/latest/files3/refresh-cache.html

https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_RefreshCache.html

Correct option:

Configure CloudFront to use a custom header and configure an AWS WAF rule on the origin’s Application Load Balancer to accept only traffic that contains that header - You can configure CloudFront to add custom headers to the requests that it sends to your origin. These custom headers enable you to send and gather information from your origin that you don’t get with typical viewer requests. These headers can even be customized for each origin. CloudFront supports custom headers for both custom and Amazon S3 origins.

You can use custom headers for a variety of things, such as the following: 1. Determining which requests come from a particular distribution - If you configure more than one CloudFront distribution to use the same origin, you can add different custom headers in each distribution. You can then use the logs from your origin to determine which requests came from which CloudFront distribution. 2. Enabling cross-origin resource sharing (CORS) 3. Controlling access to content

Incorrect options:

Configure Origin Access Identity(OAI) on the origin server, which will only allow requests originating from CloudFront - Using Origin Access Identity (OAI), access can be restricted to an Amazon S3 bucket, making it only accessible from CloudFront. OAI cannot be used for custom origins.

Configure an AWS Lambda@Edge function to validate that the traffic to the Application Load Balancer originates from CloudFront - Since AWS Lambda@Edge resides on the AWS backbone, it will not be able to validate traffic for the downstream application server such as for an EC2 instance or an Application Load Balancer.

Configure private access to content by using special CloudFront signed URLs or signed cookies - You can configure CloudFront to require that users access your files using either signed URLs or signed cookies. You then develop your application either to create and distribute signed URLs to authenticated users or to send Set-Cookie headers that set signed cookies for authenticated users. You cannot use signed URLs or signed cookies for the given use case.

Reference:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html

Correct option:

Change the application architecture to create customer-specific custom prefixes within the single bucket and then upload the daily files into those prefixed locations

Amazon Simple Storage Service (Amazon S3) is an object storage service that offers industry-leading scalability, data availability, security, and performance. Your applications can easily achieve thousands of transactions per second in request performance when uploading and retrieving storage from Amazon S3. Amazon S3 automatically scales to high request rates. For example, your application can achieve at least 3,500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requests per second per prefix in a bucket.

There are no limits to the number of prefixes in a bucket. You can increase your read or write performance by parallelizing reads. For example, if you create 10 prefixes in an Amazon S3 bucket to parallelize reads, you could scale your read performance to 55,000 read requests per second. Please see this example for more clarity on prefixes: if you have a file f1 stored in an S3 object path like so s3://your_bucket_name/folder1/sub_folder_1/f1, then /folder1/sub_folder_1/ becomes the prefix for file f1.

Some data lake applications on Amazon S3 scan millions or billions of objects for queries that run over petabytes of data. These data lake applications achieve single-instance transfer rates that maximize the network interface used for their Amazon EC2 instance, which can be up to 100 Gb/s on a single instance. These applications then aggregate throughput across multiple instances to get multiple terabits per second. Therefore creating customer-specific custom prefixes within the single bucket and then uploading the daily files into those prefixed locations is the BEST solution for the given constraints.

Optimizing Amazon S3 Performance: https://docs.aws.amazon.com/AmazonS3/latest/dev/optimizing-performance.html

Incorrect options:

Change the application architecture to create a new S3 bucket for each customer and then upload each customer's files directly under the respective buckets - Creating a new S3 bucket for each new customer is an inefficient way of handling resource availability (S3 buckets need to be globally unique) as some customers may use the service sparingly but the bucket name is locked for them forever. Moreover, this is not required as we can use S3 prefixes to improve the performance.

Change the application architecture to create a new S3 bucket for each day's data and then upload the daily files directly under that day's bucket - Creating a new S3 bucket for each new day's data is also an inefficient way of handling resource availability (S3 buckets need to be globally unique) as some of the bucket names may not be available for daily data processing. Moreover, this is not required as we can use S3 prefixes to improve the performance.

Change the application architecture to use S3 Glacier Deep Archive storage class - Glacier Deep Archive is designed to provide durable and secure long-term storage for large amounts of data at a price that is competitive with off-premises tape archival services. Data is stored across 3 or more AWS Availability Zones and can be retrieved in 12 hours or less. This option is a distractor because Glacier Deep Archive would not allow customers to retrieve the objects immediately.

Reference:

https://docs.aws.amazon.com/AmazonS3/latest/dev/optimizing-performance.html