Correct Answer: A. The correct solution for this scenario, which requires restricting access to an S3 bucket containing project reports to only users from accounts within the same AWS Organization, is to add the "aws:PrincipalOrgID" global condition key to the S3 bucket policy with a reference to the organization ID. This approach will allow only users from accounts within the same organization to access the bucket and requires the least amount of operational overhead. Option B, which suggests using the "aws:PrincipalOrgPaths" global condition key, will not limit access to the bucket. Option C, which involves using AWS CloudTrail to monitor organization events and updating the S3 bucket policy, will impose a significant operational overhead. Option D, which suggests tagging each user who needs access to the S3 bucket and adding the "aws:PrincipalTag" global condition key, will be difficult to maintain and may result in errors.

The correct answer is C. Option C is the best choice because it uses Amazon Textract to extract the text from the reports, which reduces operational overhead, and Amazon Comprehend Medical to identify the PHI from the extracted text. Amazon Comprehend Medical is a natural language processing service specifically designed to identify medical information, including PHI, which makes it the best choice for this use case.

Option A is not the best choice because it requires the company to write custom code to extract text from the reports and identify PHI, which would require significant operational overhead.

Option B is not the best choice because it requires the company to use Amazon SageMaker, which is a machine learning service that requires significant operational overhead to train and deploy models. Additionally, Amazon Textract may not be accurate enough to extract all the necessary text from the reports.

Option D is not the best choice because Amazon Rekognition is primarily used for image and video analysis and may not be accurate enough to extract all the necessary text from the reports.

Correct Answer: D. Option D is the best choice because it meets all the requirements mentioned in the question. The company needs to have access to AWS and on-premises resources. AWS Direct Connect is a service that enables organizations to establish dedicated network connections between their on-premises infrastructure and AWS. This means that the company can use AWS Direct Connect to establish a dedicated network connection between their on-premises infrastructure and AWS, which will provide them with a more reliable and consistent network experience.

AWS Direct Connect provides dedicated network connections that are private, fast, and more secure than typical internet connections. It helps to reduce network costs, increase bandwidth throughput, and provide a more consistent network experience. With AWS Direct Connect, the company can access all AWS services that are available in the region where the connection is established. AWS Direct Connect also supports multiple virtual interfaces, which means that the company can use the same connection to access multiple VPCs or AWS accounts.

In summary, AWS Direct Connect is the best choice because it meets all the requirements mentioned in the question and provides the company with a reliable and consistent network experience.

Option A, deploying and configuring Amazon FSx for Windows File Server on AWS is correct because it provides a fully managed Windows file system that is accessible from on-premises and AWS. The company can move the on-premises file data to FSx for Windows File Server, and reconfigure the workloads to use FSx for Windows File Server on AWS. This solution meets the requirements of having minimum latency and minimal operational overhead and requires no significant changes to the existing file access patterns.

Option B, deploying and configuring an Amazon S3 File Gateway on premises, and moving the on-premises file data to the S3 File Gateway is incorrect because S3 is an object storage service, not a file storage service. This solution requires reconfiguring the on-premises workloads and the cloud workloads to use the S3 File Gateway, which does not meet the requirement of having no significant changes to the existing file access patterns.

Option C, deploying and configuring an Amazon S3 File Gateway on premises, moving the on-premises file data to Amazon S3, and reconfiguring the workloads to use either Amazon S3 directly or the S3 File Gateway, depending on each workload's location is incorrect because it requires more operational overhead and does not meet the requirement of having minimum operational overhead.

Correct Answer: A. Save the .pdf files to Amazon S3. Configure an S3 PUT event to invoke an AWS Lambda function to convert the files to .jpg format and store them back in Amazon S3.

This solution is the most cost-effective because it uses Amazon S3 for storing both original and converted files. It also leverages AWS Lambda to convert the files, which is a serverless solution and eliminates the need to provision or manage any servers.

Option B is incorrect because DynamoDB is not designed for storing large files, and it can become expensive very quickly.

Option C is incorrect because it requires managing EC2 instances and EBS volumes, which can become expensive and complex to manage at scale.

Option D is also incorrect because it uses Amazon EFS, which can be expensive and does not provide the same level of durability as Amazon S3.

Correct Answer: D. Solution D is the best solution because it allows the company to use an external CA for their SSL/TLS certificate and still have ACM automatically rotate the certificate.

Import the SSL/TLS certificate from the external CA into ACM. Apply the certificate to the ALB. Create an Amazon EventBridge rule that triggers when the certificate is nearing expiration. The Amazon EventBridge rule sends a notification to the company. The company manually rotates the certificate.

This solution allows the company to use the certificate that they want and still have the peace of mind that the certificate will be rotated automatically.
Solution A is incorrect because ACM does not support importing certificates from external CAs.

Solution B is incorrect because it is not necessary to import the key material from the certificate. ACM can automatically rotate the certificate without the need to import the key material.

Solution C is incorrect because ACM Private Certificate Authority is not designed for public web applications. It is designed for internal applications that do not need to be accessible from the public internet.

Correct Answer: C. Store the database credentials as a secret in AWS Secrets Manager. Turn on automatic rotation for the secret. Attach the required permission to the EC2 role to grant access to the secret.

AWS Secrets Manager is a service that allows you to store and rotate secrets such as database credentials, API keys, and other sensitive data. It allows you to securely and easily manage secrets throughout their lifecycle. By using Secrets Manager to store and rotate the database credentials, you can ensure that the credentials are not hardcoded in the application and also that they are regularly rotated. The EC2 instance can be granted permission to access the secret through its role, which reduces operational overhead.

Option A is incorrect because storing the database credentials in the instance metadata is not a secure solution. Instance metadata can be accessed by anyone who has access to the instance, which makes it less secure.

Option B is incorrect because storing the database credentials in an S3 bucket is not a secure solution. Although the S3 bucket can be encrypted and versioned, there is still a risk that the credentials could be exposed.

Option D is incorrect because, although AWS Systems Manager Parameter Store can be used to store and rotate parameters, it is not specifically designed for storing secrets. AWS Secrets Manager is the recommended service for storing secrets such as database credentials.

Correct Answer: C. Create a listener rule on the ALB to redirect HTTP traffic to HTTPS.

