All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A public transit agency, MetroTransit, is modernizing its real-time bus tracking application by migrating it from on-premises virtual machines to AWS. The application consists of an API gateway container and two backend processing containers that need to communicate with each other with sub-millisecond latency. The application also needs to fetch real-time weather updates from an external public API every minute. The system must be highly available and resilient to Availability Zone outages, and it must run with the least possible operational overhead. The Solutions Architect plans to deploy the application on Amazon ECS using the AWS Fargate launch type across two Availability Zones in a new VPC. Which design meets these requirements?

Create a single ECS task definition containing all three containers. Configure the task to use the AWS Fargate launch type, which automatically uses the awsvpc network mode, allowing the containers to communicate over localhost. Deploy the tasks in private subnets across two Availability Zones, and deploy a NAT Gateway in each public subnet to provide redundant outbound connectivity.

Create a single ECS task definition containing all three containers. Configure the network mode to bridge to allow the containers to communicate using the Docker bridge network. Deploy the tasks in private subnets across two Availability Zones, and deploy a NAT Gateway in each public subnet to provide redundant outbound connectivity.

Create a single ECS task definition containing all three containers. Configure the task to use the AWS Fargate launch type and use the host network mode to bind the containers directly to the host network namespace. Deploy the tasks in private subnets across two Availability Zones, and deploy a NAT Gateway in each public subnet to provide redundant outbound connectivity.

Create a single ECS task definition containing all three containers. Configure the task to use the AWS Fargate launch type, which automatically uses the awsvpc network mode, allowing the containers to communicate over localhost. Deploy the tasks in private subnets across two Availability Zones, and deploy a single NAT Gateway in one public subnet of one Availability Zone to route all outbound traffic.

Show answer & explanation

Answer: Create a single ECS task definition containing all three containers. Configure the task to use the AWS Fargate launch type, which automatically uses the awsvpc network mode, allowing the containers to communicate over localhost. Deploy the tasks in private subnets across two Availability Zones, and deploy a NAT Gateway in each public subnet to provide redundant outbound connectivity.

Answer

The correct design uses a single ECS task definition containing all three containers on AWS Fargate. Fargate tasks run in the awsvpc network mode, where all containers within the task share the same network namespace and can communicate with each other over localhost with sub-millisecond latency. To ensure high availability and resilience to Availability Zone outages, tasks are deployed across multiple Availability Zones, and outbound internet access is routed through a dedicated NAT Gateway in each Availability Zone, preventing a single point of failure.

Step-by-Step Solution

Analyze container-to-container latency and deployment constraints.

To achieve sub-millisecond container-to-container latency, the containers should run within the same ECS task, allowing them to communicate over localhost. Fargate uses the awsvpc network mode, which enables this.

Running containers in the same task enables local loopback communication, avoiding network traversal over load balancers.

Select the correct network mode for AWS Fargate.

Recognize that AWS Fargate only supports the awsvpc network mode, ruling out bridge and host network modes.

Fargate abstracts the host, meaning traditional host and bridge networking configurations are not supported.

Evaluate high availability requirements for outbound internet traffic.

Determine that a NAT Gateway must be deployed in each public subnet across the two Availability Zones to prevent a single point of failure.

If a single NAT Gateway is used and its Availability Zone fails, tasks in other zones will lose outbound connectivity.

Key Concept

AWS Fargate network modes and NAT Gateway high availability

Estimated Time:2m 0s

Question 1762Question →

An enterprise is planning to migrate a mission-critical multi-tier application from an on-premises VMware vSphere cluster to a newly provisioned VMware Cloud on AWS (VMC on AWS) Software-Defined Data Center (SDDC). The application comprises:

* ` $15$ ` transactional database virtual machines (VMs) requiring zero downtime and continuous replication to meet a Recovery Time Objective (RTO) of zero during switchover.
* ` $105$ ` web and application server VMs that can tolerate a brief service interruption (maximum ` $15\text{ minutes}$ ` of downtime for a reboot) during cutover.

The network architecture requires transitive routing between the on-premises datacenter, the VMC on AWS SDDC, and four spoke VPCs in a multi-account AWS Organization. An existing ` $10\text{ Gbps}$ ` AWS Direct Connect (DX) connection terminates at a Direct Connect Gateway (DXGW) in a shared network account. The migrated VMs must also resolve private DNS records in an AWS Route 53 Private Hosted Zone (PHZ) managed in a Shared Services account.

Which combination of actions will meet these requirements with the least operational overhead? (Select TWO.)

Select all that apply

Deploy VMware HCX. Configure Replication-Assisted vMotion (RAV) to migrate the `

15

` transactional database VMs to ensure zero downtime during switchover. Configure HCX Bulk Migration for the `

105

` web and application server VMs to replicate data in the background and execute a scheduled switchover with a brief reboot.

Establish a VMware Cloud on AWS Transit Connect to peer the SDDC with an AWS Transit Gateway in the network account. Attach the Direct Connect Gateway to the AWS Transit Gateway using a Transit Virtual Interface (Transit VIF) for transitive routing. Associate the Route 53 Private Hosted Zone with the SDDC's connected VPC.

Install the AWS Application Migration Service (MGN) agent on all VMs. Replicate the `

15

` database VMs using MGN replication over a Public Virtual Interface (Public VIF) on the Direct Connect connection to ensure zero-downtime switchover.

Attach the Direct Connect Gateway directly to the VMware Cloud on AWS SDDC and the spoke VPCs using Private Virtual Interfaces (Private VIFs). Configure static routing on the Direct Connect Gateway to enable direct transitive routing between the VMC on AWS SDDC and the spoke VPCs.

Configure a Route 53 inbound resolver endpoint in the Shared Services VPC. Direct all DNS queries from the VMC on AWS SDDC VMs to the inbound resolver endpoint IP addresses without associating the Private Hosted Zone with the SDDC's connected VPC.

Show answer & explanation

Answer: Deploy VMware HCX. Configure Replication-Assisted vMotion (RAV) to migrate the ` $15$ ` transactional database VMs to ensure zero downtime during switchover. Configure HCX Bulk Migration for the ` $105$ ` web and application server VMs to replicate data in the background and execute a scheduled switchover with a brief reboot.; Establish a VMware Cloud on AWS Transit Connect to peer the SDDC with an AWS Transit Gateway in the network account. Attach the Direct Connect Gateway to the AWS Transit Gateway using a Transit Virtual Interface (Transit VIF) for transitive routing. Associate the Route 53 Private Hosted Zone with the SDDC's connected VPC.

Answer

The correct actions are: (1) Deploy VMware HCX, using Replication-Assisted vMotion (RAV) for the database virtual machines and Bulk Migration for the remaining virtual machines. (2) Establish a VMware Cloud on AWS Transit Connect peered with an AWS Transit Gateway, attach the Direct Connect Gateway via a Transit VIF, and associate the Private Hosted Zone with the connected VPC.

For the migration, VMware HCX is the recommended tool for vSphere-to-VMC migrations. HCX Replication-Assisted vMotion (RAV) replicates data in the background and switches over live, satisfying the zero-downtime requirement for database virtual machines. HCX Bulk Migration replicates data in the background and reboots the target virtual machine, which satisfies the web and application server virtual machines' downtime limit of 15 minutes. For connectivity, VMware Cloud on AWS Transit Connect peered with an AWS Transit Gateway in the customer account enables transitive routing when combined with a Direct Connect Gateway attached using a Transit VIF. To enable DNS resolution of private records, the Private Hosted Zone must be associated with the connected VPC where the SDDC interfaces with AWS services.

Step-by-Step Solution

Select the appropriate migration tool and profiles for each tier.

Choose VMware HCX. Use Replication-Assisted vMotion (RAV) for the 15 database VMs requiring zero downtime, and Bulk Migration for the 105 web/app VMs that can tolerate a reboot.

HCX is the native migration solution for VMware to VMC. RAV enables zero-downtime hot migration in parallel, and Bulk Migration enables high-throughput scheduled switchovers with a brief reboot.

Establish transitive hybrid network routing.

Peer the VMware Transit Connect with an AWS Transit Gateway, and attach the Direct Connect Gateway to the Transit Gateway using a Transit VIF.

VMC Transit Connect combined with Transit Gateway enables transitive routing across on-premises, the VMC SDDC, and the spoke VPCs, which is not supported by Direct Connect Gateway alone.

Ensure DNS resolution for AWS Private Hosted Zones from the VMC SDDC.

Associate the Route 53 Private Hosted Zone in the Shared Services account with the SDDC's connected VPC.

Since DNS resolution for the SDDC traverses the connected VPC's Route 53 Resolver, associating the PHZ with the connected VPC enables VMC VMs to resolve the private DNS names.

Key Concept

VMware Cloud on AWS hybrid migration using HCX (RAV and Bulk Migration), transitive routing using Transit Connect and AWS Transit Gateway, and Private Hosted Zone VPC association.

Question 1763Question →

An enterprise is designing a hybrid network architecture for its multi-account AWS environment. The environment consists of $30$ spoke VPCs in a single AWS Region, divided into Production and Development workloads. The on-premises network must connect to the AWS environment using a $10\text{ Gbps}$ AWS Direct Connect connection as the primary path and an IPsec VPN over the internet as a backup path. The network design must support transitive VPC-to-VPC routing, restrict the Development VPCs from accessing the on-premises network while allowing the Production VPCs full access, and support dynamic routing failover using BGP.

Which two options should the Solutions Architect select to meet these requirements?

Select all that apply

Deploy an AWS Transit Gateway, attach the spoke VPCs, and configure separate Transit Gateway route tables for the Production and Development VPC attachments to control route propagation and isolate development traffic from the on-premises connection.

Associate a Direct Connect Gateway with the AWS Transit Gateway, configure a Transit Virtual Interface (Transit VIF) for the primary connection, and establish an IPsec VPN connection on the Transit Gateway as a backup path, using BGP for dynamic failover.

Associate a Direct Connect Gateway directly with the Virtual Private Gateways of each spoke VPC, and rely on the Direct Connect Gateway to enable transitive routing between the spoke VPCs and the on-premises datacenter.

