All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A financial services company runs a high-throughput transaction reporting application in the `us-west-2` Region. The application's compute layer consists of Amazon EC2 instances in an Auto Scaling group distributed across $3$ Availability Zones (`us-west-2a`, `us-west-2b`, and `us-west-2c`). The database layer is an Amazon Aurora PostgreSQL cluster consisting of $1$ writer instance in `us-west-2a` and $3$ reader instances distributed across the same $3$ Availability Zones (one reader per zone).

The application EC2 instances perform intensive read operations, querying the database cluster using the default Aurora Reader endpoint. The database traffic amounts to approximately $150\text{ TB}$ of data read per month. The company's monthly AWS bill shows a significant charge for cross-AZ data transfer between the EC2 instances and the Aurora reader instances.

A solutions architect must optimize the database architecture to minimize these cross-AZ data transfer costs without modifying the application code, except for database connection strings.

Which of the following is the most cost-effective and operationally sound solution?

Create three custom endpoints in the Aurora cluster, one for each Availability Zone, and associate each custom endpoint with the reader instance located in that specific Availability Zone. Configure the application connection pool on the EC2 instances in each Availability Zone to connect to their corresponding local custom reader endpoint.

Deploy an Amazon RDS Proxy cluster with an endpoint in each of the three Availability Zones. Configure the EC2 instances in each Availability Zone to connect to the RDS Proxy endpoint in their local zone, allowing RDS Proxy to pin read connections to the local reader instance.

Configure a Route 53 Private Hosted Zone with latency-based routing records that map the database hostname directly to the private IP addresses of the individual Aurora reader instances. Have the EC2 instances use these records to connect to the closest reader.

Configure Amazon Aurora Auto Scaling with a scaling policy based on the average database connection count. This will dynamically scale the number of reader instances in each Availability Zone to match the EC2 instance count, ensuring traffic remains local.

Show answer & explanation

Answer: Create three custom endpoints in the Aurora cluster, one for each Availability Zone, and associate each custom endpoint with the reader instance located in that specific Availability Zone. Configure the application connection pool on the EC2 instances in each Availability Zone to connect to their corresponding local custom reader endpoint.

Answer

The correct solution uses Aurora custom endpoints to group the reader instances by Availability Zone. Since cross-AZ data transfer within a VPC incurs charges, routing the EC2 application traffic to a reader instance in the same Availability Zone eliminates these data transfer costs. Custom endpoints are operationally sound because they are native Aurora DNS endpoints that automatically track the health of the associated instances, avoiding the need for manual IP tracking or application-level routing.

Step-by-Step Solution

Identify the source of the cost: cross-Availability Zone database read traffic.

Database traffic of approximately

150\text{ TB}

per month is being routed across Availability Zones, incurring substantial data transfer charges.

By default, the Aurora Reader endpoint routes traffic round-robin across all readers in the cluster, regardless of their Availability Zone location.

Evaluate the architectural options to achieve Availability Zone affinity.

Aurora custom endpoints allow grouping specific DB instances and expose them via unique DNS hostnames.

Grouping reader instances by Availability Zone ensures that connection requests can be localized.

Create and configure custom reader endpoints.

Three custom endpoints are created, each containing only the reader instance residing in that respective Availability Zone.

This guarantees that any connection to a specific custom endpoint will only route to the reader in that specific Availability Zone.

Configure the application database connection strings in each Availability Zone.

EC2 instances in each Availability Zone are configured to use their local custom endpoint hostname.

This routes all read queries to the local reader, completely bypassing cross-AZ paths and eliminating the associated data transfer charges.

Key Concept

Using Aurora custom endpoints to enforce Availability Zone affinity for database read traffic to eliminate cross-AZ data transfer costs.

Question 1622Question →

A company is planning to migrate a self-managed PostgreSQL database hosted on-premises to an Amazon Aurora MySQL-Compatible Edition DB cluster. The migration must convert the schema and support ongoing replication to minimize cutover downtime. The source database is highly active, and the replication task must capture ongoing transactions via change data capture (CDC).

Which two actions must the solutions architect take to support schema conversion and change data capture (CDC) for this database migration? (Select two.)

Select all that apply

Use the AWS Schema Conversion Tool (SCT) to convert the PostgreSQL schema, functions, and stored procedures to MySQL-compatible formats, and apply the converted schema to the target Aurora DB cluster.

Set the wal_level parameter to logical on the source PostgreSQL database to enable the generation of write-ahead logs suitable for AWS DMS replication.

Enable the Microsoft Change Data Capture (MS-CDC) feature on the source database tables to track transactional changes.

Modify the source database configuration to set the binlog_format parameter to ROW and configure binary log retention.

Deploy an AWS SCT extraction agent on the source database host to stream write-ahead log (WAL) records directly to the AWS DMS replication instance.

Show answer & explanation

Answer: Use the AWS Schema Conversion Tool (SCT) to convert the PostgreSQL schema, functions, and stored procedures to MySQL-compatible formats, and apply the converted schema to the target Aurora DB cluster.; Set the wal_level parameter to logical on the source PostgreSQL database to enable the generation of write-ahead logs suitable for AWS DMS replication.

Answer

The solutions architect must use the AWS Schema Conversion Tool (SCT) to convert the database schema to MySQL-compatible formats and apply it to the target, and set the wal_level parameter to logical on the source PostgreSQL database.

The correct actions are to use the AWS Schema Conversion Tool (SCT) to convert the PostgreSQL schema to MySQL-compatible formats, and to configure the wal_level parameter to logical on the source PostgreSQL database. Since the migration is heterogeneous (PostgreSQL to MySQL), SCT is necessary to convert schema objects and database code. For CDC, AWS DMS uses logical replication on PostgreSQL, which requires the write-ahead log level (wal_level) to be set to logical to generate the replication stream.

Step-by-Step Solution

Analyze the migration type (source and target engines).

The migration is heterogeneous (PostgreSQL on-premises to Amazon Aurora MySQL), meaning the database schemas are incompatible and require schema conversion.

Identifying the compatibility of the source and target engines determines if AWS SCT is required.

Select the appropriate tool for schema conversion.

AWS Schema Conversion Tool (SCT) is selected to convert PostgreSQL schema, functions, and stored procedures to MySQL-compatible SQL scripts, which are then applied to the target Aurora DB cluster.

Heterogeneous schema conversion cannot be performed directly by AWS DMS and requires AWS SCT.

Configure the source PostgreSQL database for Change Data Capture (CDC).

Set the wal_level parameter to logical in the postgresql.conf file and restart the instance.

AWS DMS uses logical replication slots to capture ongoing changes from PostgreSQL, which requires the write-ahead log (WAL) level to be set to logical.

Key Concept

Heterogeneous database migration using AWS SCT for schema conversion and AWS DMS logical replication (wal_level = logical) for ongoing change data capture (CDC).

Question 1623Question →

ApexMedia is migrating its high-throughput video processing orchestration system from an on-premises data center to AWS. The target architecture will use Amazon Elastic Container Service (Amazon ECS) on AWS Fargate. Containers running in the Production and Development accounts must pull images from a centralized Amazon Elastic Container Registry (ECR) repository located in a Shared Services account. To comply with strict security standards, tasks must run in private subnets with no internet access (no NAT Gateways). The container images and secrets are encrypted using a Customer Managed Key (CMK) in AWS KMS in the Shared Services account. A Transit Gateway connects the Production, Development, and Shared Services VPCs. The Solutions Architect must configure cross-account access, networking, and DNS resolution to ensure Fargate tasks can pull images and decrypt required secrets from AWS Secrets Manager (which is also encrypted with the same KMS CMK in the Shared Services account).

Which combination of actions must the Solutions Architect perform to successfully deploy the containers? (Select TWO.)

Select all that apply

In the Shared Services account, update the ECR repository policy and the Secrets Manager resource policy to grant read access to the ECS Task Execution Roles of the Production and Development accounts. Update the key policy of the KMS Customer Managed Key in the Shared Services account to grant kms:Decrypt and kms:DescribeKey permissions to these execution roles.

Configure the ECS task definitions to use the awsvpc network mode. In both the Production and Development VPCs, deploy interface VPC endpoints with Private DNS enabled for ECR (ecr.api and ecr.dkr), Secrets Manager, and KMS, and create a gateway VPC endpoint for Amazon S3 associated with the subnet route tables.

Configure the ECS task definitions to use the bridge network mode to leverage Docker port mapping. In both the Production and Development VPCs, deploy interface VPC endpoints with Private DNS enabled for ECR and Secrets Manager, and route all S3 layer download traffic through a single NAT Gateway located in the Shared Services VPC.

Configure the ECR repository and Secrets Manager to use the default AWS-managed KMS keys (aws/ecr and aws/secretsmanager) for encryption, and update the default key policies to allow cross-account access from the Production and Development ECS Task Execution Roles.

In the Shared Services VPC, deploy a gateway VPC endpoint for Amazon S3. Configure the Transit Gateway route tables to route all S3-bound traffic from the Production and Development VPC subnets to the Shared Services VPC to allow tasks to download image layers.

Show answer & explanation

Answer: In the Shared Services account, update the ECR repository policy and the Secrets Manager resource policy to grant read access to the ECS Task Execution Roles of the Production and Development accounts. Update the key policy of the KMS Customer Managed Key in the Shared Services account to grant kms:Decrypt and kms:DescribeKey permissions to these execution roles.; Configure the ECS task definitions to use the awsvpc network mode. In both the Production and Development VPCs, deploy interface VPC endpoints with Private DNS enabled for ECR (ecr.api and ecr.dkr), Secrets Manager, and KMS, and create a gateway VPC endpoint for Amazon S3 associated with the subnet route tables.

Answer