To redirect all HTTP traffic to HTTPS, a listener rule should be created on the ALB. This rule should redirect all incoming traffic on port 80 (HTTP) to port 443 (HTTPS). This can be done using the "Redirect" action in the listener rule.

Option A. Updating the ALB's network ACL to accept only HTTPS traffic would block all incoming traffic on port 80 (HTTP) and is not a valid solution.

Option B. Creating a rule that replaces the HTTP in the URL with HTTPS would not redirect all HTTP traffic to HTTPS, and is not a valid solution.

Option D. Replacing the ALB with a Network Load Balancer configured to use Server Name Indication (SNI) would not automatically redirect HTTP traffic to HTTPS, and is not a valid solution.

Correct Answer: D. Option D is the correct solution. Amazon Kinesis Data Streams can handle high-volume data ingestion, while Amazon Kinesis Data Firehose can automatically load the data into an S3 data lake. Amazon Redshift can then be used for data analysis. This solution is also cost-effective and can be scaled easily.

Option A is incorrect as it is a complex and outdated solution. AWS Data Pipeline is used for data processing, but it is an outdated service and is not recommended for new workloads. EMR is also an outdated tool for data analysis.

Option B is incorrect as it is not a serverless solution. Creating an Auto Scaling group of EC2 instances is not a cost-effective solution for this use case.

Option C is incorrect as it is not designed for high-volume data processing. AWS Lambda has a maximum execution time of 15 minutes, which may not be adequate for processing large amounts of data.

The correct answer is: C. Extend the file share environment to Amazon FSx for Windows File Server with a Multi-AZ configuration. Migrate all the data to FSx for Windows File Server.

This option is correct because:

• Amazon FSx for Windows File Server provides a fully managed Windows-native file system that supports SMB protocol, Active Directory integration, and Windows ACLs, allowing users to access files in the same way they currently do.

• Multi-AZ deployment ensures high availability and durability by replicating data automatically across two Availability Zones.

• Migrating data to FSx eliminates the need to manage synchronization between EC2 instances manually, reducing operational overhead while preserving the existing file access experience.

More details:

• FSx for Windows File Server overview: https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html

• Multi-AZ deployments: https://docs.aws.amazon.com/fsx/latest/WindowsGuide/high-availability.html

Option A: Incorrect — Storing data in S3 would require reconfiguring file access for users, breaking the existing SMB-based workflow.
Option B: Incorrect — S3 File Gateway provides file access via NFS or SMB, but mounting it on EC2 does not replace a fully managed Windows file share and would still require custom synchronization.
Option D: Incorrect — Amazon EFS supports NFS, not SMB, so it is not fully compatible with native Windows file shares and would change how users access files.

Summary: Option C provides a highly available, durable, and fully managed Windows file share environment with minimal changes to user experience.

The correct answer is: A. Create an Amazon Kinesis Data Firehose delivery stream to ingest the alerts. Configure the Kinesis Data Firehose stream to deliver the alerts to an Amazon S3 bucket. Set up an S3 Lifecycle configuration to transition data to Amazon S3 Glacier after 14 days.

Explanation:

This option is the most operationally efficient because:

• Kinesis Data Firehose is fully managed and can ingest large volumes of streaming data (1 TB/day) from thousands of devices without managing servers.

• S3 provides highly available and durable storage for immediate access to the last 14 days of alerts.

• S3 Lifecycle policies automate the archival of older data to Amazon S3 Glacier, reducing storage costs without manual intervention.

• No additional infrastructure (EC2 instances, OpenSearch clusters, or custom consumers) is needed, minimizing operational overhead.

More details:

• Kinesis Data Firehose: https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html

• S3 Lifecycle Policies: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html

Option B: Incorrect because using EC2 instances adds operational overhead for scaling, availability, and management.

Option C: Incorrect because OpenSearch is costly for storing 1 TB/day, and manually managing snapshots and deletions increases operational complexity.

Option D: Incorrect because SQS has a maximum retention period of 14 days, and using consumers to check message age and move to S3 adds unnecessary operational complexity.

Summary: Option A provides a fully managed, scalable, cost-efficient, and highly available solution for ingesting, storing, and archiving large volumes of alerts.

The correct answer is: A. Change the storage type to Provisioned IOPS SSD.

This option is correct because Provisioned IOPS (io1 or io2) SSD storage allows you to specify a consistent number of IOPS, ensuring predictable and high-performance storage for write-intensive workloads like millions of inserts per day. Since the problem is identified as storage performance, moving from General Purpose SSD (gp2/gp3) to Provisioned IOPS directly addresses the bottleneck.

More details: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html#CHAP_Storage.IOPS

Option B: Incorrect because changing to a memory-optimized instance improves CPU and RAM resources, but does not directly solve a storage I/O bottleneck.

Option C: Incorrect because burstable performance instances (T-series) are suitable for workloads with variable CPU usage, not for high-throughput, storage-intensive workloads.

Option D: Incorrect because Multi-AZ read replicas primarily provide high availability and failover capabilities. They do not improve write performance on the primary instance.

Summary: Option A addresses the root cause by providing high and consistent IOPS for storage-intensive operations, reducing the latency of inserts.

The correct answer is: B. Attach the appropriate IAM role to each existing instance and new instance. Use AWS Systems Manager Session Manager to establish a remote SSH session.

This option is correct because AWS Systems Manager Session Manager provides secure, auditable, and remote shell access to EC2 instances without the need to open inbound ports, manage SSH keys, or maintain a bastion host, minimizing operational overhead. It integrates with IAM for fine-grained access control and follows the AWS Well-Architected Framework security best practices.

More details: https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html

Option A: Incorrect because the EC2 serial console is primarily for emergency troubleshooting and does not scale well for routine administrative access.

Option C: Incorrect because deploying a bastion host and managing SSH keys increases operational overhead and exposes the network to more attack vectors.

Option D: Incorrect because using a Site-to-Site VPN and SSH keys requires managing network infrastructure and key distribution, which increases operational complexity.

Summary: Option B provides the most secure, scalable, and low-maintenance approach for remote administration of EC2 instances.

The correct answer is: B. Create a customer-managed multi-region KMS key. Create an S3 bucket in each region, and configure replication between the S3 buckets. Set up the application to use the KMS key with client-side encryption.