Create a single Transit Gateway route table for all spoke VPCs, associate a Route 53 Private Hosted Zone with all VPCs, and use DNS routing policies to prevent the Development VPCs from resolving the IP addresses of on-premises resources.

Route all outbound traffic from all spoke VPCs to a single NAT Gateway deployed in a centralized Transit Gateway services VPC to minimize NAT Gateway costs and administrative overhead.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway, attach the spoke VPCs, and configure separate Transit Gateway route tables for the Production and Development VPC attachments to control route propagation and isolate development traffic from the on-premises connection.; Associate a Direct Connect Gateway with the AWS Transit Gateway, configure a Transit Virtual Interface (Transit VIF) for the primary connection, and establish an IPsec VPN connection on the Transit Gateway as a backup path, using BGP for dynamic failover.

Answer

Deploy an AWS Transit Gateway with separate route tables for the Production and Development VPC attachments, and associate a Direct Connect Gateway with the Transit Gateway using a Transit VIF while setting up a Transit Gateway VPN connection utilizing BGP for dynamic failover.

To achieve transitive routing and network segmentation for

30

spoke VPCs, an AWS Transit Gateway is deployed. Spoke VPCs are attached to the Transit Gateway, and separate route tables are configured for Production and Development VPCs to block Development traffic from routing to the on-premises network. For the hybrid connection, a Direct Connect Gateway is associated with the Transit Gateway using a Transit VIF to establish the primary

10\text{ Gbps}

link. A Site-to-Site VPN is configured as a Transit Gateway attachment to serve as the backup link, with BGP managing dynamic failover.

Step-by-Step Solution

Evaluate the requirement for transitive routing and scale.

Identify AWS Transit Gateway as the central hub to support VPC-to-VPC and hybrid transitive routing for

30

VPCs.

Direct Connect Gateway alone does not support transitive routing between attached VPCs.

Design route isolation between Production and Development workloads.

Configure separate Transit Gateway route tables. Associate Development VPCs with a route table that does not propagate the on-premises route, and associate Production VPCs with a route table that does propagate it.

This implements network-level isolation, preventing Development workloads from reaching on-premises resources.

Establish the primary and backup hybrid connectivity paths with dynamic failover.

Associate the Direct Connect Gateway with the Transit Gateway via a Transit VIF (primary), and configure an IPsec VPN attachment on the Transit Gateway (backup) with BGP routing enabled on both.

BGP ensures dynamic path selection and automatically switches traffic to the VPN backup path if the Direct Connect link fails.

Key Concept

AWS Transit Gateway acts as a cloud router supporting transitive routing, route isolation via multiple route tables, and dynamic failover by combining Direct Connect Gateways (via Transit VIFs) and IPsec VPNs using BGP routing.

Estimated Time:3m 0s

Question 1764Question →

A gaming publisher is migrating its legacy multiplayer matchmaking and lobby servers from an on-premises data center to AWS using AWS Application Migration Service (MGN). The hybrid network architecture consists of an AWS Site-to-Site VPN terminating on an AWS Transit Gateway that is attached to a staging VPC. The source servers are in a highly secure zone with no direct route to the public internet and must perform data replication strictly over the private VPN connection.

After installing the AWS replication agent on the source servers, the replication status shows as stalled, and the agent logs indicate a connection timeout when attempting to reach the replication servers in the staging VPC.

Which two configuration steps must the Solutions Architect perform to resolve this connectivity issue? (Select TWO.)

Select all that apply

Modify the AWS Application Migration Service staging area settings to use a private IP address for data routing, and configure the replication security group in the staging VPC to allow inbound traffic on TCP port 1500 from the on-premises subnet range.

Configure the on-premises firewall to allow outbound traffic on TCP port 1500 to the staging VPC CIDR block, and verify that the Transit Gateway route tables have propagation or static routes configured for both the on-premises and staging VPC attachments.

Deploy a NAT Gateway in the staging VPC public subnet, update the staging subnet route tables to direct all 0.0.0.0/0 traffic to the NAT Gateway, and configure the on-premises firewall to accept incoming connections over TCP port 443.

Create an Amazon Route 53 Private Hosted Zone for the Application Migration Service control plane interface VPC endpoint in the staging VPC, and associate the hosted zone with the on-premises DNS server to resolve replication target hostnames.

Configure a Direct Connect Gateway directly attached to the staging VPC to handle transitive VPC-to-VPC traffic, and configure the source servers to route replication traffic over TCP port 8080.

Show answer & explanation

Answer: Modify the AWS Application Migration Service staging area settings to use a private IP address for data routing, and configure the replication security group in the staging VPC to allow inbound traffic on TCP port 1500 from the on-premises subnet range.; Configure the on-premises firewall to allow outbound traffic on TCP port 1500 to the staging VPC CIDR block, and verify that the Transit Gateway route tables have propagation or static routes configured for both the on-premises and staging VPC attachments.

Answer

Modify the AWS Application Migration Service staging area settings to use a private IP address for data routing, allow inbound traffic on TCP port 1500 in the replication security group, permit outbound traffic on TCP port 1500 on the on-premises firewall, and configure Transit Gateway route tables to allow private routing between the attachments.

To achieve private replication over the VPN connection, the AWS Application Migration Service must be configured to route data over private IP addresses. Because data replication occurs strictly over TCP port 1500, the replication security group in the staging VPC must permit inbound port 1500 traffic from the on-premises subnets, the on-premises firewall must permit outbound port 1500 traffic to the staging VPC CIDR, and the Transit Gateway route tables must have valid routing configurations for both attachments.

Step-by-Step Solution

Configure private IP address usage for replication traffic in the AWS Application Migration Service (MGN) staging area settings.

Ensures that replication servers are assigned and use private IP addresses for data replication instead of public IP addresses.

This complies with the security requirement to restrict replication data traffic to the private VPN connection.

Ensure firewall rules and security groups permit TCP port 1500 traffic.

Allows replication agents to establish the data channel to the replication servers.

AWS MGN performs data replication strictly over TCP port 1500, which must be open bidirectionally between source and replication subnets.

Verify Transit Gateway routing between the on-premises network and the staging VPC.

Enables transitive routing of packets across the private Site-to-Site VPN to the staging subnets.

Without proper route propagation or static routes in the Transit Gateway route table, packets cannot reach their destination across the attachments.

Key Concept

Configuring secure private network data replication for AWS Application Migration Service (MGN) over VPN and Transit Gateway using private IP routing and TCP port 1500.

Estimated Time:2m 0s

Question 1765Question →

An enterprise needs to migrate $450\text{ TB}$ of historical compliance records from an on-premises SFTP server to Amazon S3. The migration must be completed within $25\text{ days}$ . The enterprise has a dedicated $200\text{ Mbps}$ network connection to AWS. Legacy applications must continue to access the records using the SFTP protocol without code modifications. Corporate auditing standards mandate that all data at rest must be encrypted using a customer managed key (CMK) in AWS KMS. Which two options should the solutions architect select to meet these requirements?

Select all that apply

Order AWS Snowball Edge Storage Optimized devices, configure them with an on-premises import job utilizing a customer managed key (CMK) for encryption, copy the initial

450\text{ TB}

dataset to the devices, and ship them back to AWS.

Create an AWS Transfer for SFTP endpoint backed by Amazon S3 configured to use the customer managed key (CMK) for encryption, deploy an AWS DataSync agent on-premises to sync changes made during shipping, and transition client connections to the new SFTP endpoint.

Deploy AWS DataSync agents on-premises to transfer the

450\text{ TB}

dataset directly over the

200\text{ Mbps}

network connection to Amazon S3, using the customer managed key (CMK) to encrypt data in transit and at rest.

Order AWS Snowball Edge Storage Optimized devices using the default AWS managed key (aws/s3) for encryption to simplify cross-account sharing, copy the dataset, ship them back to AWS, and configure an AWS Storage Gateway File Gateway to serve SFTP clients.

Establish an AWS Direct Connect connection with a Transit Gateway and Direct Connect Gateway to configure transitive routing, then deploy AWS Transfer Family with an AS2 protocol endpoint to stream the

450\text{ TB}

payload within the migration window.

Show answer & explanation

Answer: Order AWS Snowball Edge Storage Optimized devices, configure them with an on-premises import job utilizing a customer managed key (CMK) for encryption, copy the initial $450\text{ TB}$ dataset to the devices, and ship them back to AWS.; Create an AWS Transfer for SFTP endpoint backed by Amazon S3 configured to use the customer managed key (CMK) for encryption, deploy an AWS DataSync agent on-premises to sync changes made during shipping, and transition client connections to the new SFTP endpoint.

Answer

The correct actions are to order AWS Snowball Edge Storage Optimized devices using a customer managed key for the bulk migration, and configure an AWS Transfer for SFTP endpoint backed by Amazon S3 while deploying an AWS DataSync agent to synchronize delta changes.

The solution requires a hybrid approach. The timeline constraint of

25\text{ days}

for

450\text{ TB}

of data makes an online-only transfer over a

200\text{ Mbps}

network connection mathematically impossible (~

208\text{ days}

). Therefore, the solutions architect must use AWS Snowball Edge Storage Optimized devices for the initial bulk data load. Using a customer managed key (CMK) is required to meet the auditing rules. To preserve SFTP protocol compatibility for legacy applications, AWS Transfer for SFTP backed by Amazon S3 is deployed. An AWS DataSync agent is used to synchronize the delta changes made on-premises during the Snowball shipment window, as the delta changes easily fit within the

200\text{ Mbps}

bandwidth.

Step-by-Step Solution

Calculate the time required to transfer the data over the network.

200\text{ Mbps}

, transferring

450\text{ TB}

of data takes over

208\text{ days}

, which exceeds the

25

-day limit. Thus, physical transport using AWS Snowball Edge is required for the initial load.

To verify whether an online or offline migration strategy is feasible within the given time constraint.

Apply compliance and key requirements to the bulk transfer.

Order AWS Snowball Edge Storage Optimized devices configured with an import job using a customer managed key (CMK) in KMS to ensure compliance with auditing standards.