The correct actions are: updating the ECR repository policy, Secrets Manager resource policy, and KMS key policy in the Shared Services account to grant access to the consumer task execution roles; and configuring the ECS tasks to use the awsvpc network mode while deploying local interface VPC endpoints for ECR, Secrets Manager, and KMS alongside a local S3 gateway endpoint in both the Production and Development VPCs.

The correct architecture requires configuring the ECS task definitions to use the awsvpc network mode since Fargate does not support bridge mode. In VPCs without internet access, local interface VPC endpoints are required for ECR and Secrets Manager, and a local Gateway VPC endpoint is required for S3 because S3 Gateway endpoints do not support transitive routing over Transit Gateway. Additionally, cross-account access to ECR, Secrets Manager, and the Customer Managed Key (CMK) must be explicitly allowed by updating the ECR repository policy, Secrets Manager resource policy, and the KMS CMK key policy in the Shared Services account to trust the ECS Task Execution Roles of the consumer accounts.

Step-by-Step Solution

Select Fargate compatible network mode

ECS tasks must be configured to use the awsvpc network mode, which is the only network mode supported by AWS Fargate.

Fargate does not support bridge or host network modes.

Establish local endpoints in consumer VPCs

Create interface VPC endpoints (ECR API, ECR DKR, Secrets Manager, KMS) and a gateway VPC endpoint for S3 in the Production and Development VPCs.

Since tasks run in private subnets with no internet routes, local endpoints are required for service communication. Gateway endpoints cannot be routed transitively over Transit Gateway, necessitating local S3 gateway endpoints for image layer retrieval.

Configure cross-account resource access policies

Add policies on the ECR repository and Secrets Manager in the Shared Services account permitting read/get access to the task execution roles in the Production and Development accounts.

Resource-based policies are required to authorize cross-account API calls to pull images and read secrets.

Grant decryption rights on the Customer Managed Key (CMK)

Modify the KMS key policy of the CMK in the Shared Services account to allow the ECS Task Execution Roles in the Prod/Dev accounts to perform kms:Decrypt and kms:DescribeKey actions.

Because AWS-managed keys cannot be accessed cross-account, a Customer Managed Key must be used, and its key policy must explicitly authorize cross-account decryption operations.

Key Concept

Deploying containerized workloads on AWS Fargate in highly secure, isolated multi-account environments requires using the awsvpc network mode, configuring local interface and gateway VPC endpoints to avoid internet routing, and utilizing cross-account resource policies alongside KMS Customer Managed Key policies to delegate decryption rights.

Question 1624Question →

A financial services company manages its multi-account environment using AWS Organizations. The security team mandates that all Amazon EBS volumes across all member accounts must be backed up daily, and the backups must be stored in a central vault. The company wants to delegate the administration of these backup policies to a dedicated backup-admin account, minimizing the use of the Organizations management account.

Arrange the correct sequence of steps to configure this centralized backup governance model across the organization.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order begins with enabling the Backup policy type in the management account, followed by registering the delegated administrator, creating the destination backup vault and access policy, creating the backup policy, and finally attaching the policy to the target OUs.

The correct sequence ensures that prerequisites are met at each stage: enabling the policy type, delegating administrative rights, establishing the target storage resource with access controls, defining the compliance policy, and finally applying it to the resource hierarchy.

Step-by-Step Solution

Enable Backup policies in the Organizations management account.

The organization configuration is updated to support Backup policies.

Backup policies cannot be created or managed by any account until the policy type is enabled at the root organization level.

The backup-admin account receives administrative authority for Backup policies across the organization.

The management account must explicitly grant delegated permissions before the member account can perform administrative actions.

Create the centralized Backup vault and associate a cross-account vault access policy in the backup-admin account.

A vault is established that permits recovery points from other accounts in the organization.

Without a valid destination vault ARN and a policy granting cross-account write permissions, backups sent by member accounts will be rejected.

Create the Backup policy in the backup-admin account.

A JSON Backup policy is defined within the organization.

The policy must be created with correct plan details and destination vault configurations before it can be distributed.

Attach the Backup policy to the target OUs in the backup-admin account.

The backup schedule is applied to all accounts and EBS resources within the target OUs.

Attaching the policy initiates and enforces the backup schedule across the specified resources in the member accounts.

Key Concept

Delegated administration in AWS Organizations allows member accounts to manage specific service policies, reducing the operational burden on the management account.

Estimated Time:2m 0s

Question 1625Question →

NexaChem Laboratories is modernizing its laboratory information management system (LIMS) by migrating its containerized chemical analysis microservices to Amazon ECS on AWS Fargate. To comply with strict industry data privacy standards, the microservices must run in a fully private VPC containing only private subnets, with no direct access to the public internet. The container images are built and stored in a centralized Amazon Elastic Container Registry (ECR) repository located in a Shared Services AWS account, and are encrypted using an AWS Key Management Service (AWS KMS) customer managed key (CMK). The ECS tasks also need to access sensitive database credentials stored in AWS Systems Manager Parameter Store in the application account, which are encrypted using a local CMK. Which combination of configuration steps is required to allow the ECS tasks to successfully pull the container images and launch on AWS Fargate? (Select TWO.)

Select all that apply

Create interface VPC endpoints (AWS PrivateLink) in the application VPC for the Amazon ECR API, the ECR Docker registry, and AWS KMS. Create a gateway VPC endpoint for Amazon S3 in the application VPC, and associate it with the route tables of the private subnets where the ECS tasks are deployed.

Configure the ECR repository policy in the Shared Services account to grant read permissions to the application account's ECS Task Execution Role. Update the ECS Task Execution Role's IAM policy in the application account to allow access to ECR API actions and kms:Decrypt permissions on the KMS customer managed key located in the Shared Services account.

Configure the ECS task definition network mode to use host or bridge networking instead of awsvpc, allowing the tasks to leverage local Docker daemon routing to pull images from the cross-account ECR repository.

Encrypt the ECR repository using the default AWS-managed KMS key for ECR (aws/ecr) in the Shared Services account, and modify the key policy of this AWS-managed key to grant kms:Decrypt permissions to the application account's ECS Task Execution Role.

Create a Route 53 Private Hosted Zone for the ECR endpoints in the Shared Services account, and create alias records pointing to the Shared Services VPC endpoints without associating the hosted zone with the application VPC.

Show answer & explanation

Answer: Create interface VPC endpoints (AWS PrivateLink) in the application VPC for the Amazon ECR API, the ECR Docker registry, and AWS KMS. Create a gateway VPC endpoint for Amazon S3 in the application VPC, and associate it with the route tables of the private subnets where the ECS tasks are deployed.; Configure the ECR repository policy in the Shared Services account to grant read permissions to the application account's ECS Task Execution Role. Update the ECS Task Execution Role's IAM policy in the application account to allow access to ECR API actions and kms:Decrypt permissions on the KMS customer managed key located in the Shared Services account.

Answer

Establishing interface endpoints for ECR and KMS along with a gateway endpoint for S3 in the private VPC, combined with granting ECR and KMS decrypt access to the task execution role across accounts.

For ECS on AWS Fargate tasks running in a completely private subnet to pull images from a cross-account ECR repository, two conditions must be met: network accessibility and IAM/KMS permissions. Network accessibility requires interface endpoints for ECR APIs and KMS, as well as an S3 gateway endpoint (since ECR stores image layers in S3). Security requires that the ECS Task Execution Role (which performs the pull and decrypt operations) is granted permission in the ECR repository policy and has kms:Decrypt permissions on the customer managed key in the Shared Services account.

Step-by-Step Solution

Determine the necessary networking endpoints for ECS Fargate to pull from ECR without internet access.

Identify that VPC Interface Endpoints are required for ECR API, ECR registry, and KMS. Additionally, a Gateway Endpoint for S3 is required because ECR stores image layers in S3 buckets.

Since the VPC lacks an internet gateway or NAT gateway, all communication to AWS APIs and S3 layer storage must go through private endpoints.

Establish the cross-account ECR repository and KMS key permissions.

Grant cross-account read access to the application account's ECS Task Execution Role on the Shared Services ECR repository policy, and grant kms:Decrypt permissions on the customer managed key (CMK) policy in the Shared Services account.

The Task Execution Role runs outside the user container context to pull and decrypt images, requiring explicit access to the cross-account repository and CMK.

Key Concept

Configuring secure, private, cross-account image pulls for Amazon ECS tasks running on AWS Fargate in a restricted network environment.

Question 1626Question →

Aetheris Health is modernizing its legacy patient data processing application by migrating it to Amazon ECS. The Solutions Architect must design a highly secure, containerized architecture that runs in private subnets with no internet gateway or NAT gateways. The application must pull container images from a central Amazon ECR registry located in a shared services AWS account, and read encrypted patient datasets from an Amazon S3 bucket in a separate storage AWS account. The data in the S3 bucket is encrypted using an AWS KMS Customer Managed Key (CMK) in the storage account. To optimize container-to-container communication, the development team has requested configuring the tasks to use the `bridge` network mode on AWS Fargate. Which architecture should the Solutions Architect recommend to meet these requirements with the lowest operational overhead?

Configure the ECS task definition to use the bridge network mode on AWS Fargate to enable dynamic port mapping. Create Interface VPC Endpoints in the application VPC for ECR and AWS KMS, and a Gateway VPC Endpoint for S3, with Private DNS enabled. Grant the ECS Task Execution Role ECR pull permissions, and configure the ECR repository policy to trust this role. Configure the ECS Task Role to read S3 and decrypt the data using the Customer Managed Key.

Configure the ECS task definition to use the awsvpc network mode on AWS Fargate. Create Interface VPC Endpoints in the application VPC for ECR (ecr.dkr and ecr.api) and AWS KMS, and a Gateway VPC Endpoint for S3, with Private DNS enabled. Grant the ECS Task Execution Role ECR pull permissions, and trust it in the ECR repository policy. Configure the ECS Task Role with permissions to read from the S3 bucket, encrypting and decrypting the bucket using the default AWS-managed KMS key (aws/s3) to simplify cross-account key management.