This option is correct because:

• Multi-Region KMS keys allow the same key ID to be used in multiple AWS Regions, enabling encryption and decryption of data across regions without creating separate keys.

• Using client-side encryption ensures that data is encrypted before it is stored in S3, and the same key can be used seamlessly in both buckets.

• Replication between the buckets keeps the data synchronized across regions while maintaining encryption with the same key.

• This approach minimizes maintenance because you do not need to manage separate keys in each region or rotate multiple keys.

More details: https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html

Option A: Incorrect because SSE-S3 uses AWS-managed keys and does not allow a customer-managed KMS key to be used in multiple regions.

Option C: Incorrect because SSE-S3 does not support customer-managed KMS keys; also, creating separate KMS keys in each region increases administrative overhead.

Option D: Incorrect because using separate SSE-KMS keys in each region would require managing multiple keys and does not fulfill the requirement of using the same key across regions.

Summary: Option B meets the requirement for using the same customer-managed KMS key in multiple regions with minimal administration while ensuring encrypted replication between S3 buckets.

The correct answer is: B. Use AWS Config to track configuration changes and AWS CloudTrail to record API calls.

This option is correct because:

• AWS Config continuously monitors and records your AWS resource configurations, allowing you to track changes over time, evaluate resource compliance, and maintain a historical view of configuration changes.

• AWS CloudTrail records all API calls made in your AWS account, including calls from the AWS Management Console, SDKs, command-line tools, and other AWS services. This is essential for auditing, governance, and security analysis.

More details:

• AWS Config: https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html

• AWS CloudTrail: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html

Option A: Incorrect because CloudTrail records API calls, not resource configuration changes.

Option C: Incorrect because CloudWatch is primarily for monitoring metrics and logs, not recording API calls.

Option D: Incorrect because CloudTrail does not track resource configuration changes, only API activity, and CloudWatch does not provide a complete API history.

Summary: Option B provides the correct combination of services for tracking configuration changes and recording API calls for compliance, governance, and auditing purposes.

The correct answer is: A. Use AWS Config rules to define and detect resources that are not properly tagged.

This option is correct because AWS Config provides managed rules that can automatically check whether resources such as EC2 instances, RDS DB instances, and Redshift clusters are tagged according to your company’s policies. Config continuously monitors resources and reports noncompliant resources, reducing manual effort and operational overhead.
More details: https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html

Option B: Incorrect because Cost Explorer can report costs by tag but cannot enforce or automatically detect untagged resources. Manual tagging would require additional effort and is prone to errors.

Option C: Incorrect because writing custom API calls and running them manually is highly operationally intensive and does not provide continuous compliance monitoring.

Option D: Incorrect because while a Lambda-based solution can automate checks, it still requires custom code, scheduling, and maintenance, which increases operational overhead compared to managed AWS Config rules.

Summary: Option A is the correct solution because AWS Config provides automated, continuous, and low-overhead enforcement of tagging policies across multiple AWS resources.

The correct answer is: B. Create an IAM user specifically for the product manager. Attach the CloudWatchReadOnlyAccess AWS managed policy to the user. Share the new login credentials with the product manager. Share the browser URL of the correct dashboard with the product manager.

This option is correct because it provides the product manager with a dedicated IAM user account and applies the principle of least privilege by granting only read-only access to CloudWatch. This ensures they can securely view the required dashboard while preventing unauthorized access to other AWS resources. It also avoids operational complexity and keeps access auditable.
More details: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/auth-and-access-control-cw.html

Option A: Incorrect because sharing dashboards publicly or by link can expose sensitive application metrics. This does not meet the principle of least privilege.

Option C: Incorrect because creating a general employee IAM user and sharing it with the product manager violates security best practices. Shared credentials reduce accountability and break least privilege.

Option D: Incorrect because deploying a bastion server is overly complex and introduces unnecessary operational overhead and security risks. It is not suitable for simple dashboard viewing.

Summary: Option B is the correct solution because it offers secure, least-privilege, read-only access to CloudWatch dashboards with minimal effort and proper user accountability.

The correct answer is: A. Turn on AWS Config with the appropriate rules.

This option is correct because AWS Config continuously monitors and records S3 bucket configurations and changes, and it can evaluate them against predefined or custom rules (e.g., ensuring buckets are not public, enforcing encryption). If unauthorized configuration changes occur, AWS Config can trigger alerts or remediation.
More details: https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html and https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-policy-not-public.html

Option B: Incorrect — AWS Trusted Advisor provides periodic best-practice checks, but it is not real-time monitoring and cannot enforce compliance at the configuration level.

Option C: Incorrect — Amazon Inspector is used for automated security assessments of EC2 instances, containers, and Lambda (vulnerabilities/exposures), not for monitoring S3 bucket configuration changes.

Option D: Incorrect — S3 server access logging + EventBridge helps capture request activity (who accessed what), but it does not provide automated evaluation of configuration compliance or prevent unauthorized configuration changes.

Summary: AWS Config with S3-related rules is the right solution for ensuring no unauthorized changes happen to bucket configurations.

The correct answer is: D. Configure two Lambda functions — one to receive the data and the other to load it into the database. Connect the Lambda functions using an Amazon Simple Queue Service (Amazon SQS) queue.

This option is correct because using SQS as a buffer between the ingestion Lambda and the loader Lambda decouples producers from consumers, smooths traffic spikes, and prevents direct throttling of the database. SQS provides durable message buffering and backpressure; the loader Lambda can scale at a controlled rate (via Lambda’s SQS event-source mapping) to match the database’s capacity, avoiding the need to dramatically raise Lambda quotas. This approach minimizes configuration effort while providing reliable, scalable ingestion.
More details: https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html and https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html

Option A: Incorrect — Rewriting the function as an Apache Tomcat app on EC2 increases operational overhead (managing servers, scaling, OS patching) and loses the benefits of serverless scaling.

Option B: Incorrect — Switching to DynamoDB + DAX is a major architectural change (and DAX is a caching layer for DynamoDB reads). It may be unnecessary for the POC and does not address the immediate need to decouple and buffer incoming requests to protect the database.