To copy the bulk dataset securely and ensure that encryption is controlled via a custom-managed KMS key.

Ensure continuous protocol support and synchronization of delta changes.

Configure AWS Transfer for SFTP backed by Amazon S3 to provide compatibility for legacy applications, and deploy an AWS DataSync agent on-premises to sync active data updates during shipping and import.

To support the legacy SFTP clients without code changes and sync updates that occurred during the transit phase.

Key Concept

Selecting the correct hybrid migration tool based on network bandwidth limits, legacy protocol requirements, and encryption compliance standards.

Estimated Time:2m 0s

Question 1766Question →

An image processing application runs on Amazon EC2 instances in private subnets across three Availability Zones in a VPC. The application downloads and processes approximately $80\text{ TB}$ of raw files per month from an Amazon S3 bucket in the same Region and uploads the results back. The application also queries a metadata database hosted in a partner company's VPC in the same Region. These API queries transfer approximately $15\text{ TB}$ of data monthly and are currently routed over the public internet through the application's NAT Gateways to the partner's public API endpoint. The company wants to reduce the high data transfer and NAT Gateway processing costs while maintaining high availability.

Which two of the following actions should the Solutions Architect recommend to achieve these goals? (Select TWO.)

Select all that apply

Create a Gateway VPC Endpoint for Amazon S3 in the application's VPC, and associate it with the route tables of the private subnets.

Request the partner company to publish their metadata database API as an AWS PrivateLink VPC Endpoint Service, and create an Interface VPC Endpoint in the application's VPC to access the API.

Consolidate the NAT Gateways across the three Availability Zones into a single NAT Gateway in one Availability Zone to eliminate the hourly charges of the other two NAT Gateways.

Route all S3 and API traffic from the application VPC through an AWS Transit Gateway to a centralized egress VPC that contains a dedicated NAT Gateway pool.

Create a Route 53 Private Hosted Zone for the partner's API domain in a centralized AWS account, but do not associate it with the application VPC.

Show answer & explanation

Answer: Create a Gateway VPC Endpoint for Amazon S3 in the application's VPC, and associate it with the route tables of the private subnets.; Request the partner company to publish their metadata database API as an AWS PrivateLink VPC Endpoint Service, and create an Interface VPC Endpoint in the application's VPC to access the API.

Answer

Create a Gateway VPC Endpoint for Amazon S3 in the application's VPC, and request the partner company to publish their metadata database API as an AWS PrivateLink VPC Endpoint Service to establish an Interface VPC Endpoint.

Deploying a Gateway VPC Endpoint for S3 completely eliminates data processing fees for the

80\text{ TB}

of S3 traffic, as Gateway Endpoints are free. Deploying an Interface VPC Endpoint (AWS PrivateLink) for the partner API routes the

15\text{ TB}

of traffic privately, reducing the data processing fee from

0.045 per GB (NAT Gateway) to

0.01 per GB and eliminating public internet egress charges.

Step-by-Step Solution

Identify S3 traffic volume and determine the most cost-effective VPC connection type.

Amazon S3 traffic accounts for

80\text{ TB}

per month. A Gateway VPC Endpoint is free of charge (no hourly or data processing fees).

Using a Gateway VPC Endpoint bypasses NAT Gateways and eliminates all data processing costs for S3 traffic.

Analyze API traffic volume and compare NAT Gateway costs vs AWS PrivateLink Interface Endpoint costs.

API traffic accounts for

15\text{ TB}

per month. NAT Gateway processing is

0.045 per GB, plus internet data transfer out of

0.09 per GB. AWS PrivateLink charges $0.01 per GB for processing and eliminates internet egress fees.

AWS PrivateLink reduces the processing charge by

78\%

and avoids public egress charges entirely, keeping traffic on the AWS backbone.

Key Concept

Reducing NAT Gateway processing and data transfer charges by utilizing VPC Gateway Endpoints for S3 and Interface Endpoints (AWS PrivateLink) for cross-VPC API communication.

Question 1767Question →

A company manages a multi-account AWS environment using AWS Organizations. The company needs to grant read-only access to a third-party compliance team. The compliance team authenticates using an external corporate SAML 2.0 Identity Provider (IdP). The compliance team must access resources across several target accounts in the 'Compliance' Organizational Unit (OU) without managing local AWS IAM user credentials in each account.

An administrator needs to configure the trust relationship so that the external compliance team can federate directly into the target accounts. Service Control Policies (SCPs) are applied to the 'Compliance' OU to restrict administrative access.

Which configuration strategy correctly establishes this federated access in a secure manner?

In each target AWS account, create a SAML Identity Provider (IdP) referencing the compliance team's IdP metadata. Create an IAM role in each target account with a trust policy that allows the `sts:AssumeRoleWithSAML` action for the local SAML provider ARN, and attach the required read-only permission policies to these roles.

Create a Service Control Policy (SCP) at the 'Compliance' OU level that explicitly allows the external SAML IdP's entity ID to access all member accounts. Attach the read-only permission policies directly to this SCP, allowing compliance users to bypass local IAM role creation in the target accounts.

In each target AWS account, create a SAML Identity Provider (IdP) referencing the compliance team's IdP metadata. Create an IAM role in each target account with a trust policy that specifies the SAML provider as the principal but allows the `sts:AssumeRole` action, and attach the required read-only permission policies to these roles.

Create the SAML Identity Provider (IdP) only in the management account of the organization. Create a centralized IAM role in the management account using `sts:AssumeRoleWithSAML`. Rely on the Organization's root SCP to allow this role to dynamically assume local administrator roles in target accounts in the 'Compliance' OU.

Show answer & explanation

Answer: In each target AWS account, create a SAML Identity Provider (IdP) referencing the compliance team's IdP metadata. Create an IAM role in each target account with a trust policy that allows the `sts:AssumeRoleWithSAML` action for the local SAML provider ARN, and attach the required read-only permission policies to these roles.

Answer

The correct option correctly outlines that target accounts must have a local SAML Identity Provider configured and a corresponding local IAM role. The role's trust policy must explicitly allow the `sts:AssumeRoleWithSAML` action to process SAML assertions from the external provider.

Step-by-Step Solution

Each target account is aware of the external SAML IdP and can validate assertion signatures.

This establishes trust between the target AWS accounts and the external identity provider.

Create an IAM role with a trust policy allowing `sts:AssumeRoleWithSAML` for the SAML provider.

An IAM role exists that is assumable by users authenticated by the external SAML IdP.

Federated users need an AWS role to assume in order to receive temporary security credentials.

Attach the required read-only IAM permissions policy to the created IAM role in each target account.

The federated session receives the appropriate read-only authorization.

This ensures the compliance team has the necessary access to inspect resources inside the target accounts.

Key Concept

To establish cross-account access via SAML 2.0 federation, each target AWS account must have a configured SAML Identity Provider and local IAM roles with trust policies specifying `sts:AssumeRoleWithSAML` as the action.

Question 1768Question →

An aerospace defense systems provider is planning to migrate its mission-critical flight monitoring and logistics workloads to AWS. The on-premises environment consists of:

* $150$ VMware vSphere virtual machines (VMs) running a mix of Linux and Windows.
* $40$ physical bare-metal servers running IBM AIX $7.2$ .
* $15$ physical bare-metal servers running CentOS $7.9$ .

The company's security compliance policy strictly forbids installing any third-party agents or software directly inside the guest operating systems of the virtualized VMware environment. Outbound internet access from the bare-metal network segment is prohibited, except through an authenticated on-premises forward proxy. The provider wants to gather configuration and performance utilization data for all workloads, along with process-level network dependency details for the CentOS servers. Finally, they require a centralized dashboard to track the migration status using both AWS Migration Service tools and their existing third-party migration tracking tool.

Which migration discovery and tracking strategy should a solutions architect recommend?

Deploy the AWS Application Discovery Agentless Collector as a virtual appliance in the VMware environment. Install the AWS Application Discovery Agent on all physical servers, including the CentOS and AIX systems, configuring them to route outbound traffic through the forward proxy. Use AWS Systems Manager Inventory to collect network dependency details. Register all discoveries in AWS Migration Hub, and use AWS Systems Manager to track third-party migration tool activities.

Install the AWS Application Discovery Agent on the VMware VMs and the CentOS physical servers. Configure the CentOS agents to use the on-premises forward proxy for outbound communication. Use the AWS Application Discovery Agentless Collector to discover the AIX servers by connecting directly to their management interfaces. Perform all tracking using the AWS Application Discovery Service console, and configure a webhook to sync the data to AWS Migration Hub.

Deploy the AWS Application Discovery Agentless Collector as a virtual appliance in the VMware environment. Install the AWS Application Discovery Agent on the

15

CentOS physical servers, configured to route outbound traffic through the on-premises forward proxy. Manually import the configuration data of the

40

AIX physical servers using the Application Discovery Service CSV template. Configure AWS Migration Hub to aggregate the discovery data and integrate the third-party migration tracking tool.

Deploy the AWS Application Discovery Agentless Collector to discover the VMware VMs and the CentOS physical servers. Perform a manual import using the Application Discovery Service CSV template for the

40

AIX physical servers. Use AWS Systems Manager Distributor to deploy the third-party migration tracking tool across all environments, and utilize Amazon CloudWatch dashboards to track migration progress.

Show answer & explanation

Answer: Deploy the AWS Application Discovery Agentless Collector as a virtual appliance in the VMware environment. Install the AWS Application Discovery Agent on the $15$ CentOS physical servers, configured to route outbound traffic through the on-premises forward proxy. Manually import the configuration data of the $40$ AIX physical servers using the Application Discovery Service CSV template. Configure AWS Migration Hub to aggregate the discovery data and integrate the third-party migration tracking tool.

Answer

Deploy the AWS Application Discovery Agentless Collector as a virtual appliance in the VMware environment. Install the AWS Application Discovery Agent on the CentOS physical servers, configured to route outbound traffic through the on-premises forward proxy. Manually import the configuration data of the AIX physical servers using the Application Discovery Service CSV template. Configure AWS Migration Hub to aggregate the discovery data and integrate the third-party migration tracking tool.