Configure the ECS task definition to use the awsvpc network mode on AWS Fargate. Create Interface VPC Endpoints in the application VPC for ECR (ecr.dkr and ecr.api) and AWS KMS, and a Gateway VPC Endpoint for S3, with Private DNS enabled. Grant the ECS Task Execution Role permissions to pull ECR images, and configure the ECR repository policy in the shared services account to trust this role. Grant the ECS Task Role permissions to read S3 and decrypt KMS, and update the Customer Managed Key policy in the storage account to allow kms:Decrypt for the ECS Task Role.

Configure the ECS task definition to use the awsvpc network mode on AWS Fargate. Deploy an AWS Transit Gateway connected to a shared services VPC containing a single NAT Gateway to route ECR and S3 traffic. Create a Route 53 Private Hosted Zone for the ECR endpoints in the shared services account and manually associate it with the application VPC. Use the ECS Task Execution Role for both pulling images and decrypting the S3 objects using the Customer Managed Key.

Show answer & explanation

Answer: Configure the ECS task definition to use the awsvpc network mode on AWS Fargate. Create Interface VPC Endpoints in the application VPC for ECR (ecr.dkr and ecr.api) and AWS KMS, and a Gateway VPC Endpoint for S3, with Private DNS enabled. Grant the ECS Task Execution Role permissions to pull ECR images, and configure the ECR repository policy in the shared services account to trust this role. Grant the ECS Task Role permissions to read S3 and decrypt KMS, and update the Customer Managed Key policy in the storage account to allow kms:Decrypt for the ECS Task Role.

Answer

The correct design configures the ECS task definition to use the awsvpc network mode on AWS Fargate, establishes private communication using Interface VPC Endpoints for ECR and KMS, a Gateway VPC Endpoint for S3, grants ECR pull permissions to the Task Execution Role, and uses the ECS Task Role for cross-account S3 reads and KMS decryption via a Customer Managed Key.

The correct design uses AWS Fargate in awsvpc network mode, which is the only supported mode for Fargate. It establishes private communication via Interface VPC Endpoints for Amazon ECR and AWS KMS, and a Gateway VPC Endpoint for Amazon S3. By using a Customer Managed Key in the storage account and explicitly granting kms:Decrypt permissions to the ECS Task Role (which is used by the containerized application), and granting ECR pull permissions to the ECS Task Execution Role, all compliance and functional requirements are met with minimal operational overhead.

Step-by-Step Solution

Determine the supported network mode for AWS Fargate tasks.

AWS Fargate only supports the `awsvpc` network mode, which assigns each task its own Elastic Network Interface (ENI). The requested `bridge` network mode must be rejected.

To ensure correct network configuration for the Fargate tasks.

Identify VPC endpoints required for private communication in a VPC with no NAT Gateway or Internet Gateway.

Create Interface VPC Endpoints for Amazon ECR (`ecr.dkr` and `ecr.api`) and AWS KMS, and a Gateway VPC Endpoint for Amazon S3, with Private DNS enabled.

To allow tasks to download images and interact with S3 and KMS without routing traffic over the public internet.

Configure ECS Task Execution Role vs Task Role permissions.

The Task Execution Role is configured to authorize container image pulls from ECR. The ECR repository policy in the shared services account must trust the Task Execution Role. The Task Role is configured to allow S3 access and KMS decryption.

To separate container lifecycle actions (Task Execution Role) from application runtime actions (Task Role).

Configure cross-account KMS decryption permissions.

Grant `kms:Decrypt` permission to the ECS Task Role in the Customer Managed Key (CMK) policy located in the storage account.

Cross-account decryption requires customer-managed keys because AWS-managed keys (like `aws/s3`) cannot be shared or modified.

Key Concept

Private VPC endpoint connectivity and cross-account IAM/KMS configurations for ECS Fargate tasks.

Estimated Time:3m 0s

Question 1627Question →

An enterprise runs a data processing application on Amazon EC2 instances within an Auto Scaling Group (ASG) deployed across three Availability Zones (AZs) behind an Application Load Balancer. The application instances take approximately 8 minutes to download a large proprietary dataset, bootstrap services, and pass load balancer health checks. During sudden workload spikes, the ASG scales out based on a target tracking policy, but it consistently launches far more EC2 instances than necessary, leading to underutilized resources and high costs. Additionally, all outbound internet traffic from the private subnets in all three AZs is routed through a single NAT Gateway located in the first AZ.

Which combination of changes should a Solutions Architect implement to optimize the auto-scaling behavior and ensure high availability for outbound traffic?

Configure the instance warmup time in the target tracking scaling policy to 600 seconds. Deploy a NAT Gateway in each of the three Availability Zones, and update the private subnet route tables to direct outbound traffic to the local NAT Gateway in its respective Availability Zone.

Configure the instance warmup time in the target tracking scaling policy to 180 seconds. Deploy a NAT Gateway in each of the three Availability Zones, and update the private subnet route tables to direct outbound traffic to the local NAT Gateway in its respective Availability Zone.

Configure the instance warmup time in the target tracking scaling policy to 600 seconds. Keep the single NAT Gateway in the first Availability Zone, and add a secondary Elastic IP address to it to handle the traffic load from all three Availability Zones.

Submit a request to AWS Support to pre-warm the Application Load Balancer to handle the traffic spikes. Keep the single NAT Gateway in the first Availability Zone, and configure cross-zone load balancing to distribute outbound traffic equally.

Show answer & explanation

Answer: Configure the instance warmup time in the target tracking scaling policy to 600 seconds. Deploy a NAT Gateway in each of the three Availability Zones, and update the private subnet route tables to direct outbound traffic to the local NAT Gateway in its respective Availability Zone.

Answer

The correct option addresses the bootstrapping delay by setting the scaling policy's instance warmup time to 600 seconds (longer than the 8-minute bootstrapping time), preventing premature scale-out. It also ensures fault tolerance by deploying a dedicated NAT Gateway in each Availability Zone, removing the single point of failure for outbound internet traffic.

Step-by-Step Solution

Analyze the instance bootstrapping time and configure the target tracking scaling policy.

Set the instance warmup to 600 seconds, which is greater than the 8 minutes (480 seconds) required for an instance to become ready.

This prevents the scaling policy from launching additional instances prematurely while the initial scaling action is still bootstrapping.

Analyze the outbound routing architecture for the private subnets.

Deploy a NAT Gateway in each of the three Availability Zones.

Having a NAT Gateway in each Availability Zone ensures that if one zone fails, outbound connectivity for the remaining zones is not interrupted.

Update route tables for the private subnets in each Availability Zone.

Point the 0.0.0.0/0 route in each private subnet's route table to the NAT Gateway in its respective Availability Zone.

This creates a localized, fault-tolerant path to the internet for each zone.

Key Concept

Optimizing Auto Scaling policies for long bootstrapping times and ensuring high availability for outbound traffic via NAT Gateways.

Estimated Time:2m 0s

Question 1628Question →

An enterprise is planning to migrate a legacy high-frequency trading platform and its supporting workloads to AWS. The on-premises infrastructure consists of:
- 50 physical bare-metal servers running a custom Linux distribution with a proprietary, non-standard kernel. Corporate security compliance policies strictly prohibit modifying the kernel, installing third-party kernel modules, or deploying any resident agent software on these latency-sensitive systems.
- 250 virtual machines running on Microsoft Hyper-V (Windows Server 2022).
The security compliance team mandates the following rules:
- Deep packet SSL/TLS inspection is active on all outbound firewalls and proxies.
- No direct outbound connections to the public internet are allowed; all traffic must transit through an explicit outbound proxy.
The migration architect needs to:
1. Map network dependencies at the process level for the Hyper-V virtual machines hosting the transactional databases.
2. Obtain CPU, RAM, and disk utilization data for all systems to assist in right-sizing the target AWS instances.
3. Consolidate and track all discovery and migration status data within AWS Migration Hub.

Which approach will satisfy these discovery and tracking requirements with the least operational overhead?

Deploy the AWS Application Discovery Agentless Collector on the Hyper-V hosts. For the bare-metal servers, install the AWS Application Discovery Agent and configure it to bypass the proxy. For the Hyper-V database VMs, enable the database discovery feature in the Agentless Collector to map process-level network connections.

Deploy the AWS Application Migration Service (MGN) replication agent on all Hyper-V virtual machines and physical bare-metal servers. Utilize the replication agent's telemetry to perform dependency mapping in AWS Migration Hub, routing the replication traffic through the SSL/TLS inspecting proxy over TCP port 1500.

Deploy the AWS Application Discovery Agentless Collector on the Hyper-V hosts to gather configuration and performance history for the virtual machines. Export the bare-metal server configurations and performance metrics to a CSV file and import them into AWS Migration Hub. Install the AWS Application Discovery Agent on the Hyper-V database VMs, and import the proxy's root CA certificate into the trusted certificate store of the VM operating systems.

Deploy the AWS Application Discovery Agentless Collector on both the Hyper-V hosts and the physical bare-metal servers. Configure the collector to perform WMI and SSH scans across the network segments to gather configuration and performance history. Enable agentless process-level dependency mapping in the collector settings.

Show answer & explanation

Answer: Deploy the AWS Application Discovery Agentless Collector on the Hyper-V hosts to gather configuration and performance history for the virtual machines. Export the bare-metal server configurations and performance metrics to a CSV file and import them into AWS Migration Hub. Install the AWS Application Discovery Agent on the Hyper-V database VMs, and import the proxy's root CA certificate into the trusted certificate store of the VM operating systems.

Answer

Deploying the Agentless Collector on Hyper-V hosts avoids virtual machine-level agent overhead while gathering VM metrics. Manual CSV import for bare-metal servers respects the policy against agent installation on low-latency kernels. The Discovery Agent is required on the database VMs to map process-level network dependencies, and importing the proxy's root CA certificate ensures the agent can establish secure HTTPS connections through the SSL/TLS inspecting proxy.