Option C: Incorrect — Using SNS between the Lambdas is not ideal for this point-to-point buffering use case. SNS is a pub/sub fan-out service (push-based) without durable per-consumer buffering semantics; it does not provide the same reliable buffering and controlled consumption that SQS provides for smoothing spikes.

Summary: D is the best choice because SQS + Lambda decoupling provides durable buffering, controlled consumption, and easy scaling with minimal config changes, protecting the Aurora database while handling high ingestion volumes.

The correct answer is: B. Use Cost Explorer's granular filtering feature to perform an in-depth analysis of EC2 costs based on instance types.

This option is correct because AWS Cost Explorer provides built-in tools to visualize and analyze costs at a granular level, including by service, linked account, usage type, and EC2 instance type. It requires minimal operational overhead, since the feature is available directly in the AWS Management Console without needing extra setup. The billing team can easily compare costs over time (last 2 months) and identify which EC2 instance types caused the vertical scaling costs.

More details: https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html

• Option A: Incorrect — AWS Budgets helps set alerts and enforce cost thresholds but does not provide granular visual analysis across instance types. It’s proactive but not an analytical tool.

• Option C: Incorrect — The Billing and Cost Management dashboard provides a high-level view of total costs but lacks the granular breakdown needed by EC2 instance types.

• Option D: Incorrect — Cost and Usage Reports with QuickSight is powerful but adds significant operational overhead (setting up CUR, S3 bucket, and QuickSight dashboards). This is overkill for the stated requirement.

Summary: Option B is the best because Cost Explorer’s filtering features give an immediate, low-overhead way to compare EC2 costs by instance type across months and pinpoint the cause of scaling-related increases.

The correct answer is: B. Create an S3 Lifecycle configuration to transition objects from S3 Standard to S3 Glacier Deep Archive after 1 month.

This option is correct because S3 Glacier Deep Archive is the lowest-cost storage class in Amazon S3, designed for long-term data retention where retrieval is very rare. Since the backup files are accessed frequently during the first month, it makes sense to keep them in S3 Standard initially. After that, when access needs drop significantly, transitioning them to Glacier Deep Archive minimizes storage costs while still keeping the data for compliance or disaster recovery.

More details: https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html

• Option A: Incorrect — S3 Intelligent-Tiering automatically optimizes cost for unknown or unpredictable access patterns. Here, the access pattern is predictable (frequent for one month, then rarely accessed), so Intelligent-Tiering adds unnecessary monitoring cost.

• Option C: Incorrect — S3 Standard-IA reduces cost for infrequent access, but Glacier Deep Archive is much cheaper for data kept indefinitely with very rare retrieval.

• Option D: Incorrect — S3 One Zone-IA is less resilient (stored in a single AZ only) and not recommended for critical, long-term backup data.

Summary: Option B is best because it leverages predictable access patterns to keep data cost-effective and durable for the long term.

The correct answer is: B. S3 Intelligent-Tiering

This option is correct because Amazon S3 Intelligent-Tiering automatically moves objects between frequent and infrequent access tiers based on access patterns. It is designed for data with unpredictable or changing access, minimizing storage costs without performance impact or operational overhead. It also provides resiliency across multiple Availability Zones, meeting the requirement for durability and availability.

More details: https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html

Option A: Incorrect — S3 Standard provides high durability and availability but does not optimize costs for rarely accessed data.

Option C: Incorrect — S3 Standard-IA is cheaper for infrequent access but incurs higher retrieval costs and is not cost-efficient if access patterns are unpredictable.

Option D: Incorrect — S3 One Zone-IA stores data in a single Availability Zone, which does not meet the resiliency requirement if an AZ is lost.

Summary: Option B is the best choice because S3 Intelligent-Tiering balances cost savings, resiliency, and unpredictable access needs with minimal management overhead.

The correct answer is: D. Use an Amazon S3 bucket to host the website's static resources. Deploy an Amazon CloudFront distribution and set the S3 bucket as the origin. Utilize Amazon API Gateway and AWS Lambda functions for the backend APIs. Save the data to Amazon DynamoDB.

This option is correct because a fully serverless + CDN architecture (S3 + CloudFront + API Gateway + Lambda + DynamoDB) provides the least operational overhead while scaling automatically to handle millions of requests per hour with low (millisecond) latency.

• S3 + CloudFront serves static content from edge locations for global, ultra-low-latency delivery. More details: https://aws.amazon.com/cloudfront/ and https://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html

• API Gateway + Lambda provides a fully managed, auto-scaling backend with no servers to manage. More details: https://docs.aws.amazon.com/apigateway/latest/developerguide/what-is-api-gateway.html and https://docs.aws.amazon.com/lambda/latest/dg/welcome.html

• DynamoDB is a serverless NoSQL database that can scale to millions of requests per second and delivers single-digit millisecond latency when properly provisioned/used. More details: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html

Option A: Incorrect — Hosting the entire site (including dynamic APIs and order processing) solely in S3 + CloudFront and storing order data in S3 is not appropriate for transactional workloads; S3 is object storage and not a low-latency transactional database.

Option B: Incorrect — EC2 + Auto Scaling + ALB + RDS can scale, but it has much higher operational overhead (managing OS, scaling policies, DB tuning) compared with a serverless approach.

Option C: Incorrect — EKS can handle scale but requires substantial operational effort (cluster management, pod autoscaling tuning, CI/CD, cluster ops). It is not the least-operational solution.

Summary: Option D delivers the best combination of massive scale, millisecond latency, and minimal operational overhead by using managed serverless services and a global CDN.

The correct answer is: D. Create EBS snapshots of the production EBS volumes. Enable the EBS fast snapshot restore feature on the EBS snapshots. Restore the snapshots into new EBS volumes. Attach the new EBS volumes to EC2 instances in the test environment.

This option is correct because taking EBS snapshots and restoring them to new EBS volumes gives you an independent copy that will not affect production. Enabling EBS Fast Snapshot Restore (FSR) on the snapshots ensures that volumes created from those snapshots are fully-initialized and deliver expected steady I/O performance immediately (no “warming” period), which reduces the time-to-ready for the test environment. Restoring snapshots into new EBS volumes and attaching them to test instances provides an isolated, high-performance clone of production data.
More details: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html and https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-restoring-volume.html

Option A: Incorrect because you cannot recover EBS snapshots onto instance store (ephemeral) volumes; instance store volumes are not persistent and cannot be created from snapshots.