Deploying the AWS Application Discovery Agentless Collector in the VMware environment respects the restriction against guest-level agent installations. The CentOS physical servers, which require process-level and dependency tracking, are supported by the Application Discovery Agent, which can be configured to communicate via the on-premises forward proxy. Since IBM AIX is not supported by the discovery agent, manually importing configuration details via a CSV template is the correct method. AWS Migration Hub serves as the central hub to aggregate discovery data and supports tracking integration with third-party tools.

Step-by-Step Solution

Determine the discovery mechanism for the VMware vSphere VMs.

The AWS Application Discovery Agentless Collector must be deployed as an OVA virtual appliance.

Installing agents inside guest VMs is prohibited by the customer's compliance policy.

Determine the discovery and networking approach for CentOS physical servers.

The AWS Application Discovery Agent is installed on CentOS servers and configured with proxy variables.

CentOS physical servers need process-level dependencies, and the agent supports proxy settings to route outbound traffic through the on-premises forward proxy.

Evaluate the discovery mechanism for the bare-metal AIX servers.

A CSV import template must be populated and imported manually into AWS Application Discovery Service.

IBM AIX is not supported by either the Application Discovery Agent or the Agentless Collector.

Determine the tracking and third-party integration platform.

AWS Migration Hub must be used to track the migration and aggregate discovery data.

AWS Migration Hub natively supports tracking migration status from both AWS tools and integrated third-party migration tools.

Key Concept

Selecting and configuring AWS Application Discovery Service agents, agentless collectors, and CSV import mechanisms based on operating system, hypervisor, security, and networking requirements, and consolidating discovery and migration tracking in AWS Migration Hub.

Estimated Time:3m 0s

Question 1769Question →

A financial technology company is designing a new global payment settlement platform. The solution requires a highly available transactional metadata database (OLTP) to process high-throughput transaction records, alongside a high-volume NoSQL database for real-time audit logs. The OLTP database must support a cross-region disaster recovery strategy with a Recovery Point Objective (RPO) of less than 1 second and a Recovery Time Objective (RTO) of less than 1 minute. Additionally, during peak trading hours, the OLTP database must dynamically scale to support sudden read traffic spikes. All data stored in both database engines must be encrypted using customer-managed keys (CMKs) in AWS KMS, allowing a centralized security account to manage and rotate the keys. Which two database and storage configurations should the solutions architect choose to meet these requirements?

Select all that apply

Configure an Amazon Aurora Global Database with Aurora PostgreSQL. Set up Aurora Auto Scaling for the Aurora Replicas in both the primary and secondary regions to handle dynamic read scaling.

Provision an Amazon DynamoDB table for audit logs with encryption enabled using Customer Managed Keys (CMKs), and update the KMS key policy in the security account to grant cross-account permissions.

Configure Amazon RDS for PostgreSQL with a Multi-AZ deployment, and configure the application to direct read traffic to the standby instance to handle peak trading spikes.

Set up hourly cross-region copying of Amazon Aurora DB cluster snapshots to a secondary region, and write a script to restore the cluster if the primary region fails.

Provision an Amazon DynamoDB table for audit logs, encrypting the data with an AWS managed KMS key, and configure cross-account IAM roles to allow key administration from the centralized security account.

Show answer & explanation

Answer: Configure an Amazon Aurora Global Database with Aurora PostgreSQL. Set up Aurora Auto Scaling for the Aurora Replicas in both the primary and secondary regions to handle dynamic read scaling.; Provision an Amazon DynamoDB table for audit logs with encryption enabled using Customer Managed Keys (CMKs), and update the KMS key policy in the security account to grant cross-account permissions.

Answer

Configure an Amazon Aurora Global Database with Aurora PostgreSQL utilizing Aurora Auto Scaling for replicas, and provision Amazon DynamoDB tables for logs encrypted with KMS Customer Managed Keys (CMKs) managed by the centralized security account.

Configuring Amazon Aurora Global Database allows low-latency cross-region replication that meets the under 1-second RPO and under 1-minute RTO. Aurora Replicas support active read scaling, which is automated using Aurora Auto Scaling. Encrypting the Amazon DynamoDB table with Customer Managed Keys (CMKs) enables modification of the KMS key policy to permit cross-account administrative control from the centralized security account.

Step-by-Step Solution

Evaluate the OLTP database disaster recovery requirements (RPO < 1s, RTO < 1m) and read scalability.

Amazon Aurora Global Database is selected because its physical replication matches the low RPO/RTO goals, and Aurora Auto Scaling on Aurora Replicas manages traffic spikes.

Alternative patterns like standard RDS Multi-AZ or snapshot copying fail either the RTO/RPO target or the capability to scale reads dynamically.

Determine the database configuration for the time-series audit logs.

Amazon DynamoDB is selected as a low-latency NoSQL database.

DynamoDB scales horizontally and natively supports high-throughput NoSQL write workloads.

Determine the encryption key management strategy for cross-account security delegation.

Select AWS KMS Customer Managed Keys (CMKs) rather than AWS-managed keys.

AWS-managed keys do not permit key policy edits, which prevents cross-account delegation of key rotation and management.

Key Concept

Designing a secure, highly scalable, and low-latency storage strategy using Amazon Aurora Global Database and Amazon DynamoDB with custom-managed KMS encryption policies.

Estimated Time:3m 0s

Question 1770Question →

A company is planning to migrate its on-premises application environment to AWS and wants to track the overall migration progress in AWS Migration Hub. The environment consists of 120 VMware vSphere virtual machines running supported versions of Windows Server and Red Hat Enterprise Linux, along with 10 physical bare-metal servers running IBM AIX 7.2. The company's corporate security policy strictly prohibits direct outbound internet access from these servers, but a site-to-site VPN connection to an AWS VPC is available. The Solutions Architect must collect system configurations, gather performance utilization history, map network dependencies to identify application boundaries, and minimize manual effort. Which combination of actions should the Solutions Architect take to accomplish these goals?

Install the AWS Application Discovery Agent on the VMware virtual machines, configured to send data through an on-premises proxy to the AWS Application Discovery Service VPC endpoint. Manually gather configuration and dependency details for the AIX bare-metal servers, and import them into AWS Migration Hub using the CSV import template.

Deploy the AWS Application Discovery Agentless Collector on VMware vSphere to discover both the VMware virtual machines and the AIX bare-metal servers. Configure the collector to output discovery logs to a local Amazon S3 File Gateway to bypass the outbound internet restriction.

Install the AWS Application Migration Service (MGN) replication agent on all VMware virtual machines and AIX bare-metal servers to automatically discover OS configurations and track live network replication dependencies directly within the AWS Migration Hub dashboard.

Request an AWS Snowball Edge Storage Optimized device, deploy the Application Discovery Agentless Collector on the device's compute capacity, and connect it to the on-premises network to perform local scanning of the VMware virtual machines and AIX physical servers without using the VPN.

Show answer & explanation

Answer: Install the AWS Application Discovery Agent on the VMware virtual machines, configured to send data through an on-premises proxy to the AWS Application Discovery Service VPC endpoint. Manually gather configuration and dependency details for the AIX bare-metal servers, and import them into AWS Migration Hub using the CSV import template.

Answer

The correct choice involves installing the AWS Application Discovery Agent on the VMware VMs, routing their traffic to a VPC endpoint via an on-premises proxy, and manually importing the AIX bare-metal server data. The discovery agent supports the Windows and Red Hat Enterprise Linux VMs and can gather the network connection data needed for dependency mapping. For security, routing the agent traffic via a proxy to the VPC endpoint satisfies the constraint of having no direct outbound internet access. Since IBM AIX is not supported by the discovery agents, their information must be manually collected and imported via the Migration Hub CSV template.

Step-by-Step Solution

Identify the OS compatibility of AWS Application Discovery Service collection mechanisms.

The Application Discovery Agent supports Windows and standard Linux distributions but does not support IBM AIX. The Agentless Collector cannot perform discovery on physical bare-metal servers.

This rules out automatic agent-based collection for the AIX servers and indicates they must be manually documented and imported using the Migration Hub CSV import template.

Determine the data collection requirements for dependency mapping.

Process-level network dependency mapping requires the Application Discovery Agent (agent-based), while the Agentless Collector only gathers VM-level inventory and performance.

The agent-based approach is required for the VMware virtual machines to map network dependencies.

Address the security requirement of no direct outbound internet access.

Route the agent traffic through an on-premises proxy to the AWS Application Discovery Service VPC endpoints (AWS PrivateLink) over the site-to-site VPN connection.

This allows secure data transmission to AWS without allowing direct outbound internet access from the on-premises servers.

Key Concept

Determining appropriate AWS Application Discovery Service collection methods based on operating system support, virtualization type, network dependency mapping requirements, and security configurations.

Estimated Time:2m 0s

Question 1771Question →

A financial services company manages its multi-account environment using AWS Organizations. To ensure strict compliance, the security team wants to restrict member accounts in the Development Organizational Unit (OU) to only use Amazon S3, Amazon EC2, and Amazon DynamoDB. A solutions architect creates a custom Service Control Policy (SCP) that allows all actions (`*`) for `s3`, `ec2`, and `dynamodb`. The architect attaches this SCP to the Development OU and removes the default `FullAWSAccess` SCP. Shortly after, a developer in a development member account attempts to upload objects to an S3 bucket. The S3 bucket is encrypted with a Customer Managed Key (CMK) stored in the same account. The developer's IAM role has the AWS-managed policy `AmazonS3FullAccess` attached. However, the developer receives an 'Access Denied' error. What is the root cause of this issue?

The custom SCP on the OU automatically overrides the developer's local IAM policies and grants S3 access directly, but the developer must use an IAM role in the Organizations management account to inherit the SCP permissions.

The S3 bucket is encrypted using an AWS-managed KMS key (aws/s3), which does not support policy modifications, and the developer must modify the key policy of the AWS-managed KMS key to allow the member account's role access.