Step-by-Step Solution

Determine the discovery mechanism for physical bare-metal servers under the agent restriction constraint.

Since agents cannot be installed on the bare-metal servers due to custom kernel and performance restrictions, and they are not hosted on a supported hypervisor, the configuration and performance details must be collected using custom tools/scripts and imported manually into AWS Migration Hub using the import CSV template.

This avoids violating security and compatibility requirements.

Determine the discovery mechanism for Hyper-V virtual machines to capture performance metrics and process-level network dependencies.

Deploy the AWS Application Discovery Agentless Collector on Hyper-V hosts to collect configuration and performance metrics without agent overhead. For the database servers requiring process-level network dependency mapping, deploy the AWS Application Discovery Agent.

The Agentless Collector does not support process-level network dependency mapping, which requires the local agent.

Address network security and outbound SSL/TLS inspection requirements for the deployed agents.

Configure the AWS Application Discovery Agents to trust the outbound proxy by importing the proxy's root CA certificate into the trusted certificate store of the VM operating systems.

The Discovery Agent communicates via outbound HTTPS. Without trusting the SSL-inspecting proxy's CA, HTTPS certificate verification will fail, preventing discovery data transmission.

Consolidate and track all discovery and migration status data.

Imported CSV data, Agentless Collector metadata, and Agent-based dependency data will all be consolidated and visible within the centralized AWS Migration Hub dashboard.

AWS Migration Hub integrates natively with both the Agent and Agentless Collector, as well as imported CSV discovery records.

Key Concept

AWS Application Discovery Service supports agentless discovery for VMware and Hyper-V environments for system specifications and performance metrics. However, process-level network dependency mapping requires the installation of the AWS Application Discovery Agent. Physical bare-metal environments or machines with unsupported configurations must utilize CSV imports. When security controls enforce SSL/TLS inspection on outbound proxies, the agent's OS must be updated to trust the proxy's root CA certificate to avoid SSL validation failure.

Question 1629Question →

A global pharmaceutical corporation is migrating its legacy laboratory database and research servers from an on-premises VMware environment to AWS using AWS Application Migration Service (MGN). The migration network path must be completely private, utilizing an existing $10\text{ Gbps}$ AWS Direct Connect connection that terminates at an AWS Transit Gateway. The Transit Gateway routes traffic to a dedicated staging VPC and a production VPC. The replication traffic must not traverse the public internet. Which of the following configurations must be implemented to establish successful private data replication? (Select TWO.)

Select all that apply

Configure the security group of the AWS MGN replication servers in the staging VPC to allow inbound traffic on TCP port

1500

from the on-premises source IP range, and configure the on-premises network firewall to allow outbound traffic on TCP port

1500

to the staging VPC CIDR.

Create VPC interface endpoints for AWS MGN in the staging VPC, associate the corresponding Amazon Route 53 private hosted zone with the staging VPC, and deploy an inbound Route 53 Resolver endpoint to resolve the service endpoints from the on-premises network.

Configure the staging VPC security groups to allow inbound traffic on TCP port

443

and TCP port

1500

from the staging VPC to the on-premises network, and configure the on-premises firewall to allow inbound traffic on TCP port

1500

from the replication servers.

Establish a Direct Connect Gateway directly associated with the virtual private gateway of the staging VPC to enable transitive routing, bypassing the Transit Gateway to minimize network hops during replication.

Deploy Route 53 Private Hosted Zones for the MGN interface endpoints in the production VPC without associating them with the staging VPC, and configure the on-premises DNS servers to forward requests to default AWS public DNS servers.

Show answer & explanation

Answer: Configure the security group of the AWS MGN replication servers in the staging VPC to allow inbound traffic on TCP port $1500$ from the on-premises source IP range, and configure the on-premises network firewall to allow outbound traffic on TCP port $1500$ to the staging VPC CIDR.; Create VPC interface endpoints for AWS MGN in the staging VPC, associate the corresponding Amazon Route 53 private hosted zone with the staging VPC, and deploy an inbound Route 53 Resolver endpoint to resolve the service endpoints from the on-premises network.

Answer

Successful private replication using AWS Application Migration Service (MGN) over Direct Connect requires configuring security groups and firewalls to allow inbound TCP port

1500

traffic into the staging VPC from the on-premises CIDR (with outbound TCP port

1500

allowed on-premises), and establishing VPC interface endpoints for MGN in the staging VPC, complete with Route 53 private hosted zone association and an inbound Route 53 Resolver endpoint to allow the on-premises source servers to resolve MGN endpoints privately.

Establishing a successful private infrastructure migration using AWS Application Migration Service requires allowing outbound data replication traffic on TCP port

1500

from the source servers to the staging VPC replication servers, and allowing it inbound on the replication servers' security group. Additionally, because the architecture requires private endpoint communication without internet access, VPC interface endpoints for MGN must be deployed in the staging VPC. These endpoints require a Route 53 Private Hosted Zone associated with the staging VPC, and an inbound Route 53 Resolver endpoint must be configured to handle DNS resolution requests forwarded from the on-premises DNS servers.

Step-by-Step Solution

Configure the network data plane path for data replication.

Ensure TCP port

1500

is allowed outbound from the on-premises source servers and inbound on the replication servers within the staging VPC security groups.

Replication servers (lightweight EC2 instances) launched in the staging area act as endpoints for receiving block-level data from the MGN replication agent over TCP port

1500

Configure private control plane communication.

Create interface VPC endpoints (AWS PrivateLink) for the MGN service in the staging VPC.

This allows the replication agent and replication servers to communicate with the MGN service control plane privately without traversing the public internet.

Establish hybrid DNS resolution for the private endpoints.

Associate the Route 53 Private Hosted Zone for the MGN VPC endpoints with the staging VPC, and deploy an inbound Route 53 Resolver endpoint.

On-premises source servers need to resolve the public MGN service domain names to the private IP addresses of the VPC interface endpoints. The inbound resolver endpoint acts as a DNS target for on-premises DNS forwarders.

Key Concept

Private replication with AWS Application Migration Service (MGN) requires both control plane connectivity (via VPC interface endpoints and hybrid DNS resolution) and data plane connectivity (via TCP port

1500

routing over VPN or Direct Connect).

Question 1630Question →

NovaTrade Brokerage is modernizing its legacy transaction clearing system by migrating it from on-premises servers to AWS. The workload consists of multiple microservices that must run on AWS Fargate to minimize operational overhead. The microservices must securely communicate with each other using internal DNS names within a multi-VPC environment spanning two AWS accounts: Account A (a shared services account) and Account B (the application workload account). The workload VPC in Account B spans three Availability Zones and hosts the containers in private subnets. The microservices must also securely call external payment APIs over the internet. Additionally, to comply with financial audits, all container logs must be encrypted in Amazon CloudWatch Logs using a Customer Managed Key (CMK) in AWS KMS.

Which architectural design meets these requirements while ensuring high availability for outbound traffic?

Deploy the microservices on AWS Fargate using the bridge network mode to enable dynamic host port mapping. In the workload VPC, deploy a NAT Gateway in a public subnet in each of the three Availability Zones, routing outbound internet traffic from the private subnets to their respective local NAT Gateway. Create a Route 53 Private Hosted Zone in Account A, authorize and associate it with the workload VPC in Account B. Configure CloudWatch Logs with a Customer Managed Key (CMK), granting permissions to the CloudWatch Logs service principal in the key policy.

Deploy the microservices on AWS Fargate using the awsvpc network mode. In the workload VPC, deploy a NAT Gateway in a public subnet in each of the three Availability Zones, routing outbound internet traffic from the private subnets to their respective local NAT Gateway. Create a Route 53 Private Hosted Zone in Account A, authorize and associate it with the workload VPC in Account B. Configure CloudWatch Logs with a Customer Managed Key (CMK), granting permissions to the CloudWatch Logs service principal in the key policy.

Deploy the microservices on AWS Fargate using the awsvpc network mode. In the workload VPC, deploy a NAT Gateway in a public subnet in each of the three Availability Zones, routing outbound internet traffic from the private subnets to their respective local NAT Gateway. Create a Route 53 Private Hosted Zone in Account A, assuming it is automatically accessible by all VPCs within the AWS Organization without explicit cross-account association. Configure CloudWatch Logs with a Customer Managed Key (CMK), granting permissions to the CloudWatch Logs service principal in the key policy.

Deploy the microservices on AWS Fargate using the awsvpc network mode. In the workload VPC, deploy a single NAT Gateway in a public subnet within one Availability Zone, routing outbound internet traffic from all private subnets across all three Availability Zones to this single NAT Gateway. Create a Route 53 Private Hosted Zone in Account A, authorize and associate it with the workload VPC in Account B. Configure CloudWatch Logs with a Customer Managed Key (CMK), granting permissions to the CloudWatch Logs service principal in the key policy.

Show answer & explanation

Answer: Deploy the microservices on AWS Fargate using the awsvpc network mode. In the workload VPC, deploy a NAT Gateway in a public subnet in each of the three Availability Zones, routing outbound internet traffic from the private subnets to their respective local NAT Gateway. Create a Route 53 Private Hosted Zone in Account A, authorize and associate it with the workload VPC in Account B. Configure CloudWatch Logs with a Customer Managed Key (CMK), granting permissions to the CloudWatch Logs service principal in the key policy.

Answer

Deploying the microservices on AWS Fargate in the awsvpc network mode, deploying redundant NAT Gateways across all three Availability Zones, configuring a cross-account Route 53 Private Hosted Zone association, and encrypting CloudWatch Logs with a Customer Managed Key.