Option B: Incorrect because EBS Multi-Attach is not a cloning solution and attaching production volumes to test instances would risk affecting or corrupting production data. Multi-Attach does not create independent copies.

Option C: Incorrect because attaching new EBS volumes to test instances before restoring them from snapshots won't provide usable data; without FSR, restored volumes may require initialization (I/O warm-up) that delays steady I/O performance and increases time-to-ready.

Summary: Option D is the best choice because snapshots + EBS Fast Snapshot Restore create independent, instantly ready volumes that preserve steady I/O and minimize replication time for the test environment.

The correct answer is: D. Deploy a Gateway Load Balancer (GWLB) in the inspection VPC, create a Gateway Load Balancer endpoint for incoming packets, and forward the packets to the appliance.

This option is correct because AWS Gateway Load Balancer is purpose-built to insert, scale, and manage third-party virtual network appliances (firewalls, IDS/IPS, deep-packet inspection) into your VPC traffic path. GWLB provides a single entry/exit point and uses the GENEVE protocol to forward traffic to appliance targets while maintaining flow stickiness and symmetry, which minimizes operational overhead compared with building custom routing or using ALB/NLB workarounds. More details: https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html and https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html. AWS Documentation+1

Option A (Network Load Balancer) is incorrect because an NLB operates at L4 and is not designed to provide the transparent “bump-in-the-wire” inspection pattern or GENEVE traffic encapsulation that many virtual appliances expect; it doesn’t provide the managed appliance scaling and flow management GWLB offers.

Option B (Application Load Balancer) is incorrect because an ALB is an L7 (HTTP/HTTPS) load balancer and cannot handle raw IP packet inspection or forward traffic to network appliances for packet-level inspection. It’s unsuitable for inline network-level inspection.

Option C (Transit Gateway routing alone) is incorrect because while Transit Gateway can route traffic between VPCs, it doesn’t provide a managed, scalable inline appliance orchestration layer. You would still need GWLB or custom routing + appliance management to achieve the same inspection and scaling behavior—so operational overhead would be higher. AWS Documentation

Summary: Use Gateway Load Balancer (Option D) to centrally and transparently forward incoming traffic to your virtual firewall appliance with minimal custom routing or operational overhead. For implementation guidance and best practices, see:

• https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html

• https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html

• https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/

The correct answer is: A. The solutions architect should create an IAM role granting access to the S3 bucket, and then attach the role to the EC2 instances.

This option is correct because the recommended and secure way to grant AWS resources (like EC2) access to other AWS services (like S3) is by using IAM roles with instance profiles. The EC2 instances assume the role automatically, and temporary credentials are provided by AWS, avoiding hardcoding or manual credential management.
More details: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

Option B: Incorrect because IAM policies cannot be attached directly to EC2 instances. They must be attached to roles or users.

Option C: Incorrect because IAM groups are used to organize users and apply policies to them, not to attach permissions to EC2 instances.

Option D: Incorrect because IAM users are intended for human access or applications outside AWS. Attaching static credentials to EC2 instances is insecure and not recommended.

Summary: The best practice is to create an IAM role with S3 access permissions and attach it to the EC2 instances (Option A).

The correct answer is: C. Implement Amazon Aurora with a Multi-AZ deployment and Aurora Replicas configured with Aurora Auto Scaling.

This option is correct because Amazon Aurora is purpose-built for high availability and scalable read performance. Aurora’s architecture separates storage and compute, supports automatic failover in Multi-AZ deployments, and lets you create Aurora Replicas that offload read traffic. With Aurora Replica Auto Scaling you can automatically add or remove replicas based on metrics (for example CPU, connections, or replica lag), which provides an automatic, elastic response to unpredictable read workloads while maintaining high availability.
More details:

• Aurora overview: https://aws.amazon.com/rds/aurora/

• Aurora Replicas & Auto Scaling: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replica.AutoScaling.html

Option A: Incorrect because Amazon Redshift is a data warehouse optimized for analytics, not for serving transactional OLTP workloads or low-latency application reads. A single-node Redshift cluster does not provide the transactional scaling or HA required.

Option B: Incorrect because an RDS Single-AZ deployment is not highly available; although you can create read replicas in other AZs, that approach does not provide the built-in, automated replica autoscaling and seamless Multi-AZ HA that Aurora offers. It would require more manual management to scale and ensure availability.

Option D: Incorrect because ElastiCache (Memcached) is an in-memory cache that can accelerate reads but does not provide durable transactional storage or the automatic database scaling/HA required for the primary DB tier. Using EC2 Spot Instances for cache nodes also reduces reliability due to potential interruptions.

Summary: Option C is the best fit because Amazon Aurora (Multi-AZ) + Aurora Replicas with Replica Auto Scaling provides automated, highly available scaling of read capacity while keeping operational overhead low.

The correct answer is: A. Store credentials in AWS Secrets Manager with multi-Region replication and rotation scheduled.

This option is correct because AWS Secrets Manager is specifically designed to manage database credentials and rotate them automatically without custom code. With multi-Region replication, credentials are synchronized across Regions, ensuring availability for all RDS instances. This approach minimizes operational overhead since AWS handles both storage security and rotation automatically.
More details: https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets.html

Option B: Incorrect because while AWS Systems Manager Parameter Store can store credentials, it does not natively support automatic rotation. Implementing secure rotation would require additional Lambda functions, increasing operational overhead.

Option C: Incorrect because storing credentials in Amazon S3 and handling rotation with EventBridge + Lambda requires a fully custom solution. This adds complexity and increases operational burden compared to Secrets Manager.

Option D: Incorrect because using DynamoDB global tables + KMS encryption + Lambda rotation is overly complex and requires significant custom management. It does not natively provide the seamless credential rotation that Secrets Manager offers.

Summary: Option A is correct because AWS Secrets Manager provides the simplest, most automated, and least operationally heavy solution for credential rotation across multiple Regions.

The correct answer is: A. Generate an Amazon CloudFront distribution with the S3 bucket and ALB origins and configure Route 53 to direct traffic to the CloudFront distribution.