The developer's IAM role is missing a trust relationship with the AWS Organizations management account, which prevents the role from inheriting permissions from the newly attached Service Control Policy.

The custom SCP implicitly denies AWS KMS actions because the default FullAWSAccess SCP was removed. The developer's IAM role lacks permission to use the Customer Managed Key (CMK) for encryption because the SCP blocks the required Key Management Service (KMS) actions.

Show answer & explanation

Answer: The custom SCP implicitly denies AWS KMS actions because the default FullAWSAccess SCP was removed. The developer's IAM role lacks permission to use the Customer Managed Key (CMK) for encryption because the SCP blocks the required Key Management Service (KMS) actions.

Answer

The correct answer is correct because SCPs in AWS Organizations act as filters that define the maximum permissions for member accounts. By default, the FullAWSAccess SCP allows all actions. When it is removed and replaced by a custom SCP that only allows S3, EC2, and DynamoDB, any other service (such as KMS) is implicitly denied. Since the S3 bucket is encrypted with a Customer Managed Key (CMK), writing to it requires KMS actions (kms:GenerateDataKey and kms:Decrypt). The implicit deny in the SCP blocks these KMS actions, causing the upload operation to fail despite the developer's local S3 permissions.

Step-by-Step Solution

Analyze how SCPs function in AWS Organizations when the default FullAWSAccess SCP is removed.

Removing the default FullAWSAccess SCP means that any AWS service or API action not explicitly allowed in the remaining attached SCPs is implicitly denied.

This establishes the baseline that only services explicitly whitelisted in the custom SCP can be accessed by users in the member accounts.

Identify the encryption requirement for writing objects to the S3 bucket.

The S3 bucket is encrypted using a Customer Managed Key (CMK) in AWS Key Management Service (KMS). Writing to this bucket requires both S3 permissions and KMS permissions (kms:GenerateDataKey, kms:Decrypt).

This shows that the client needs permission to interact with AWS KMS to perform the S3 upload operation successfully.

Determine the interaction between the custom SCP and the developer's IAM role.

The custom SCP allows S3, EC2, and DynamoDB, but does not allow KMS. Therefore, KMS actions are implicitly denied at the organization boundary. This deny overrides the local IAM policy's allow permissions.

This explains why the developer receives an Access Denied error despite having the AmazonS3FullAccess local policy.

Key Concept

Service Control Policies (SCPs) define the maximum permission boundaries in an AWS Organization. Removing the default FullAWSAccess SCP and attaching a custom SCP that restricts allowed services will implicitly deny access to any unlisted dependent services (like AWS KMS), even if users have local administrative privileges.

Question 1772Question →

An enterprise IoT data ingestion platform runs on Amazon EC2 instances inside an Auto Scaling group (ASG) spread across three Availability Zones. The instances require 5 minutes to download configuration files and bootstrap before they can accept requests from an Application Load Balancer (ALB). During sudden morning traffic spikes, the ALB returns HTTP 503 Service Unavailable errors, and the ASG launches far more instances than needed, leading to severe resource over-provisioning and high costs. Additionally, the current network architecture uses a single NAT Gateway located in a public subnet in Availability Zone A for all outbound traffic. If Availability Zone A suffers an outage, outbound connectivity for instances in Availability Zones B and C is completely lost. Which two modifications should the Solutions Architect implement to resolve the scaling issues and eliminate the single point of failure with the lowest recovery time objective (RTO)? (Select TWO.)

Select all that apply

Deploy a NAT Gateway in a public subnet in each Availability Zone, and update the route tables of the private subnets in each Availability Zone to route outbound traffic through their respective local NAT Gateway.

Implement an Auto Scaling group Warm Pool with pre-warmed instances in the Warmed:Running state, and adjust the scaling policy's warmup period to exceed the 5-minute instance bootstrapping time.

Decrease the default cooldown period of the Auto Scaling group to 60 seconds to allow the group to launch new instances more rapidly in response to sudden traffic spikes.

Configure all private subnets across all Availability Zones to route outbound traffic through the single NAT Gateway in Availability Zone A, and use an AWS Lambda function to recreate the NAT Gateway in another Availability Zone during an outage.

Request AWS Support to pre-warm the Application Load Balancer prior to the morning traffic spikes, and configure the target tracking scaling policy to use a shorter cooldown period.

Show answer & explanation

Answer: Deploy a NAT Gateway in a public subnet in each Availability Zone, and update the route tables of the private subnets in each Availability Zone to route outbound traffic through their respective local NAT Gateway.; Implement an Auto Scaling group Warm Pool with pre-warmed instances in the Warmed:Running state, and adjust the scaling policy's warmup period to exceed the 5-minute instance bootstrapping time.

Answer

Deploy a NAT Gateway in a public subnet in each Availability Zone with corresponding route table updates, and implement an Auto Scaling group Warm Pool with a warmup period configured to exceed the 5-minute instance bootstrapping time.

Deploying a NAT Gateway in each Availability Zone removes the single point of failure by ensuring local outbound paths. Implementing an Auto Scaling group Warm Pool allows instances to boot, configure, and sit in a warmed state, which cuts down scaling latency. Combined with a warmup period longer than the bootstrap time, this ensures the scaling metric stabilizes and prevents instance over-provisioning.

Step-by-Step Solution

Address the network single point of failure (SPOF) for outbound internet traffic.

By deploying a NAT Gateway in a public subnet in each Availability Zone and updating the route tables of the private subnets to direct traffic to their local NAT Gateway, the architecture becomes resilient to Availability Zone outages.

This guarantees that outbound internet routing is localized and independent per Availability Zone.

Resolve target initialization delays and scaling over-provisioning.

By using an Auto Scaling group Warm Pool with pre-warmed instances, we significantly reduce the time needed for instances to handle requests from 5 minutes to seconds. Increasing the warmup period to exceed the 5-minute bootstrapping window prevents the Auto Scaling group from scaling out prematurely.

This prevents the scaling policy from initiating subsequent scale-out actions while the initial instances are still bootstrapping.

Key Concept

Multi-AZ NAT Gateway redundancy and Auto Scaling Warm Pools are critical for eliminating single points of failure and managing bootstrapping delays in high-availability workloads.

Question 1773Question →

An enterprise manages a multi-account environment with $180$ AWS accounts organized under AWS Organizations. The security team is designing a centralized auditing solution to aggregate VPC Flow Logs from all VPCs in all member accounts into a single Amazon S3 bucket located in a dedicated Security account. The S3 bucket must be encrypted using a Customer Managed Key (CMK) in AWS Key Management Service (AWS KMS). The solution must prevent member accounts from reading or deleting logs, while allowing the log delivery service to write logs directly to the bucket.

Which of the following actions should the Solutions Architect perform to meet these requirements? (Select TWO.)

Select all that apply

In the Security account's S3 bucket policy, grant the s3:PutObject and s3:GetBucketAcl permissions to the delivery.logs.amazonaws.com service principal, restricting access using the aws:PrincipalOrgID condition.

In the Security account's KMS key policy, grant the kms:GenerateDataKey* and kms:Decrypt permissions to the delivery.logs.amazonaws.com service principal, restricting access using the aws:PrincipalOrgID condition.

Configure the S3 bucket encryption using the default AWS managed key (aws/s3) to simplify key management and automate access controls across all member accounts.

Apply a Service Control Policy (SCP) at the organization root that grants the s3:PutObject permission to member accounts for the Security account S3 bucket, ensuring that member accounts can write but not read logs.

In the Security account's S3 bucket policy, grant the s3:PutObject and s3:DeleteObject permissions to the root principal of all member accounts using the aws:PrincipalOrgID condition, and configure IAM policies in member accounts to deny read actions.

Show answer & explanation

Answer: In the Security account's S3 bucket policy, grant the s3:PutObject and s3:GetBucketAcl permissions to the delivery.logs.amazonaws.com service principal, restricting access using the aws:PrincipalOrgID condition.; In the Security account's KMS key policy, grant the kms:GenerateDataKey* and kms:Decrypt permissions to the delivery.logs.amazonaws.com service principal, restricting access using the aws:PrincipalOrgID condition.

Answer

The correct actions are to configure the S3 bucket policy to allow the log delivery service principal (delivery.logs.amazonaws.com) to write objects and get bucket ACLs, and to configure the KMS key policy to allow the same service principal to generate data keys and decrypt.

To centrally aggregate VPC Flow Logs in a cross-account S3 bucket, the S3 bucket policy must grant s3:PutObject and s3:GetBucketAcl to the log delivery service principal (delivery.logs.amazonaws.com). Furthermore, when the destination S3 bucket is encrypted using a Customer Managed Key (CMK) in AWS KMS, the KMS key policy must grant permissions such as kms:GenerateDataKey* and kms:Decrypt to the same log delivery service principal. Using the aws:PrincipalOrgID condition ensures that only VPCs belonging to accounts within the organization can write logs to the bucket.

Step-by-Step Solution

Configure the S3 bucket policy in the Security account.

Allows the delivery.logs.amazonaws.com service principal to perform s3:PutObject and s3:GetBucketAcl restricted by aws:PrincipalOrgID.

Enables the VPC Flow Logs log delivery service to publish logs to the cross-account bucket while restricting access to the AWS Organization.

Configure the KMS key policy for the Customer Managed Key (CMK) in the Security account.

Allows the delivery.logs.amazonaws.com service principal to use the key via kms:GenerateDataKey* and kms:Decrypt.

Allows the log delivery service to encrypt log objects before writing them to the encrypted S3 bucket.

Configure VPC Flow Logs in the member accounts' VPCs to point to the Security account S3 bucket.

Initiates flow log delivery to the central S3 bucket.

Establishes log aggregation from spoke VPCs to the central logging repository.

Key Concept

Cross-account log aggregation for VPC Flow Logs requires configuring the destination S3 bucket policy and KMS key policy to trust the AWS Log Delivery service principal (delivery.logs.amazonaws.com), rather than individual member account IAM principals.

Estimated Time:3m 0s

Question 1774Question →