The correct architectural design involves deploying the microservices on AWS Fargate using the awsvpc network mode, since AWS Fargate does not support other modes. To ensure high availability and prevent a single point of failure, a separate NAT Gateway must be deployed in a public subnet in each of the three Availability Zones. To resolve DNS names across the two AWS accounts, the Route 53 Private Hosted Zone in Account A must be explicitly associated with the workload VPC in Account B. Finally, to encrypt CloudWatch Logs with a Customer Managed Key, the KMS key policy must explicitly allow the CloudWatch Logs service principal to access the key.

Step-by-Step Solution

Determine container networking mode on AWS Fargate

Identify that only the awsvpc network mode is supported by AWS Fargate, which allocates an Elastic Network Interface (ENI) to each task.

Choosing the bridge network mode will cause deployment failure on Fargate.

Configure high availability for outbound internet connectivity

Deploy three NAT Gateways (one per Availability Zone) in the public subnets and update the private subnet route tables to target the local NAT Gateway in the same zone.

A single NAT Gateway creates a single point of failure if that specific Availability Zone goes down, failing the high availability requirement.

Configure cross-account internal DNS resolution

Create a Route 53 Private Hosted Zone in Account A, authorize the VPC in Account B to associate with it, and then accept the association from Account B.

Private Hosted Zones are private to the associated VPCs and do not cross account boundaries automatically without explicit association.

Configure log encryption with a Customer Managed Key

Create a KMS Customer Managed Key, configure a key policy allowing the CloudWatch Logs service principal to perform encrypt/decrypt actions, and associate the key with the log group.

AWS-managed keys (like aws/logs) cannot have their policies modified to allow cross-account or service-specific custom grants, necessitating a Customer Managed Key.

Key Concept

Modernizing legacy workloads using Amazon ECS on AWS Fargate requires understanding network limitations (awsvpc only), multi-account DNS integration via cross-account Route 53 Private Hosted Zone associations, high availability outbound routing using redundant NAT Gateways, and compliance logging using KMS Customer Managed Keys.

Estimated Time:3m 0s

Question 1631Question →

A Solutions Architect is designing a heterogeneous migration of a highly transactional, 3 TB on-premises Oracle database to an Amazon Aurora PostgreSQL-Compatible Edition DB cluster. The source database contains complex schemas with deep foreign key hierarchies, triggers, and numerous secondary indexes. The migration must minimize source database performance impact, achieve minimal downtime during cutover, and optimize the initial data load speed while ensuring target data integrity and consistency during replication. Which combination of steps should the Solutions Architect take to meet these requirements?

Enable supplemental logging on the source Oracle database. Use AWS SCT to generate the target DDL, separating table and primary key definitions from secondary indexes, foreign keys, and triggers. Apply only the table and primary key definitions to the target. Create a DMS Full Load task and a separate DMS CDC task. Run the Full Load task with target table preparation mode set to Do Nothing. After completion, apply the remaining indexes, foreign keys, and triggers to the target, then start the CDC task from the Full Load start time.

Use AWS SCT to convert the schema and apply it to the target. Create a single DMS Full Load and CDC task with target table preparation mode set to Do Nothing. Start the task immediately without modifying the logging configuration on the source Oracle database, and allow DMS to automatically handle the initial data load and transition to continuous replication.

Enable supplemental logging on the source Oracle database. Use AWS SCT to convert the schema. Create a single DMS Full Load and CDC task with target table preparation mode set to Drop and Create. Run the task to let DMS automatically handle target table creation, index management, and continuous replication, and then use AWS SCT to re-apply stored procedures and triggers after the task enters the replication phase.

Use Oracle Data Guard to establish continuous replication from the on-premises database directly to the target Aurora PostgreSQL DB cluster, classifying the migration as a replatforming path to avoid schema conversion overhead and minimize cutover downtime.

Show answer & explanation

Answer: Enable supplemental logging on the source Oracle database. Use AWS SCT to generate the target DDL, separating table and primary key definitions from secondary indexes, foreign keys, and triggers. Apply only the table and primary key definitions to the target. Create a DMS Full Load task and a separate DMS CDC task. Run the Full Load task with target table preparation mode set to Do Nothing. After completion, apply the remaining indexes, foreign keys, and triggers to the target, then start the CDC task from the Full Load start time.

Answer

Enable supplemental logging on the source Oracle database, use AWS Schema Conversion Tool (SCT) to separate tables/primary keys from constraints/indexes, load data using a separate AWS Database Migration Service (DMS) Full Load task with Do Nothing mode, apply indexes and constraints, and then run a separate DMS Change Data Capture (CDC) task from the Full Load start time.

The correct sequence of actions enables supplemental logging on the source Oracle database to allow Change Data Capture (CDC). Using AWS Schema Conversion Tool (SCT) to separate table/primary key definitions from secondary indexes, foreign keys, and triggers, and applying only the tables/primary keys initially, optimizes the performance of the AWS Database Migration Service (DMS) Full Load task. Running separate Full Load and CDC tasks prevents DMS from automatically moving to replication before constraints and secondary indexes are applied. Applying the remaining indexes, foreign keys, and triggers after the full load completes ensures rapid index creation and data integrity validation. Starting the CDC task from the Full Load start time guarantees that no transactions are missed during the data migration process.

Step-by-Step Solution

Configure the source database logging

Supplemental logging is enabled on the source Oracle database.

AWS DMS Change Data Capture (CDC) requires supplemental logging to be enabled on Oracle to capture the full row changes in the redo logs.

Convert and separate schema DDL using AWS SCT

Target schema DDL is generated and split into table structures (with primary keys) and secondary structures (indexes, foreign keys, triggers).

Applying only tables and primary keys before the full load prevents the performance overhead of updating indexes and validating constraints for every inserted row.

Run DMS Full Load task

Initial dataset is loaded into the target Aurora PostgreSQL database with target table preparation mode set to Do Nothing.

Setting the mode to Do Nothing ensures that the pre-created schema structures from AWS SCT are preserved during the bulk load.

Apply secondary schema objects and start CDC

Secondary indexes, foreign keys, and triggers are created on the target, and the DMS CDC task is started from the Full Load start timestamp.

Applying indexes after the bulk load is significantly faster. Starting CDC from the Full Load start time ensures no transactional changes are lost during the load period.

Key Concept

Heterogeneous database migration lifecycle optimization using AWS SCT and AWS DMS

Question 1632Question →

NovaCare Telehealth is modernizing its HIPAA-compliant patient-record processing service by migrating its on-premises microservices to AWS. The target architecture must run on Amazon ECS using the AWS Fargate launch type to minimize operational overhead. The containers must run in a private VPC with no internet access. The application needs to securely retrieve database credentials and API keys stored in AWS Systems Manager Parameter Store. These parameters are encrypted using a customer managed key (CMK) in AWS Key Management Service (AWS KMS) located in a centralized security account. All AWS service traffic must traverse private VPC endpoints. Which solution configuration meets these security and compliance requirements with the least operational overhead?

Deploy the Amazon ECS tasks using the AWS Fargate launch type with the bridge network mode. Create interface VPC endpoints for Systems Manager Parameter Store and AWS KMS in the application VPC. Grant the ECS task execution role permissions to decrypt the customer managed key in the security account and read the parameters.

Deploy the Amazon ECS tasks using the AWS Fargate launch type with the awsvpc network mode. Create interface VPC endpoints for Systems Manager Parameter Store and AWS KMS in the application VPC. Configure the Parameter Store parameters to use the AWS-managed KMS key in the centralized security account, and grant the ECS task execution role permissions to decrypt the parameters.

Deploy the Amazon ECS tasks using the AWS Fargate launch type with the awsvpc network mode. Create interface VPC endpoints for Systems Manager Parameter Store and AWS KMS in the application VPC. Grant the ECS task execution role permissions to decrypt the customer managed key in the security account and read the parameters.

Deploy the Amazon ECS tasks using the AWS Fargate launch type with the awsvpc network mode. Create interface VPC endpoints for Systems Manager Parameter Store and AWS KMS in a shared services VPC. Configure a Route 53 private hosted zone in the shared services VPC to resolve endpoint DNS names, without associating the private hosted zone with the application VPC.

Show answer & explanation

Answer: Deploy the Amazon ECS tasks using the AWS Fargate launch type with the awsvpc network mode. Create interface VPC endpoints for Systems Manager Parameter Store and AWS KMS in the application VPC. Grant the ECS task execution role permissions to decrypt the customer managed key in the security account and read the parameters.

Answer

Deploy the Amazon ECS tasks using the AWS Fargate launch type with the awsvpc network mode, create interface VPC endpoints locally in the application VPC, and grant the ECS task execution role permissions to decrypt the customer managed key in the security account and read the parameters.

The correct solution correctly specifies the awsvpc network mode, which is mandatory for AWS Fargate. It sets up interface VPC endpoints locally in the isolated application VPC to facilitate private connectivity to Systems Manager and KMS. Since the KMS key resides in a separate centralized security account, a customer managed key is used, as it is the only key type that allows cross-account permissions. Finally, permissions are granted to the ECS task execution role, which is the role responsible for fetching secrets and parameter values during container startup.

Step-by-Step Solution

Select the correct network mode for AWS Fargate.

The tasks must be configured to use the awsvpc network mode.

AWS Fargate does not support bridge or host network modes; it exclusively requires the awsvpc network mode.

Establish secure private connectivity to AWS services.

Create interface VPC endpoints (AWS PrivateLink) for Systems Manager Parameter Store and AWS KMS in the application VPC.

Because the VPC lacks internet access, interface VPC endpoints are required to privately route requests to Parameter Store and KMS.

Configure cross-account KMS decryption permissions.

Use a customer managed key (CMK) in the security account and modify its key policy to allow the application's ECS task execution role to perform kms:Decrypt operations.

AWS-managed keys (like aws/ssm) cannot be modified to delegate access to external AWS accounts. A customer managed key is necessary for cross-account decryption.

Key Concept