This option is correct because Amazon CloudFront is a global content delivery network (CDN) that reduces latency by caching content at edge locations. CloudFront supports multiple origins, which allows you to configure the S3 bucket for static content and the ALB for dynamic content within the same distribution. By routing traffic through CloudFront using Route 53, users benefit from faster performance, lower latency, and improved scalability for both static and dynamic data.
More details: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html

Option B: Incorrect because AWS Global Accelerator is used to improve availability and performance of applications across multiple AWS Regions. In this case, performance gains come from caching at the edge (CloudFront), not routing acceleration.

Option C: Incorrect because combining CloudFront with Global Accelerator for this workload adds unnecessary complexity and cost. The requirement is already met by CloudFront with dual origins.

Option D: Incorrect because managing two separate domain names (one for static and one for dynamic content) complicates architecture and user access. A single CloudFront distribution with multiple origins is the simplest and most efficient approach.

Summary: Option A is correct because CloudFront with S3 and ALB as origins, integrated with Route 53, provides a unified, low-latency, and scalable solution to serve both static and dynamic content under a single domain.

The correct answer is: B. Use an API Gateway integration to deliver a message to an Amazon Simple Queue Service (Amazon SQS) FIFO queue when the application receives an order. Then, set up the SQS FIFO queue to invoke an AWS Lambda function for processing.

This option is correct because SQS FIFO queues ensure that messages are processed exactly once and in the same order they were sent. For an e-commerce system, processing orders in sequence without duplication is critical. By integrating API Gateway with an SQS FIFO queue and then triggering AWS Lambda, the solution ensures that orders are processed reliably and immediately as they arrive.
More details: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html

Option A: Incorrect because SNS is a pub/sub service that delivers messages to multiple subscribers, but it does not guarantee strict ordering or exactly-once processing, which are critical for e-commerce order handling.

Option C: Incorrect because an API Gateway authorizer is for request authentication/authorization, not for ensuring reliable or ordered order processing.

Option D: Incorrect because an SQS standard queue provides at-least-once delivery with best-effort ordering. This could result in out-of-order or duplicate order messages, which is unacceptable for order processing.

Summary: Option B is correct because SQS FIFO queues provide guaranteed ordering and exactly-once processing, which are required for reliable e-commerce order handling.

The correct answer is: B. Create an Amazon S3 File Gateway to extend the company's storage space. Create an S3 Lifecycle policy to transition the data to S3 Glacier Deep Archive after 7 days.

This option is correct because Amazon S3 File Gateway provides an SMB-compatible file share that extends the company’s existing on-premises storage into Amazon S3. Frequently accessed files remain cached locally for low-latency access, while older files are stored in Amazon S3. By applying an S3 Lifecycle policy, the company can automatically transition files that are rarely accessed after 7 days to cheaper storage classes such as S3 Glacier, addressing the need for lifecycle management and avoiding capacity issues.
More details: https://docs.aws.amazon.com/filegateway/latest/userguide/what-is-file-gateway.html

Option A: Incorrect because AWS DataSync is a data transfer service, not a storage extension or lifecycle management solution.

Option C: Incorrect because Amazon FSx for Windows File Server provides SMB storage but does not integrate directly with S3 Lifecycle policies for archival management.

Option D: Incorrect because installing an S3 utility on every user’s computer adds operational overhead, lacks SMB compatibility, and lifecycle transitions to S3 Glacier Flexible Retrieval would still cause delayed access to files.

Summary: Option B is correct because it combines seamless SMB access with S3 scalability and automatic lifecycle management, ensuring both low-latency access for recent files and cost-effective storage for older files.

The correct answer is: B. Configure an Amazon Simple Queue Service (Amazon SQS) queue as a destination for the jobs, while implementing the compute nodes using Amazon EC2 instances managed in an Auto Scaling group. Configure EC2 Auto Scaling based on the size of the queue to ensure maximum resiliency and scalability.

This option is correct because SQS provides durable, decoupled job queuing and handles variable workloads reliably. Using Auto Scaling tied to the queue depth ensures the compute fleet scales dynamically with demand, improving resiliency and cost efficiency. This removes the single point of failure of a primary server and leverages AWS-managed scalability. More details: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html

Option A: Incorrect because scheduled scaling is static and does not adapt to unpredictable or variable workloads. This would not achieve maximum resiliency or scalability.

Option C: Incorrect because CloudTrail is for auditing and logging API calls, not for job queuing or workload distribution. Using CloudTrail as a destination for jobs is not feasible.

Option D: Incorrect because EventBridge (CloudWatch Events) is designed for event-driven automation, not for buffering large volumes of distributed jobs. It is not suitable as a job queue compared to SQS, which is built for reliable, scalable workload distribution.

In summary, Option B best modernizes the distributed architecture, decouples components, and ensures elastic scalability by combining SQS + EC2 Auto Scaling on queue depth.

The correct answer is: D. Transmit the messages to an Amazon Simple Notification Service (Amazon SNS) topic with multiple Amazon Simple Queue Service (Amazon SQS) subscriptions. Set up the consumer applications to handle the messages from the queues.

This option is correct because the SNS → SQS fan-out pattern instantly delivers each message to multiple durable SQS queues so many independent consumers can process the same message in parallel. SQS provides buffering and backpressure (each consumer can scale and process at its own pace), and SNS handles the push distribution to all subscribers — a simple, highly decoupled, and scalable architecture for very high and highly variable message volumes. More on the fan-out pattern and how SNS delivers to SQS: https://docs.aws.amazon.com/sns/latest/dg/sns-sqs-as-subscriber.html.

Option A — Kinesis Data Analytics (save to Kinesis Data Analytics and have consumers read): Kinesis can handle streaming at scale, but it’s more appropriate when you need ordered streams, real-time stream processing, or windowed analytics. Also, Kinesis Data Streams shard limits (1 MB/sec or 1,000 records/sec per shard) mean you must provision many shards to reach spikes of ~100,000 records/sec, adding operational complexity. For simple fan-out to many independent consumers, SNS+SQS is simpler and more cost-effective. See Kinesis shard quotas and scaling guidance: https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html.

Option B — Ingest on EC2 Auto Scaling group: Auto Scaling based on CPU doesn’t provide the same reliable buffering, fan-out, or decoupling as managed messaging services. EC2 adds operational overhead (managing instances, resilience, scaling policies) and is not ideal for delivering the same message to many consumers concurrently.