An enterprise needs to migrate a $2.4\text{ PB}$ Hadoop Distributed File System (HDFS) dataset to an Amazon S3 bucket. The enterprise has a $1\text{ Gbps}$ dedicated network connection, but only a maximum of $400\text{ Mbps}$ can be allocated for migration activities to avoid impacting daily operations. The migration must be completed within $45$ days. During the migration, the source dataset is actively modified on-premises. The final migrated data in Amazon S3 must be securely accessed by an external analytics partner operating in a separate AWS account, and all data must be encrypted at rest. Which architecture strategy will migrate the dataset within the timeline and satisfy the security requirements?

Order multiple AWS Snowball Edge Storage Optimized devices. Copy the bulk data from the HDFS NFS Gateway to the Snowball Edge devices, encrypting the data with an AWS KMS Customer Managed Key (CMK). Ship the devices back to AWS. After the bulk data is imported into Amazon S3, deploy AWS DataSync agents on-premises and configure a DataSync task with an HDFS source location to transfer the incremental changes to the S3 bucket over the network. Configure the S3 bucket policy and the KMS CMK key policy to grant read access to the partner's AWS account.

Deploy AWS DataSync agents on-premises, configure the source location to point to the HDFS cluster, and configure the target to point to the Amazon S3 bucket. Encrypt the bucket using an AWS KMS Customer Managed Key (CMK). Execute the DataSync task to transfer the entire

2.4\text{ PB}

dataset over the dedicated network connection using the allocated

400\text{ Mbps}

bandwidth, then keep the source and target synchronized. Grant read access to the partner's AWS account using the KMS CMK key policy.

Order multiple AWS Snowball Edge Storage Optimized devices. Copy the bulk data from the HDFS NFS Gateway to the Snowball Edge devices, encrypting the data using the default AWS managed key (`aws/s3`). Ship the devices back to AWS. After the data is imported, deploy AWS DataSync agents on-premises to sync incremental changes from HDFS to Amazon S3 over the network. Grant read access to the external partner's AWS account by modifying the S3 bucket policy.

Order multiple AWS Snowball Edge Storage Optimized devices. Copy the bulk data from the HDFS NFS Gateway to the Snowball Edge devices, encrypting with an AWS KMS Customer Managed Key (CMK). After the bulk import, configure AWS DataSync to sync changes from on-premises to S3 VPC endpoints in multiple VPCs. Route this DataSync traffic transitively across the VPCs using a Direct Connect Gateway directly connected to the on-premises network, without using AWS Transit Gateway. Configure the KMS CMK key policy to grant access to the partner's account.

Show answer & explanation

Answer: Order multiple AWS Snowball Edge Storage Optimized devices. Copy the bulk data from the HDFS NFS Gateway to the Snowball Edge devices, encrypting the data with an AWS KMS Customer Managed Key (CMK). Ship the devices back to AWS. After the bulk data is imported into Amazon S3, deploy AWS DataSync agents on-premises and configure a DataSync task with an HDFS source location to transfer the incremental changes to the S3 bucket over the network. Configure the S3 bucket policy and the KMS CMK key policy to grant read access to the partner's AWS account.

Answer

The strategy that uses multiple AWS Snowball Edge Storage Optimized devices for the initial bulk HDFS data copy, utilizes AWS DataSync to sync HDFS incremental changes over the network, and encrypts the data using an AWS KMS Customer Managed Key (CMK) to allow cross-account access to the partner's account.

The correct strategy combines offline transfer via multiple AWS Snowball Edge Storage Optimized devices for the initial bulk data and online replication via AWS DataSync to copy incremental changes from the HDFS cluster over the network. Since

2.4\text{ PB}

cannot be transferred over

400\text{ Mbps}

within

45

days, the bulk must go offline. After import, the DataSync agent reads from the HDFS gateway to capture updates. Furthermore, a Customer Managed Key (CMK) is required because AWS-managed keys cannot be shared with external AWS accounts.

Step-by-Step Solution

Calculate the transfer duration for the

2.4\text{ PB}

dataset over the allocated

400\text{ Mbps}

network bandwidth.

The calculation (

2.4\text{ PB} / 400\text{ Mbps}

) results in a transfer time of over

550

days, which exceeds the

45

-day window, indicating that physical transfer (AWS Snowball Edge) is required for the bulk phase.

To determine whether an online or offline migration strategy is feasible under the given network constraints.

Address the requirement to transfer active updates during the migration period.

AWS DataSync is selected to sync incremental HDFS changes over the network post-bulk import, leveraging its native support for HDFS source locations.

To capture and replicate the on-premises changes to AWS while the bulk data is being shipped and ingested.

Select the correct encryption key configuration for cross-account data sharing.

An AWS KMS Customer Managed Key (CMK) is used, and its key policy is modified to grant decryption rights to the partner's AWS account.

AWS-managed keys (such as `aws/s3`) cannot be used for cross-account decryption because their key policies cannot be customized to grant access to external accounts.

Key Concept

Combining offline Snowball Edge devices for bulk data transfer with online AWS DataSync HDFS replication for active incremental changes, while using KMS Customer Managed Keys to facilitate cross-account resource sharing.

Question 1775Question →

Veloce Telemetry is migrating a Kubernetes-based telemetry application from an on-premises data center to AWS. The application must connect to an Amazon Aurora PostgreSQL database located in a separate dedicated Database VPC. The application pods must also securely pull container images from a central Amazon ECR repository in a Shared Services VPC. The architecture must prevent all traffic, including container image pulls and database queries, from traversing the public internet. Infrastructure management and operational overhead must be minimized, and the solution must remain highly available across multiple Availability Zones. The database endpoint is resolved using a Route 53 Private Hosted Zone (PHZ) created in the Database VPC. Which TWO actions should a Solutions Architect take to design a solution that meets these requirements? (Select TWO.)

Select all that apply

Deploy the telemetry workload on Amazon EKS using AWS Fargate profiles, and configure interface VPC endpoints for Amazon ECR (ecr.api and ecr.dkr) in the EKS VPC to pull container images privately.

Create an AWS Transit Gateway to route private network traffic between the EKS VPC, the Database VPC, and the Shared Services VPC, and associate the database Route 53 Private Hosted Zone with the EKS VPC.

Deploy the telemetry workload on Amazon EKS using Self-Managed Node Groups in a single Availability Zone, and route outbound image pulls and database traffic through a single NAT Gateway in that zone.

Configure the telemetry pods to use the Kubernetes hostNetwork and hostPort parameters in their specifications to bypass the VPC CNI and directly utilize the host's network namespace for database connectivity.

Create a Transit Gateway Route Table in the Shared Services account, add a static route pointing to the database VPC, and configure the database Private Hosted Zone to delegate query resolution via the Transit Gateway.

Show answer & explanation

Answer: Deploy the telemetry workload on Amazon EKS using AWS Fargate profiles, and configure interface VPC endpoints for Amazon ECR (ecr.api and ecr.dkr) in the EKS VPC to pull container images privately.; Create an AWS Transit Gateway to route private network traffic between the EKS VPC, the Database VPC, and the Shared Services VPC, and associate the database Route 53 Private Hosted Zone with the EKS VPC.

Answer

Deploy the telemetry workload on Amazon EKS using AWS Fargate profiles, configure interface VPC endpoints for Amazon ECR (ecr.api and ecr.dkr) in the EKS VPC, establish private network connectivity between the VPCs using AWS Transit Gateway, and associate the database Route 53 Private Hosted Zone with the EKS VPC.

The correct solution involves deploying the telemetry application on Amazon EKS with AWS Fargate profiles to minimize the operational overhead of node management. Interface VPC endpoints for Amazon ECR are configured in the EKS VPC to allow the EKS control plane and Fargate pods to pull container images privately. To enable private connectivity between the EKS, database, and shared services environments, AWS Transit Gateway is deployed to route traffic. Finally, the database's Route 53 Private Hosted Zone is associated with the EKS VPC, enabling the pods to resolve the database DNS endpoint privately.

Step-by-Step Solution

Select a serverless compute option for Amazon EKS to minimize node management.

AWS Fargate profiles are chosen for the EKS cluster, removing the need to manage, scale, or patch EC2 instances.

This directly addresses the constraint to minimize operational overhead.

Ensure container images can be pulled securely without traversing the public internet.

Interface VPC endpoints for Amazon ECR (ecr.api and ecr.dkr) are created in the EKS VPC.

Since the pods run in private subnets and cannot use the public internet, VPC endpoints enable private connections to Amazon ECR.

Configure private network routing between the EKS VPC, Database VPC, and Shared Services VPC.

An AWS Transit Gateway is deployed with VPC attachments to all three VPCs.

This establishes private network connectivity across the multi-account architecture without exposing traffic to the public internet.

Enable domain name resolution for the database from the EKS cluster VPC.

The Route 53 Private Hosted Zone for the database is associated with the EKS VPC.

By default, Route 53 PHZs are only resolvable within the VPCs they are associated with. Association is required for pods in the EKS VPC to resolve the database DNS endpoint.

Key Concept

Modernizing Kubernetes applications using Amazon EKS on AWS Fargate with multi-VPC private routing via Transit Gateway and Route 53 Private Hosted Zone association.

Question 1776Question →

A company is designing a hybrid network architecture for its multi-account AWS environment. The environment consists of 12 spoke VPCs in a single AWS Region, a shared services VPC, and an on-premises data center. The company requires:

- Hybrid connectivity from all VPCs to the on-premises data center using an existing AWS Direct Connect connection.
- Private DNS resolution for an on-premises domain, `corp.internal`, from all spoke VPCs.
- High-availability outbound internet connectivity for workloads running in the spoke VPCs.

Which combination of steps should a solutions architect recommend to meet these requirements with the least administrative overhead?

Deploy an AWS Transit Gateway, attach all spoke VPCs and the shared services VPC to it, and associate the Transit Gateway with a Direct Connect Gateway. Create a Route 53 Resolver outbound endpoint in the shared services VPC, create a forwarding rule for the `corp.internal` domain, and associate the rule with all VPCs. Deploy redundant NAT Gateways across multiple Availability Zones in the shared services VPC, directing spoke egress traffic to these NAT Gateways via the Transit Gateway.