Deploying containerized workloads on AWS Fargate requires the awsvpc network mode. Accessing services from a fully isolated VPC requires interface VPC endpoints, and cross-account KMS access requires customer managed keys.

Estimated Time:2m 30s

Question 1633Question →

A company is migrating its customer-facing booking application to a serverless architecture using Amazon API Gateway and AWS Lambda. The backend Lambda function integrates with a legacy third-party inventory database that can only support a maximum of 30 concurrent database connections. During peak hours, traffic spikes cause the database to crash due to too many simultaneous connections from the Lambda function. Which configuration should the solutions architect implement to limit the concurrent executions of the Lambda function to a maximum of 30?

Configure reserved concurrency with a limit of 30 on the Lambda function.

Configure provisioned concurrency with a value of 30 on the Lambda function.

Configure a canary deployment in Amazon API Gateway to limit traffic to 30% of peak capacity.

Set up an AWS KMS customer managed key to encrypt the Lambda environment variables and limit concurrent decryptions to 30.

Show answer & explanation

Answer: Configure reserved concurrency with a limit of 30 on the Lambda function.

Answer

Configure reserved concurrency with a limit of 30 on the Lambda function.

Configuring reserved concurrency on the Lambda function sets a strict maximum limit on the number of concurrent executions. This ensures that the function will never open more than 30 connections to the legacy database, preventing it from crashing during high traffic periods.

Step-by-Step Solution

Identify the primary scaling constraint of the architecture.

The legacy downstream inventory database has a strict threshold of 30 concurrent connections.

We must restrict the backend Lambda function from scaling beyond 30 concurrent executions to prevent database exhaustion.

Evaluate the difference between reserved concurrency and provisioned concurrency in AWS Lambda.

Reserved concurrency acts as both a reservation and a hard limit on the function's maximum concurrency. Provisioned concurrency only prepares execution environments in advance and does not cap maximum concurrency.

Only reserved concurrency satisfies the requirement of capping the maximum number of concurrent executions to protect downstream resources.

Select the correct configuration parameter.

Setting the reserved concurrency configuration value to 30 on the Lambda function.

This guarantees that any invocation requests beyond 30 concurrent executions will be throttled, maintaining database stability.

Key Concept

AWS Lambda Reserved Concurrency

Question 1634Question →

A financial technology startup is designing a new transaction auditing system (OLTP and Object storage workloads) that must span two AWS accounts: a Production account and a dedicated Security account. The architecture must satisfy the following requirements:

* For the OLTP database, support dynamic read scaling to handle unpredictable query spikes, and implement a cross-region disaster recovery (DR) strategy with a Recovery Point Objective (RPO) of under 1 minute and a Recovery Time Objective (RTO) of under 5 minutes.
* For object storage, centralize AWS CloudTrail logs from the Production account into an Amazon S3 bucket in the Security account.

Which database and storage design meets these requirements?

Deploy an Amazon Aurora Global Database with the primary cluster in the active region and a secondary cluster in the recovery region. Configure Aurora Auto Scaling for the primary cluster's reader instances to handle query spikes. In the Security account, configure an S3 bucket with a bucket policy that grants permission to the CloudTrail service principal (cloudtrail.amazonaws.com) to perform s3:PutObject operations, and enable CloudTrail in the Production account to write logs to this bucket.

Deploy an Amazon RDS for PostgreSQL database with a Multi-AZ deployment in the primary region, and configure the application to route read queries to the standby replica during traffic spikes. Set up AWS Backup copy jobs to replicate database snapshots to the recovery region. In the Security account, configure the S3 bucket policy to allow the Production account's root user to manage CloudTrail logging.

Deploy a single-region Amazon Aurora PostgreSQL database with Aurora Replicas and Auto Scaling. Meet the disaster recovery requirements by implementing a Pilot Light strategy that replicates S3-based database backups to the recovery region and spins up a minimal database instance only during failover events. In the Security account, encrypt the S3 bucket using the default AWS-managed KMS key (aws/s3) and configure its key policy to allow cross-account access from the Production account.

Deploy an Amazon Aurora Global Database with the primary cluster in the active region and a secondary cluster in the recovery region. In the Security account, configure the centralized S3 bucket for CloudTrail logs but omit the CloudTrail service principal from the bucket policy, relying on an IAM policy in the Production account to grant cross-account write permissions. Configure a read replica in the secondary region and manually promote it during a failover event.

Show answer & explanation

Answer: Deploy an Amazon Aurora Global Database with the primary cluster in the active region and a secondary cluster in the recovery region. Configure Aurora Auto Scaling for the primary cluster's reader instances to handle query spikes. In the Security account, configure an S3 bucket with a bucket policy that grants permission to the CloudTrail service principal (cloudtrail.amazonaws.com) to perform s3:PutObject operations, and enable CloudTrail in the Production account to write logs to this bucket.

Answer

Deploy an Amazon Aurora Global Database with replica auto-scaling for read performance and cross-region DR, and configure the S3 bucket policy in the Security account to grant s3:PutObject permissions to the CloudTrail service principal.

Deploying an Amazon Aurora Global Database provides local read scaling via Aurora Replicas and handles cross-region disaster recovery with sub-minute RPO. Configuring the S3 bucket policy in the Security account to grant access to the CloudTrail service principal is the required way to enable secure cross-account log collection.

Step-by-Step Solution

Evaluate the OLTP database scalability and disaster recovery (DR) requirements.

Identify that Amazon Aurora Global Database provides the necessary cross-region replication latency (seconds) to meet the RPO < 1 minute and RTO < 5 minutes requirements, while Aurora Auto Scaling can dynamically add read replicas to handle spike loads.

RDS Multi-AZ standby instances are offline and cannot serve reads, and backup-based copy methods fail to meet the low RTO/RPO targets.

Evaluate the S3 bucket policy requirements for cross-account logging.

Determine that the S3 bucket policy in the Security account must explicitly trust the CloudTrail service principal (cloudtrail.amazonaws.com) to perform s3:PutObject operations.

CloudTrail is a service principal that writes logs directly to the target bucket. Relying on client IAM policies is insufficient for cross-account ingestion because the service requires direct bucket-level authorization.

Analyze KMS key and encryption constraints for cross-account S3 buckets.

Determine that default AWS-managed KMS keys (such as aws/s3) cannot be shared across AWS accounts because their key policies cannot be modified.

Cross-account decryption or write access requires customer managed keys (CMKs) with custom key policies that explicitly delegate access to external account identities.

Key Concept

Designing database and storage solutions that support read scaling, cross-region DR RTO/RPO targets, and cross-account S3 logging constraints.

Estimated Time:2m 0s

Question 1635Question →

A global digital advertising agency is designing a new real-time campaign telemetry store (NoSQL workload) and a creative asset repository (Object storage workload) across two AWS Regions: `us-east-1` (primary) and `us-west-2` (disaster recovery). The disaster recovery region is managed under a separate AWS account within the same AWS Organization.

The telemetry store must support active-active writes in both regions with sub-second replication latency, handle semi-structured data, and scale automatically to handle millions of requests per second. The creative asset repository must store large media files with $99.999999999\%$ durability, replicate assets from `us-east-1` to `us-west-2` automatically, and meet a Recovery Point Objective (RPO) of 15 minutes. All data must be encrypted at rest using Customer Managed Keys (CMKs) to support key rotation and fine-grained access audits.

Which two database and storage strategy options should the solutions architect choose to meet these requirements? (Select TWO.)

Select all that apply

Deploy Amazon DynamoDB global tables in `us-east-1` and `us-west-2`, encrypted using customer managed keys (CMKs) created in each region, to handle the campaign telemetry workload.

Configure Amazon S3 Cross-Region Replication (CRR) from the primary bucket in `us-east-1` to a destination bucket in `us-west-2` in the secondary account. Encrypt the source bucket using a customer managed key (CMK) in `us-east-1`, and encrypt the destination bucket using a customer managed key (CMK) in `us-west-2`. Grant the replication IAM role permissions to decrypt with the source CMK and encrypt with the destination CMK.

Deploy Amazon Aurora PostgreSQL with global databases. Configure the primary cluster in `us-east-1` and an Aurora replica in `us-west-2`. Enable Aurora Auto Scaling on both the primary and replica clusters to handle dynamic, active-active write workloads in both regions.

Configure Amazon S3 Cross-Region Replication (CRR) from the primary bucket in `us-east-1` to a destination bucket in `us-west-2` in the secondary account. Encrypt both S3 buckets using the default AWS-managed KMS key (`aws/s3`), and configure the replication IAM role to assume a cross-account IAM role to perform replication.

Store the creative assets in an Amazon S3 bucket in `us-east-1`. Create a daily AWS Backup plan to copy the S3 recovery points to a backup vault in the secondary account in `us-west-2` to meet the RPO and cross-account isolation requirements.

Show answer & explanation

Answer: Deploy Amazon DynamoDB global tables in `us-east-1` and `us-west-2`, encrypted using customer managed keys (CMKs) created in each region, to handle the campaign telemetry workload.; Configure Amazon S3 Cross-Region Replication (CRR) from the primary bucket in `us-east-1` to a destination bucket in `us-west-2` in the secondary account. Encrypt the source bucket using a customer managed key (CMK) in `us-east-1`, and encrypt the destination bucket using a customer managed key (CMK) in `us-west-2`. Grant the replication IAM role permissions to decrypt with the source CMK and encrypt with the destination CMK.

Answer

To satisfy the requirements, the campaign telemetry store should be built on Amazon DynamoDB global tables with customer managed keys in each region, and the creative asset repository should use cross-account Amazon S3 Cross-Region Replication (CRR) with customer managed KMS keys in both regions.

Deploying DynamoDB global tables fulfills the telemetry workload requirements, as it provides a fully managed multi-master NoSQL solution with sub-second replication latency across regions. For the asset repository, configuring S3 Cross-Region Replication (CRR) using customer managed keys (CMKs) in both the source and destination regions satisfies both the 15-minute RPO and the encryption constraints. Because S3 cross-account replication requires the replication role to decrypt in the source account and encrypt in the destination account, CMKs are required since their policies can be updated to delegate cross-account usage permissions.