Option C — Single Kinesis shard + Lambda + DynamoDB then consumers read DynamoDB: A single Kinesis shard supports only up to ~1,000 records/sec writes, so it cannot handle peaks of 100,000 messages/sec. Also, writing everything to DynamoDB for downstream consumers to poll defeats the purpose of a messaging/fan-out architecture and adds unnecessary complexity and latency. Kinesis could work with many shards, but that increases operational management versus SNS+SQS fan-out for this use case.

Summary: Use SNS + multiple SQS subscriptions (Option D). It implements durable fan-out, provides per-consumer buffering and retry semantics, decouples producers from many consumers, and is operationally lightweight compared with managing a large Kinesis shard fleet or EC2-based ingestion. For implementation guidance, see the SNS→SQS fan-out docs and the SNS getting-started tutorial: https://docs.aws.amazon.com/sns/latest/dg/sns-sqs-as-subscriber.html

The correct answer is: B. Use the Snowball Edge client to transfer data to an AWS Snowball Edge device received on premises, and return the device so that AWS can import the data into Amazon S3.

This option is correct because Snowball Edge devices are designed for large-scale offline data transfers when you want to minimize use of network bandwidth. For 70 TB of mixed-size video files (1 MB → 500 GB), physically shipping Snowball Edge(s) lets you move the data far faster than over a constrained WAN or Internet link and avoids prolonged bandwidth consumption and long transfer windows. Snowball Edge supports high-capacity devices (tens of TB per device) and best-practice workflows for secure, efficient bulk import into S3. More details:

• https://aws.amazon.com/snowball/

• https://aws.amazon.com/blogs/storage/best-practices-for-accelerating-data-migrations-using-aws-snowball-edge/

Option A: Use the AWS CLI to copy all files over the network.
This option is incorrect because copying 70 TB over the public Internet would consume large amounts of network bandwidth and could take a very long time depending on available throughput—contrary to the requirement to minimize bandwidth usage.

Option C: Deploy an S3 File Gateway on premises and create a public service endpoint to connect to it, then transfer the data.
This option is incorrect for the stated goal because the S3 File Gateway streams and buffers writes to S3 over your network; it still requires significant network bandwidth to upload 70 TB (the gateway only reduces complexity and provides NFS/SMB access, it does not avoid heavy WAN use). File Gateway is a good option for ongoing hybrid access or incremental syncs, but not optimal for the initial bulk migration when bandwidth is the limiting factor. More details: https://docs.aws.amazon.com/filegateway/latest/files3/best-practices.html

Option D: Deploy an S3 File Gateway and set up AWS Direct Connect with a public VIF.
This option is incorrect because while Direct Connect can provide higher and more consistent bandwidth (reducing Internet usage), provisioning Direct Connect is often time-consuming and costly. Creating a Direct Connect connection specifically for a one-time 70 TB bulk migration is usually less practical than shipping Snowball Edge devices. Direct Connect + File Gateway adds complexity and lead time that contradicts the requirement to migrate as soon as possible with minimal network usage.

Summary: For a one-time bulk migration of ~70 TB where minimizing WAN/internet bandwidth usage and migrating quickly are priorities, Snowball Edge (Option B) is the best choice. See AWS Snowball overview and migration guidance: https://aws.amazon.com/snowball/ and https://aws.amazon.com/blogs/storage/best-practices-for-accelerating-data-migrations-using-aws-snowball-edge/.

The correct answer is: C. Shift all the documents from the EBS volumes to Amazon EFS and integrate the application to save new documents to Amazon EFS.

This option is correct because Amazon EFS (Elastic File System) provides a shared, POSIX-compliant file system that can be mounted concurrently by multiple EC2 instances. Moving documents to EFS ensures both application servers see the same file set at the same time, eliminating inconsistencies caused by per-instance EBS storage. EFS is managed, highly available, and scales automatically, minimizing operational overhead for shared file access.
More details can be found at: https://docs.aws.amazon.com/efs/latest/ug/what-is-efs.html

Option A: Duplicate all the documents to both EBS volumes.
This option is incorrect because keeping duplicated copies on each instance creates synchronization complexity and possible consistency issues. It also increases storage and operational overhead to keep replicas in sync.

Option B: Configure the Application Load Balancer to route users to the server with the required documents.
This option is incorrect because the ALB only routes requests — it cannot guarantee the correct instance holds the needed documents (and routing based on document location would be complex and fragile). This is not a scalable or maintainable solution.

Option D: Configure the Application Load Balancer to direct the request to both servers.
This option is incorrect because an ALB cannot send a single request simultaneously to multiple targets in order to merge responses; it routes each request to one healthy target. This does not solve the underlying data consistency / shared storage problem.

In summary, using Amazon EFS (Option C) gives both EC2 instances a single shared file system so users will always see the full set of documents, with minimal operational overhead.

The correct answer is: A. Create a gateway VPC endpoint to the S3 bucket.
This option is correct because a gateway VPC endpoint allows private network connectivity between a VPC and Amazon S3 without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect. It ensures that EC2 instances in the VPC can access S3 buckets securely over the AWS private network. This solution meets the requirement of accessing S3 without using the internet.
More details can be found at: https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html

Option B: Stream logs to Amazon CloudWatch Logs and export them to the S3 bucket.
This option is incorrect because exporting from CloudWatch Logs to S3 does not establish private connectivity. It only provides a mechanism to move logs, not a direct access path from EC2 to S3 without the internet.

Option C: Create an instance profile on Amazon EC2 to allow access to S3.
This option is incorrect because an instance profile (IAM role) only provides permissions to access S3. It does not control the network path, so without a VPC endpoint, the traffic would still go through the internet.

Option D: Create an Amazon API Gateway API with a private link to access the S3 endpoint.
This option is incorrect because API Gateway is not needed to connect EC2 to S3. Using API Gateway adds unnecessary complexity and cost. The simplest and most secure solution is to use a gateway VPC endpoint.

In summary, creating a gateway VPC endpoint (Option A) is the correct solution because it provides private, secure, and scalable access to Amazon S3 from within a VPC without requiring internet connectivity.