Associate all 12 spoke VPCs directly with the Direct Connect Gateway to establish hybrid connectivity, and configure a full mesh of VPC peering connections for inter-VPC routing. Deploy a Route 53 Resolver outbound endpoint in the shared services VPC without associating the forwarding rule to other VPCs. Deploy a single NAT Gateway in the shared services VPC for egress traffic.

Deploy an AWS Transit Gateway, attach all spoke VPCs and the shared services VPC, and associate the Transit Gateway with the Direct Connect Gateway. Create a Route 53 Private Hosted Zone for `corp.internal` in the shared services account, but do not associate it with the spoke VPCs, relying on the Transit Gateway to route DNS queries to the shared services VPC. Deploy redundant NAT Gateways across multiple Availability Zones in the shared services VPC.

Deploy an AWS Transit Gateway, attach all spoke VPCs and the shared services VPC, and associate the Transit Gateway with the Direct Connect Gateway. Create a Route 53 Resolver outbound endpoint in the shared services VPC and associate the forwarding rule for `corp.internal` with all VPCs. Deploy a single NAT Gateway in one Availability Zone within the shared services VPC, and configure the spoke VPC route tables to direct all outbound internet traffic to this NAT Gateway via the Transit Gateway.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway, attach all spoke VPCs and the shared services VPC to it, and associate the Transit Gateway with a Direct Connect Gateway. Create a Route 53 Resolver outbound endpoint in the shared services VPC, create a forwarding rule for the `corp.internal` domain, and associate the rule with all VPCs. Deploy redundant NAT Gateways across multiple Availability Zones in the shared services VPC, directing spoke egress traffic to these NAT Gateways via the Transit Gateway.

Answer

The correct solution uses AWS Transit Gateway to interconnect all spoke VPCs and the shared services VPC, and connects to the on-premises data center via a Direct Connect Gateway. Centralized DNS resolution is achieved by configuring a Route 53 Resolver outbound endpoint and associating the forwarding rule with all VPCs. High-availability egress traffic is managed using redundant NAT Gateways across multiple Availability Zones in the shared services VPC.

Step-by-Step Solution

Deploy AWS Transit Gateway as the central hub.

Centralized routing and transit interface for all VPCs and Direct Connect.

To simplify multi-account, multi-VPC networking and avoid complex peering meshes.

Associate the Transit Gateway with the AWS Direct Connect Gateway.

Hybrid connectivity from all attached VPCs to the on-premises data center.

To route on-premises traffic through the Transit Gateway using a single connection.

Set up Route 53 Resolver outbound endpoints and associate the forwarding rule.

DNS queries for `corp.internal` are forwarded to on-premises DNS servers from all VPCs.

To enable seamless name resolution for on-premises systems from AWS workloads.

Deploy redundant NAT Gateways across multiple Availability Zones in the shared services VPC.

High-availability centralized outbound internet routing.

To prevent a single AZ failure from disabling internet egress for the entire environment.

Key Concept

Centralized hybrid networking, DNS resolution, and egress control using AWS Transit Gateway, Route 53 Resolver, and redundant NAT Gateways.

Question 1777Question →

An organization is transitioning its multi-account AWS environment to use an external SAML 2.0-compliant Identity Provider (IdP) for user authentication. The solutions architect has created the SAML identity providers in the target member accounts. However, when users attempt to authenticate, the federation process fails, and they are unable to assume the designated IAM roles. To diagnose this, the architect reviews the configurations of the member accounts and the parent AWS Organization. Which combination of actions must the solutions architect take to resolve the authentication failures and establish federated access to the target accounts? (Select TWO.)

Select all that apply

Modify the trust policy of the IAM roles in the target accounts to allow the `sts:AssumeRoleWithSAML` action, specifying the SAML identity provider as the principal and enforcing the `SAML:aud` condition.

Ensure that no Service Control Policies (SCPs) applied at the Organization or OU levels explicitly deny the `sts:AssumeRoleWithSAML` action for the target accounts.

Modify the trust policy of the IAM roles in the target accounts to allow the `sts:AssumeRole` action, specifying the SAML identity provider as the principal and checking the `SAML:iss` condition.

Attach a Service Control Policy (SCP) at the root level that explicitly grants the `sts:AssumeRoleWithSAML` action to all federated users, bypassing target account trust policies.

Configure a resource-based policy on the SAML identity providers in the target accounts to delegate the `sts:AssumeRoleWithSAML` action to the external identity provider.

Show answer & explanation

Answer: Modify the trust policy of the IAM roles in the target accounts to allow the `sts:AssumeRoleWithSAML` action, specifying the SAML identity provider as the principal and enforcing the `SAML:aud` condition.; Ensure that no Service Control Policies (SCPs) applied at the Organization or OU levels explicitly deny the `sts:AssumeRoleWithSAML` action for the target accounts.

Answer

Configure the trust policy of the target IAM roles to allow `sts:AssumeRoleWithSAML` with the SAML provider as the principal and the correct `SAML:aud` condition, and verify that no parent SCPs explicitly deny the `sts:AssumeRoleWithSAML` action.

For federated users authenticating via SAML 2.0 to access AWS, target IAM roles must trust the SAML provider object as a principal and authorize the `sts:AssumeRoleWithSAML` action. Furthermore, because Service Control Policies (SCPs) act as boundaries across the Organization, any explicit deny on STS operations will block authentication globally within that OU or account, making it necessary to verify that SCPs do not block this action.

Step-by-Step Solution

Examine the IAM role trust policy in the target accounts.

Ensure the principal is set to the Federated SAML provider ARN and the action is set to `sts:AssumeRoleWithSAML`.

SAML assertions cannot be parsed or accepted via the standard `sts:AssumeRole` call; the correct API operation must be explicitly trusted.

Configure SAML-specific conditions in the trust policy.

Add conditions verifying `SAML:aud` matches the sign-in URL.

This prevents spoofing and ensures only authorized assertions from the trusted IdP are accepted.

Inspect parent AWS Organizations Service Control Policies (SCPs).

Ensure that SCPs do not contain explicit deny statements covering the `sts:AssumeRoleWithSAML` action.

Explicit denies in SCPs override any local permissions granted in member accounts, including trust policies.

Key Concept

SAML 2.0 Federation requires both target role trust configurations (`sts:AssumeRoleWithSAML` action) and compliance with Organization-level Service Control Policies (SCPs) which act as maximum permission boundaries.

Question 1778Question →

A company's application runs on Amazon EC2 instances in private subnets across three Availability Zones in a VPC. The instances regularly download configuration files from an Amazon S3 bucket in the same region, transferring approximately $40\text{ TB}$ of data per month. The instances also stream application logs to Amazon CloudWatch Logs, transferring approximately $15\text{ TB}$ of data per month. Currently, all outbound traffic from the private subnets is routed through NAT Gateways deployed in each Availability Zone. A solutions architect needs to implement a solution to reduce the data transfer costs without compromising security or availability.

Which of the following configurations is the most cost-effective?

Create a Gateway VPC endpoint for Amazon S3 and associate it with the route tables of the private subnets. Create an Interface VPC endpoint for Amazon CloudWatch Logs in each of the three Availability Zones, and configure the instances to route CloudWatch traffic through this endpoint.

Create Interface VPC endpoints for both Amazon S3 and Amazon CloudWatch Logs in each of the three Availability Zones, and configure the instances to route all S3 and CloudWatch traffic through these endpoints.

Consolidate the three NAT Gateways into a single NAT Gateway in one Availability Zone, and keep the existing routing configuration for both Amazon S3 and Amazon CloudWatch Logs.

Deploy an AWS Transit Gateway, configure a VPN connection from the private subnets to the Transit Gateway, and route all S3 and CloudWatch Logs traffic through the Transit Gateway to their respective public endpoints.

Show answer & explanation

Answer: Create a Gateway VPC endpoint for Amazon S3 and associate it with the route tables of the private subnets. Create an Interface VPC endpoint for Amazon CloudWatch Logs in each of the three Availability Zones, and configure the instances to route CloudWatch traffic through this endpoint.

Answer

The correct configuration uses a Gateway VPC Endpoint for S3 and an Interface VPC Endpoint for CloudWatch Logs. Gateway VPC Endpoints for S3 are free of charge, completely eliminating the

1,800 monthly data processing fee. CloudWatch Logs only supports Interface VPC Endpoints, which charge

0.01 per GB for processing and

0.01 per hour per AZ. This totals

171.90 per month, which represents a net savings of over

500 compared to routing CloudWatch Logs traffic through NAT Gateways (

675 per month).

Step-by-Step Solution

Calculate the baseline data processing cost using NAT Gateways.

S3 traffic costs

40,000\text{ GB} \times \$0.045/\text{GB} = \$1,800/\text{month}

. CloudWatch Logs traffic costs

15,000\text{ GB} \times \$0.045/\text{GB} = \$675/\text{month}

. Total baseline processing cost is \

2,475/\text{month}

This establishes the current monthly costs that need to be optimized.

Evaluate the cost of using a Gateway VPC Endpoint for S3.

Gateway VPC Endpoints have no hourly or data processing charges. Cost is \

0/\text{month}

, saving \

1,800/\text{month}

for S3 traffic.

S3 supports Gateway endpoints, which are the most cost-effective way to route traffic within the same region.

Evaluate the cost of using an Interface VPC Endpoint for CloudWatch Logs across 3 Availability Zones.

Hourly charges:

3\text{ AZs} \times 730\text{ hours/month} \times \$0.01/\text{hour} = \$21.90/\text{month}

. Data processing:

15,000\text{ GB} \times \$0.01/\text{GB} = \$150/\text{month}

. Total cost: \

171.90/\text{month}

, saving \

503.10/\text{month}

compared to NAT Gateway routing.

CloudWatch Logs does not support Gateway endpoints, so Interface endpoints must be evaluated to see if they yield savings over NAT Gateways.

Key Concept

VPC endpoints optimize both costs and security by routing traffic internally within the AWS network, bypassing NAT Gateways and their high data processing charges.