Step-by-Step Solution

Determine the database model and replication design for the campaign telemetry store.

Select Amazon DynamoDB global tables because the workload requires NoSQL capabilities, dynamic schema, multi-region active-active writes with sub-second replication latency, and high scalability.

Amazon DynamoDB global tables provide multi-master replication across AWS regions, enabling low-latency read and write performance globally.

Determine the replication strategy for the creative asset object storage.

Select Amazon S3 Cross-Region Replication (CRR) to replicate objects asynchronously from `us-east-1` to the disaster recovery bucket in `us-west-2` within the secondary account.

S3 CRR provides automatic, continuous replication to satisfy RPO requirements under 15 minutes, whereas backup schedules are typically daily or hourly.

Evaluate the encryption key requirements for cross-account replication of KMS-encrypted objects.

Select Customer Managed Keys (CMKs) in both the source and destination regions, updating the key policies to permit the source replication role to decrypt the source objects and encrypt the destination objects.

AWS-managed keys (like `aws/s3`) cannot be used for cross-account replication because their key policies are locked and cannot grant cross-account permissions.

Key Concept

Designing multi-region database and object storage architectures with cross-account replication and key policy delegation using KMS customer managed keys.

Question 1636Question →

An energy utility company is migrating $15$ physical on-premises servers hosting critical control systems to AWS using AWS Application Migration Service (MGN). Due to regulatory compliance, all replication traffic must remain private and must not traverse the public internet. A $2\text{ Gbps}$ AWS Direct Connect connection is established between the on-premises data center and an AWS Transit Gateway in a shared services account. The Transit Gateway routes traffic to a dedicated Migration VPC where the staging area subnet is located. The AWS MGN Replication Agent will be installed on each on-premises server. Which network and service configuration must be implemented to ensure that the replication traffic is kept entirely private and replication completes successfully?

Configure the AWS MGN Replication Template to use private IP routing. Create Interface VPC Endpoints for the AWS MGN service inside the Staging VPC, and configure the on-premises DNS to resolve the MGN service endpoints to these private IPs. Allow inbound traffic on TCP port 1500 to the staging area subnets from the on-premises network, and allow outbound traffic on TCP port 443 from the source servers to the MGN Interface VPC Endpoints.

Configure the AWS MGN Replication Template to use private IP routing. Create Interface VPC Endpoints for the AWS MGN service inside the Staging VPC. To ensure maximum security, configure the Staging VPC security groups to allow inbound traffic on TCP port 443 from the on-premises network, but block all other inbound traffic including TCP port 1500 to prevent unauthorized block-level data access.

Configure the AWS MGN Replication Template to use public IP routing. Establish a Public Virtual Interface (VIF) on the Direct Connect connection to route replication traffic to the public endpoints of AWS MGN, and configure a NAT Gateway in the Staging VPC to route return traffic from the replication servers back to the on-premises network.

Configure the AWS MGN Replication Template to use private IP routing. Create Interface VPC Endpoints for the AWS MGN service in a shared services VPC associated with a Route 53 Private Hosted Zone for the service endpoints, but do not associate this Private Hosted Zone with the Staging VPC to avoid overlapping DNS resolution conflicts with the on-premises domain controllers.

Show answer & explanation

Answer: Configure the AWS MGN Replication Template to use private IP routing. Create Interface VPC Endpoints for the AWS MGN service inside the Staging VPC, and configure the on-premises DNS to resolve the MGN service endpoints to these private IPs. Allow inbound traffic on TCP port 1500 to the staging area subnets from the on-premises network, and allow outbound traffic on TCP port 443 from the source servers to the MGN Interface VPC Endpoints.

Answer

Configure the AWS MGN Replication Template to use private IP routing, create Interface VPC Endpoints in the Staging VPC, configure on-premises DNS to resolve MGN endpoints to these private IPs, allow inbound TCP port 1500 from the on-premises network to the staging subnets, and allow TCP port 443 outbound from the source servers to the interface endpoints.

The correct configuration establishes private IP routing in the AWS MGN Replication Template, deploy Interface VPC Endpoints for MGN in the Staging VPC, and maps DNS correctly. It also ensures both required ports (TCP 443 for control plane API calls and TCP 1500 for replication data transfer) are open in firewalls and security groups.

Step-by-Step Solution

Select private IP routing in the AWS MGN Replication Template.

Instructs the MGN replication servers and agents to route data replication traffic over the private Direct Connect link rather than using public IPs.

This complies with the security requirement to keep replication traffic off the public internet.

Create VPC Interface Endpoints for the MGN service in the Staging VPC.

Provides private IP addresses in the Staging VPC that map to the AWS MGN control plane.

Allows agents and replication servers to communicate with the AWS MGN control plane without requiring internet access.

Configure DNS and firewall rules to allow TCP ports 443 and 1500.

Ensures the replication agent can reach the control plane over port 443 and stream data blocks to the replication servers over port 1500.

Replication fails if the agent cannot establish the control connection (port 443) or the data replication stream (port 1500).

Key Concept

Private replication with AWS Application Migration Service (MGN) over VPN or Direct Connect requires configuring private IP routing in the replication template, creating VPC Interface Endpoints for control traffic (port 443), and opening port 1500 for data replication.

Question 1637Question →

A global shipping and logistics enterprise is preparing to migrate its supply chain management platform to AWS. The on-premises environment consists of a mix of VMware vSphere virtual machines and physical bare-metal servers running Red Hat Enterprise Linux and Windows Server. The enterprise security policy prohibits any direct outbound internet access from the on-premises datacenter. All outbound traffic must go through an on-premises HTTP proxy that performs SSL decryption and inspection. To plan the migration, the solutions architect must collect detailed CPU and memory utilization, active running processes, and network dependencies (source/destination IPs and ports) for all servers. The migration tracking dashboard must consolidate status updates from both AWS migration services and integrated third-party migration tools. Which strategy should the solutions architect implement to perform the discovery and track the migration?

Deploy the AWS Application Discovery Agent on all physical servers and virtual machines. Configure the agents to communicate through the on-premises HTTP proxy, and register the agents with AWS Application Discovery Service. Enable data collection, and use the AWS Migration Hub console to track the status of both AWS migration tools and integrated third-party migration tools.

Deploy the AWS Application Discovery Agentless Collector as a virtual appliance in the VMware vCenter environment. Configure the collector to route traffic through the on-premises HTTP proxy to gather hardware specifications, CPU/memory utilization, process lists, and network connection details for all servers, then track the migration status in AWS Migration Hub.

Deploy the AWS Application Migration Service (MGN) replication agent on all servers to perform initial discovery and map network dependencies. Configure the agents to route traffic through the HTTP proxy over TCP port 1500 to send performance and dependency data to the AWS Migration Hub dashboard, and integrate third-party tools using the MGN API.

Import the server inventory details into AWS Migration Hub using a CSV import template. Deploy the AWS Systems Manager (SSM) Agent on all servers to collect running processes and network dependencies, and configure SSM Inventory to stream this data through the on-premises HTTP proxy directly to the AWS Migration Hub dashboard.

Show answer & explanation

Answer: Deploy the AWS Application Discovery Agent on all physical servers and virtual machines. Configure the agents to communicate through the on-premises HTTP proxy, and register the agents with AWS Application Discovery Service. Enable data collection, and use the AWS Migration Hub console to track the status of both AWS migration tools and integrated third-party migration tools.

Answer

Deploy the AWS Application Discovery Agent on all physical servers and virtual machines, configure the agents to use the HTTP proxy, enable data collection under AWS Application Discovery Service, and track the migration status of both AWS and third-party tools in AWS Migration Hub.

The correct strategy involves deploying the AWS Application Discovery Agent on all physical and virtual servers. This agent runs inside the operating system, allowing it to collect system performance metrics, active processes, and network dependencies (source/destination IPs and ports) regardless of the hypervisor. It also natively supports routing its outbound HTTPS communication through an on-premises HTTP/HTTPS proxy. Finally, AWS Migration Hub acts as a single pane of glass to track the migration progress of both AWS tools and integrated third-party migration tools.

Step-by-Step Solution

Analyze environment and collection requirements.

The target environment contains physical bare-metal servers, and the architect must collect OS-level network dependencies and active running processes.