The correct answer is: A. Add the aws:PrincipalOrgID global condition key to the S3 bucket policy with a reference to the organization ID.
This option is correct because the aws:PrincipalOrgID global condition key enables you to restrict access to principals (users, roles, accounts) that are members of a specific AWS Organization. By referencing the organization ID in the bucket policy, only identities within that organization can access the bucket. This approach provides a centralized, low-maintenance solution with minimal operational overhead.
More details can be found at: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid

Option B: Use aws:PrincipalOrgPaths with organizational units (OUs).
This option is incorrect because aws:PrincipalOrgPaths is not intended for restricting S3 bucket access in this scenario. It specifies the path of the principal in the organization hierarchy but does not limit access effectively compared to aws:PrincipalOrgID.

Option C: Use AWS CloudTrail to monitor organization events and update policies.
This option is incorrect because CloudTrail is a logging and auditing tool, not an access control mechanism. Continuously updating policies based on events would create unnecessary complexity and high operational overhead.

Option D: Tag each user and use aws:PrincipalTag in the bucket policy.
This option is incorrect because tagging individual users across multiple accounts is difficult to scale and prone to human error. Managing access this way introduces significant operational overhead compared to using the organization ID.

In summary, the most efficient and scalable solution is to add the aws:PrincipalOrgID global condition key to the S3 bucket policy (Option A). This ensures that only principals within the specified AWS Organization can access the bucket while keeping the architecture simple and low-maintenance.

The correct answer is: C. Use Amazon Athena directly with Amazon S3 to perform the necessary queries.
This option is correct because Amazon Athena allows you to run SQL queries directly on data stored in Amazon S3 without the need to move or transform the data. Since the logs are already in JSON format, Athena can query them on demand with minimal setup. This approach avoids the overhead of managing clusters or loading data into a data warehouse. Athena is fully serverless and scales automatically, providing the lowest operational overhead.
More details can be found at: https://docs.aws.amazon.com/athena/latest/ug/what-is.html

Option A: Load all the content into one place using Amazon Redshift.
This option is incorrect because Redshift requires data loading and ongoing cluster management, which introduces unnecessary operational overhead for simple, on-demand queries.

Option B: Store the logs in Amazon CloudWatch Logs and run SQL queries from the console.
This option is incorrect because CloudWatch Logs is designed for log aggregation and monitoring, not for ad-hoc SQL analytics. It does not natively provide the querying flexibility of Athena for JSON logs in S3.

Option D: Catalog the logs using AWS Glue and utilize Amazon EMR with Spark.
This option is incorrect because running transient EMR clusters adds significant operational overhead compared to Athena. EMR is more suitable for complex, large-scale transformations rather than simple, ad-hoc SQL queries.

In summary, Amazon Athena (C) is the best solution because it allows direct querying of JSON log files in Amazon S3 with zero infrastructure management, perfectly meeting the requirement to minimize operational overhead.

The correct answers are: A and B.

Option A: Set up an Amazon Simple Queue Service (Amazon SQS) queue and configure the S3 bucket to notify the queue when an image is uploaded.
This option is correct because S3 event notifications can be configured to send a message to an SQS queue whenever a new object is created. This creates a decoupled, resilient architecture where uploads to S3 reliably trigger downstream processing. More details can be found at: https://docs.aws.amazon.com/AmazonS3/latest/userguide/NotificationHowTo.html

Option B: Use the Amazon Simple Queue Service (Amazon SQS) queue as the launch source to create the Lambda function and delete the message once it's successfully processed.
This option is correct because Lambda can poll an SQS queue, invoke the function for each message, and automatically delete the message once it is successfully processed. This provides a scalable, stateless, and fault-tolerant mechanism to handle image compression and processing. More details can be found at: https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html

Option C: Configure the Lambda function to check the S3 bucket for new images.
This option is incorrect because Lambda functions do not "poll" S3. Instead, event-driven architecture should be used where S3 notifies SQS or Lambda directly when an object is uploaded.

Option D: Deploy an Amazon EC2 instance to keep an eye on the SQS queue.
This option is incorrect because introducing an EC2 instance adds unnecessary operational overhead. Lambda already natively integrates with SQS for automatic message polling and scaling, making EC2 redundant.

Option E: Configure an Amazon EventBridge event to watch the S3 bucket and send alerts via SNS.
This option is incorrect because while EventBridge can capture S3 events, forwarding them to SNS and email does not meet the requirement for automatic image processing. This would only notify users rather than process images.

In summary, the correct design is to configure S3 to send notifications to an SQS queue (A), and then use Lambda triggered by the SQS queue to process the images automatically (B). This solution is fully serverless, resilient, and stateless, meeting the company’s requirements.

The correct answer is: A. Turn on S3 Transfer Acceleration on the destination S3 bucket. Use multipart uploads to directly upload site data to the destination S3 bucket.
This option is correct because S3 Transfer Acceleration leverages Amazon CloudFront’s globally distributed edge locations to accelerate data uploads into Amazon S3 over long distances. Since the company has multiple sites across continents, Transfer Acceleration minimizes latency and optimizes throughput, making the daily upload of 500 GB per site both fast and reliable. Multipart uploads further improve efficiency by enabling parallel transfers of large files, while also providing resilience in case of network interruptions. This solution also minimizes operational complexity since data is uploaded directly into the destination bucket without requiring replication workflows or hardware devices.
More details can be found at: https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html

Option B: Upload the data from each site to an S3 bucket in the closest Region. Use S3 Cross-Region Replication.
This option is incorrect because Cross-Region Replication introduces extra latency and operational overhead. Data must first be stored in an intermediate bucket before being replicated, which delays availability in the destination bucket.

Option C: Schedule AWS Snowball Edge device jobs daily.
This option is incorrect because Snowball Edge devices are intended for large-scale data migrations or offline transfers, not for continuous daily ingestion of 500 GB per site. Using them every day would add unnecessary cost and operational complexity.

Option D: Upload the data to Amazon EC2, store in EBS, and copy snapshots.
This option is incorrect because routing data through EC2 and EBS adds significant overhead and latency. Snapshot creation, copying, and restoration is far slower and more complex compared to direct uploads into S3.

In summary, enabling S3 Transfer Acceleration with multipart uploads is the best solution because it provides the fastest, most reliable, and least complex way to aggregate large volumes of data from globally distributed sites into a single S3 bucket.