Estimated Time:2m 0s

Question 1779Question →

A global retail banking corporation is planning to migrate its hybrid on-premises application portfolio to AWS. The environment consists of 300 VMware vSphere virtual machines (VMs) running supported Linux and Windows Server operating systems, 50 physical servers running Oracle Solaris, and 20 bare-metal servers running CentOS. Security policies mandate that database servers have no direct internet access and must route outbound traffic through a central corporate HTTP proxy. The security team also prohibits installing any software agents on the VMware ESXi hypervisors. The corporation requires detailed host performance data, running process lists, and network dependency mappings to plan the migration, and wants to track the discovery progress centrally using AWS Migration Hub. Which two actions should a solutions architect recommend to perform the discovery? (Select two.)

Select all that apply

Deploy the AWS Application Discovery Agent on the bare-metal CentOS servers and VMware VMs, configuring the agents to route outbound traffic through the central corporate HTTP proxy.

Collect the configuration and utilization details for the Oracle Solaris physical servers, format the data using the standard AWS Application Discovery Service CSV template, and import it into AWS Migration Hub.

Deploy the AWS Application Discovery Agentless Collector in the VMware vCenter Server environment to capture the running process lists and active network connections of the VMs.

Install the AWS Application Migration Service (MGN) replication agent on all bare-metal servers and VMware VMs to discover running processes and automatically map network dependencies.

Use the AWS Application Discovery Agent on the Oracle Solaris physical servers by routing the metrics transitively over a physical AWS Snowball Edge device deployed on-premises.

Show answer & explanation

Answer: Deploy the AWS Application Discovery Agent on the bare-metal CentOS servers and VMware VMs, configuring the agents to route outbound traffic through the central corporate HTTP proxy.; Collect the configuration and utilization details for the Oracle Solaris physical servers, format the data using the standard AWS Application Discovery Service CSV template, and import it into AWS Migration Hub.

Answer

Deploy the AWS Application Discovery Agent on the bare-metal CentOS servers and VMware VMs, configuring the agents to route outbound traffic through the central corporate HTTP proxy. Additionally, collect the configuration and utilization details for the Oracle Solaris physical servers, format the data using the standard AWS Application Discovery Service CSV template, and import it into AWS Migration Hub.

The correct options are deploying the AWS Application Discovery Agent on the bare-metal CentOS servers and VMware VMs, and importing Solaris server data via CSV. The Application Discovery Agent is required because the scenario specifies a need for network dependency mapping and running process lists, which the Agentless Collector does not support. The agents can be configured to communicate via the corporate proxy, satisfying the security requirements. Since Oracle Solaris is not supported by the Application Discovery Agent, importing the configuration data via a CSV template is the correct method to track those servers.

Step-by-Step Solution

Analyze the requirements for data collection types (process lists, network dependency mapping) and match them to the discovery tool capabilities.

The agent-based AWS Application Discovery Service is selected for CentOS and supported VMware VMs because the Agentless Collector cannot gather OS-level details such as active network connections and process lists.

Agentless collector only gathers VM configuration and CPU/RAM utilization from VMware vCenter, not deep network dependency mapping or running process lists.

Assess operating system compatibility and network constraints for the discovery agents.

The Application Discovery Agent is deployed on the CentOS servers and VMware VMs with proxy settings configured. However, Oracle Solaris is not supported by the agent.

Solaris is a Unix OS not supported by the Application Discovery Agent. The agent can route outbound HTTPS (port 443) traffic through a web proxy to handle the corporate security policy.

Determine the discovery mechanism for the unsupported Oracle Solaris servers.

Manual collection of Solaris configuration data is performed, and the results are formatted and imported using the standard CSV template in AWS Migration Hub.

CSV import allows the inclusion of unsupported operating systems and servers in Migration Hub for tracking.

Key Concept

Selecting the correct discovery mechanism (agent-based vs. agentless vs. CSV import) in AWS Application Discovery Service based on operating system compatibility, security/proxy requirements, and the need for network dependency mapping.

Question 1780Question →

A multinational retail corporation operates a multi-account AWS environment with $15$ spoke VPCs and a central Shared Services VPC in the `us-east-1` Region, all connected via an AWS Transit Gateway. The corporation recently acquired a logistics firm that has $10$ VPCs in the same Region and an on-premises warehouse network connected to AWS via a $10\text{ Gbps}$ AWS Direct Connect connection.

The solutions architect must design a hybrid network topology that satisfies the following requirements:
1. The logistics firm's VPCs must be able to access a shared inventory API hosted in the corporation's Shared Services VPC.
2. The logistics firm's VPCs must not have any network connectivity to the retail corporation's spoke VPCs.
3. Both the retail corporation's spoke VPCs and the logistics firm's VPCs must be able to communicate with the logistics firm's on-premises warehouse network.
4. Administrative overhead must be minimized, and no additional Direct Connect connections should be provisioned.

Which of the following network architectures meets these requirements?

Share the retail corporation's Transit Gateway with the logistics firm's AWS account using AWS Resource Access Manager (RAM). Attach the logistics firm's VPCs to the shared Transit Gateway. Associate the Direct Connect Gateway with the Transit Gateway. Create three separate Transit Gateway route tables: one for the corporate spokes, one for the logistics spokes, and one for the Shared Services and Direct Connect Gateway attachments. Associate the corporate spoke attachments with the corporate route table and propagate the Shared Services VPC and Direct Connect Gateway. Associate the logistics spoke attachments with the logistics route table and propagate the Shared Services VPC and Direct Connect Gateway. Associate the Shared Services VPC and Direct Connect Gateway attachments with their dedicated route table and propagate the corporate and logistics spokes.

Establish VPC peering connections between all

10

logistics VPCs and the corporate Shared Services VPC. Associate the Direct Connect Gateway directly with the Shared Services VPC using a Virtual Private Gateway (VGW), and configure a centralized software-defined WAN (SD-WAN) appliance cluster in the Shared Services VPC to route traffic between the logistics VPCs and the on-premises warehouse network.

Share the retail corporation's Transit Gateway with the logistics firm's AWS account using AWS Resource Access Manager (RAM). Attach all logistics VPCs to the shared Transit Gateway. Enable default route propagation and default route association on all attachments to use a single Transit Gateway route table. Use security groups and Network Access Control Lists (NACLs) in each VPC to block traffic between the corporate spokes and the logistics spokes, and associate the Direct Connect Gateway with a Virtual Private Gateway (VGW) in each of the

25

spoke VPCs.

Deploy a new Transit Gateway in the logistics firm's AWS account and connect the logistics VPCs to it. Establish a Transit Gateway peering connection between the retail corporation's Transit Gateway and the logistics firm's Transit Gateway. Associate the Direct Connect Gateway with the retail corporation's Transit Gateway. In the logistics Transit Gateway route table, add a static route pointing to the Transit Gateway peering connection for all traffic destined for the corporate Shared Services VPC and the on-premises warehouse network.

Show answer & explanation

Answer: Share the retail corporation's Transit Gateway with the logistics firm's AWS account using AWS Resource Access Manager (RAM). Attach the logistics firm's VPCs to the shared Transit Gateway. Associate the Direct Connect Gateway with the Transit Gateway. Create three separate Transit Gateway route tables: one for the corporate spokes, one for the logistics spokes, and one for the Shared Services and Direct Connect Gateway attachments. Associate the corporate spoke attachments with the corporate route table and propagate the Shared Services VPC and Direct Connect Gateway. Associate the logistics spoke attachments with the logistics route table and propagate the Shared Services VPC and Direct Connect Gateway. Associate the Shared Services VPC and Direct Connect Gateway attachments with their dedicated route table and propagate the corporate and logistics spokes.

Answer

The network architecture using a shared Transit Gateway with three separate route tables (Corporate, Logistics, and Shared/DX) to isolate environments while allowing shared access to Shared Services and the on-premises network.

The correct design uses a single shared Transit Gateway (via AWS RAM) to consolidate connections, minimizing administrative overhead and DX connection costs. By creating three separate Transit Gateway route tables (Corporate, Logistics, and Shared/DX), we can precisely control routing. Corporate spokes are associated with the Corporate route table, and logistics spokes are associated with the Logistics route table. Both route tables have propagations from the Shared Services VPC and the Direct Connect Gateway, enabling outbound connectivity to those destinations. To allow return traffic, the Shared Services VPC and Direct Connect Gateway attachments are associated with the Shared/DX route table, which has route propagations from both corporate and logistics spokes. Since the Corporate route table does not propagate logistics spoke routes, and the Logistics route table does not propagate corporate spoke routes, the two spoke environments remain completely isolated.

Step-by-Step Solution

Analyze the security isolation requirement between corporate spoke VPCs and logistics spoke VPCs.

Identify that separate Transit Gateway route tables are needed to prevent route propagation and direct VPC-to-VPC communication between the two sets of spokes.

A single default route table with full propagation would allow unwanted transitive routing between all attached VPCs.

Determine how to allow both environments to access the centralized Shared Services VPC and the on-premises warehouse network.

Propagate the Shared Services VPC attachment and the Direct Connect Gateway (DXGW) attachment into both the Corporate Route Table and the Logistics Route Table.

This populates both route tables with the destination CIDRs for Shared Services and on-premises, enabling outbound routing to these destinations.

Configure the routing for return traffic back from the Shared Services VPC and the on-premises network.

Associate both the Shared Services VPC and the DXGW attachments with a third route table (Shared/DX Route Table), and propagate the Corporate Spokes and Logistics Spokes into it.

This ensures the Transit Gateway knows how to route returning traffic back to the respective spokes without needing to route corporate traffic directly to logistics spokes.

Evaluate the option of using Transit Gateway peering for on-premises connectivity.

Recognize that Transit Gateway peering does not support transitive routing to a Direct Connect Gateway.

An architecture relying on TGW peering to access DXGW on a peered TGW is invalid, making separate TGWs with peering an incorrect design.

Key Concept

Transit Gateway route table isolation and propagation in a hybrid, multi-account setup

PreviousPage 89 / 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