Since the environment has physical servers and requires OS-level process and network connection mapping, the AWS Application Discovery Agentless Collector cannot be used (as it is VMware-only and doesn't collect process or network dependencies). The Application Discovery Agent (agent-based) is required.

Configure egress connectivity for the agents.

Install the AWS Application Discovery Agent on each host and configure it with the proxy settings (e.g., HTTP_PROXY/HTTPS_PROXY) to communicate with AWS endpoints through the local proxy.

The local datacenter prohibits direct outbound internet access and mandates HTTP proxy routing with SSL inspection. The agents support proxy configuration to securely transmit metadata to AWS.

Consolidate and track migration progress in AWS Migration Hub.

Integrate third-party migration tools with the AWS Migration Hub API and use the unified dashboard to monitor migration state.

AWS Migration Hub is designed to act as a central portfolio and migration tracking dashboard, aggregating data from discovery agents and supporting tracking for both native AWS migration tools and registered third-party software.

Key Concept

AWS Application Discovery Agent vs. Agentless Collector Trade-offs and Migration Hub Tracking Integration

Question 1638Question →

A gaming studio is migrating its legacy multiplayer game servers from an on-premises data center to AWS using AWS Application Migration Service (MGN). The replication network path must be private, utilizing an existing $1\text{ Gbps}$ AWS Direct Connect connection with a private virtual interface (VIF) attached to an AWS Transit Gateway that connects to the migration VPC. During the initial testing phase, the AWS MGN Replication Agent is installed on the source servers, but the replication status remains stuck at 'Initiating' and no data is being copied to the staging area in AWS. A network engineer verifies that the source servers can resolve the necessary domain names and can reach the VPC endpoints in AWS, but the replication data blocks are not being received. Which of the following configuration changes will resolve this replication issue?

Update the security group of the staging area replication servers to permit incoming connections on TCP port 1500 from the on-premises IP address range, and configure the local firewall to permit outgoing traffic on the same port.

Reconfigure the Transit Gateway route table to establish a Direct Connect Gateway connection that bypasses the Transit Gateway routing, allowing direct peering between the on-premises data center and the staging VPC.

Link the Amazon Route 53 Private Hosted Zone created for the AWS MGN interface VPC endpoints to the staging VPC and authorize cross-account access for the on-premises DNS resolver.

Route all outbound traffic from the staging subnets through a single NAT Gateway located in a public subnet of the staging VPC to reach the AWS MGN service endpoints.

Show answer & explanation

Answer: Update the security group of the staging area replication servers to permit incoming connections on TCP port 1500 from the on-premises IP address range, and configure the local firewall to permit outgoing traffic on the same port.

Answer

The correct option resolves the replication initiation issue by opening TCP port 1500, which is the specific port used by the AWS MGN Replication Agent to stream replicated data blocks to the replication servers in the staging area VPC.

Step-by-Step Solution

Identify the network protocol and port requirements for AWS MGN data replication.

The AWS Replication Agent sends replication data blocks to the replication servers in the staging area over TCP port 1500.

AWS MGN uses TCP port 1500 for the secure transmission of replication data from the agent to the staging area.

Analyze the connectivity status and error symptoms.

Domain resolution and connection to VPC endpoints are successful, but data replication is stuck in 'Initiating', indicating that port 1500 is blocked.

Since control plane endpoints (VPC endpoints) are reachable, the network path is functional, but the data plane path (port 1500) is being filtered.

Formulate the correct configuration change to open TCP port 1500.

Permit TCP port 1500 inbound on the replication server security groups and outbound on the local firewall.

This allows the agent to establish a TCP session to the replication servers and stream data.

Key Concept

AWS Application Migration Service (MGN) uses TCP port 1500 for replication data transfer between the source replication agent and the staging replication servers.

Estimated Time:2m 0s

Question 1639Question →

A company manages a multi-account AWS environment using AWS Organizations. The DevOps team uses AWS CloudFormation StackSets to deploy and manage application infrastructure, including EC2 instances and security groups, across multiple target accounts. The CloudFormation templates are stored in an Amazon S3 bucket within the administrator account. Recently, manual changes made to the security groups in a target account caused subsequent StackSet updates to fail due to configuration drift. Additionally, the DevOps team is planning to encrypt the S3 bucket containing the templates and needs to ensure that StackSets can still deploy resources cross-account. Which of the following actions should the DevOps engineer take to address these requirements? (Select TWO.)

Select all that apply

Encrypt the Amazon S3 bucket containing the templates using a Customer Managed Key (CMK) in the administrator account, and configure the key policy to grant the StackSet execution role (AWSCloudFormationStackSetExecutionRole) in the target accounts permissions for the kms:Decrypt and kms:GenerateDataKey actions.

Configure the AWS Config rule cloudformation-stack-drift-detection-check in the target accounts, and set up an Amazon EventBridge rule that detects non-compliant drift events and triggers an AWS Systems Manager Automation runbook to remediate the drifted resources.

Encrypt the Amazon S3 bucket using the default AWS-managed KMS key for Amazon S3 (aws/s3) in the administrator account, and configure the S3 bucket policy to grant cross-account read access to the StackSet execution roles in the target accounts.

Attach a Service Control Policy (SCP) to the target Organizational Unit (OU) that explicitly grants kms:Decrypt and cloudformation:* permissions to automatically allow the target account roles to access templates and deploy resources.

Instruct administrators to manually modify the drifted resources back to their original state in the target accounts, and then use the AWS CLI to manually update the CloudFormation stack drift status to IN_SYNC.

Show answer & explanation

Answer: Encrypt the Amazon S3 bucket containing the templates using a Customer Managed Key (CMK) in the administrator account, and configure the key policy to grant the StackSet execution role (AWSCloudFormationStackSetExecutionRole) in the target accounts permissions for the kms:Decrypt and kms:GenerateDataKey actions.; Configure the AWS Config rule cloudformation-stack-drift-detection-check in the target accounts, and set up an Amazon EventBridge rule that detects non-compliant drift events and triggers an AWS Systems Manager Automation runbook to remediate the drifted resources.

Answer

The correct actions are to encrypt the S3 bucket using a Customer Managed Key (CMK) in the administrator account while granting cross-account KMS permissions to the StackSet execution role in the target accounts, and to configure the AWS Config stack drift detection rule combined with an Amazon EventBridge rule that triggers an AWS Systems Manager Automation runbook for remediation.

To support cross-account StackSet deployments from an encrypted S3 bucket, a Customer Managed Key (CMK) must be used because AWS-managed keys cannot be shared cross-account. The CMK's key policy must grant permissions to the execution role in the target accounts. Additionally, configuring AWS Config to detect CloudFormation stack drift and using EventBridge to trigger a Systems Manager Automation runbook provides a secure, automated way to detect and remediate configuration changes without manual intervention.

Step-by-Step Solution

Address the cross-account encryption requirement.

Identify that AWS-managed KMS keys cannot be shared cross-account. A Customer Managed Key (CMK) must be created in the administrator account, and its key policy must grant permissions to the cross-account role AWSCloudFormationStackSetExecutionRole.

This ensures the StackSets execution role in target accounts has permission to decrypt the CloudFormation templates stored in the encrypted S3 bucket.

Configure configuration drift detection and remediation.

Deploy the cloudformation-stack-drift-detection-check AWS Config rule in target accounts and configure an EventBridge rule that triggers an AWS Systems Manager Automation runbook upon drift detection.

This automates the detection of configuration changes and invokes the remediation process without manual CLI overrides or console interventions.

Evaluate and rule out incorrect options.

Discard the options proposing AWS-managed KMS keys (which cannot be shared cross-account), SCPs (which do not grant permissions directly), and manual CLI status overrides (which are unsupported).

This refines the choices to the two correct, scalable, and secure architecture patterns.

Key Concept

Automating cross-account infrastructure deployment using CloudFormation StackSets, managing configuration drift with AWS Config and Systems Manager, and configuring cross-account KMS permissions.

Question 1640Question →

A digital media publishing company stores and distributes high-resolution article images. The images are stored in an Amazon S3 bucket in the `us-east-1` Region. The company uploads approximately $40\text{ TB}$ of new images each month. Users globally download these images, resulting in $150\text{ TB}$ of Data Transfer Out (DTO) from S3 directly to the internet, creating high data transfer costs. The images are accessed frequently during the first $30$ days after publication. After $30$ days, the access frequency drops significantly, but users still expect the images to load in milliseconds when requested. After $180$ days, the images are rarely accessed but must be retained for $7$ years for compliance. For these archived images, a retrieval time of up to $12$ hours is acceptable. Which two actions should the solutions architect take to meet these requirements most cost-effectively? (Select two.)

Select all that apply

Configure an Amazon S3 Lifecycle policy to transition the images to S3 Standard-Infrequent Access (S3 Standard-IA) after

30

days, and to S3 Glacier Deep Archive after

180

days.

Deploy an Amazon CloudFront distribution with the Amazon S3 bucket configured as the origin to serve the images to global users.

Configure an Amazon S3 Lifecycle policy to transition the images to S3 Glacier Flexible Retrieval after

30

days, and to S3 Glacier Deep Archive after

180

days.

Enable Amazon S3 Transfer Acceleration on the bucket and configure the application to distribute the accelerated endpoint URL to users for downloading the images.

Create an Amazon S3 Gateway VPC Endpoint in the VPC and update the public route tables to route the external user download traffic to S3 through the endpoint.

Show answer & explanation

Answer: Configure an Amazon S3 Lifecycle policy to transition the images to S3 Standard-Infrequent Access (S3 Standard-IA) after $30$ days, and to S3 Glacier Deep Archive after $180$ days.; Deploy an Amazon CloudFront distribution with the Amazon S3 bucket configured as the origin to serve the images to global users.

Answer

The correct actions are to deploy an Amazon CloudFront distribution with the S3 bucket as the origin and to configure an Amazon S3 Lifecycle policy to transition the images to S3 Standard-IA after 30 days and to S3 Glacier Deep Archive after 180 days.

Deploying an Amazon CloudFront distribution is correct because CloudFront's data transfer out rates to the internet are cheaper than S3's rates, and caching at the edge reduces S3 API call costs. Transitioning images to S3 Standard-IA after 30 days is correct because it maintains the required millisecond retrieval time while lowering storage costs, and transitioning to S3 Glacier Deep Archive after 180 days is correct because it is the most cost-effective tier that meets the 12-hour compliance retrieval requirement.

Step-by-Step Solution

Analyze the image access patterns to determine the appropriate storage tiers.

Images require millisecond access for the first 180 days (frequent for 30 days, then infrequent), and can tolerate up to 12 hours retrieval after 180 days.

This mapping allows transitioning from S3 Standard to S3 Standard-IA at day 30, and then to S3 Glacier Deep Archive at day 180, minimizing storage costs.

Analyze the global delivery requirements to optimize data transfer out (DTO) costs.

Global users downloading directly from S3 incurs high standard DTO charges. Caching and serving content via CloudFront reduces S3 requests and utilizes lower CloudFront DTO rates.

CloudFront reduces overall DTO costs and provides caching, which reduces S3 GET request fees.

Key Concept

Cost-effective storage tiering and global content delivery optimization using S3 Lifecycle policies and CloudFront.

PreviousPage 82 / 99Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept