All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

An online auction platform experiences sudden, massive surges in traffic during the final minutes of high-value auctions. The application runs on Amazon EC2 instances in an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The instances use a custom launch template that takes $5\text{ minutes}$ ( $300\text{ seconds}$ ) to download application libraries and start the service. Outbound API calls to external payment gateways are routed through a single NAT Gateway in Availability Zone $\text{us-east-1a}$ . During auction finales, the ALB immediately returns $503\text{ Service Unavailable}$ errors to new requests. Additionally, the ASG launches far more instances than needed during a surge because the scaling policy triggers additional instances before the first batch is fully functional. Which combination of actions will resolve these scaling and fault-tolerance issues with the lowest operational overhead?

Configure an Amazon CloudFront distribution in front of the ALB to cache all dynamic auction bids, reduce the ASG cooldown period to

60\text{ seconds}

, and maintain the single NAT Gateway in

\text{us-east-1a}

to control costs.

Configure a target tracking scaling policy based on average CPU utilization, set the ASG cooldown period to

120\text{ seconds}

, and configure Amazon Route 53 to distribute outbound traffic across multiple NAT Instances deployed in the private subnets.

Request AWS Support to pre-warm the ALB before scheduled high-value auctions, configure the ASG scaling policy's instance warmup to

350\text{ seconds}

, and deploy a NAT Gateway in each Availability Zone with corresponding route table updates.

Deploy a Network Load Balancer (NLB) in front of the ALB to handle the traffic spikes without pre-warming, set the ASG default cooldown to

180\text{ seconds}

, and associate the existing NAT Gateway with multiple private route tables across all Availability Zones.

Show answer & explanation

Answer: Request AWS Support to pre-warm the ALB before scheduled high-value auctions, configure the ASG scaling policy's instance warmup to $350\text{ seconds}$ , and deploy a NAT Gateway in each Availability Zone with corresponding route table updates.

Answer

Requesting AWS Support to pre-warm the ALB, setting the ASG warmup period to

350\text{ seconds}

, and deploying a NAT Gateway in each Availability Zone.

To resolve immediate

503

errors from flash traffic, the ALB must be pre-warmed since dynamic scaling of the load balancer is not instantaneous. To prevent over-provisioning during scaling, the instance warmup period must be configured to be longer than the boot and configuration time of the instances (

300\text{ seconds}

), making

350\text{ seconds}

appropriate. For fault tolerance, a NAT Gateway must be deployed in each Availability Zone to ensure outbound traffic is not dependent on a single zone.

Step-by-Step Solution

Address the load balancer bottleneck during sudden, large-scale traffic spikes.

The Application Load Balancer (ALB) is configured with pre-warming requested from AWS Support before scheduled auctions.

Dynamic scaling of the ALB is too slow for instantaneous spikes, leading to

503

errors. Pre-warming prepares the ALB with adequate capacity.

Configure the Auto Scaling Group (ASG) to prevent over-provisioning during scaling events.

The instance warmup is set to

350\text{ seconds}

, which is greater than the

300\text{ seconds}

bootstrap time.

This prevents the ASG from launching additional instances before the previously launched ones have finished bootstrapping and started reporting metrics.

Design a fault-tolerant outbound NAT architecture.

Deploy a NAT Gateway in each Availability Zone where the EC2 instances are located, and update local route tables accordingly.

Having a NAT Gateway per AZ ensures that a failure in one Availability Zone does not impact outbound connectivity for resources in other zones.

Key Concept

ELB pre-warming, Auto Scaling Group warmup tuning, and multi-AZ NAT Gateway redundancy.

Question 1722Question →

A company is implementing a federated access solution using an on-premises SAML 2.0 compliant Identity Provider (IdP) for their AWS Organizations environment. While testing the integration, a user successfully authenticates against the identity provider and selects a role named FederatedAdminRole in a target member account. However, the redirection to the AWS Management Console fails, and the user receives the following error message: 'Access denied. Action: sts:AssumeRoleWithSAML is not authorized.' The Solutions Architect verifies that the SAML identity provider is correctly created in the IAM console of the target account, and the user's SAML assertion contains the correct role and provider ARNs. Which configuration issue is the most likely cause of this error?

The trust policy of the target IAM role specifies the principal as the SAML provider but designates the action as sts:AssumeRole rather than sts:AssumeRoleWithSAML.

The Service Control Policy (SCP) attached to the target member account's Organizational Unit does not contain an explicit allow statement for the sts:AssumeRoleWithSAML action.

The identity-based permission policy attached to the target IAM role does not explicitly grant permissions for the sts:AssumeRoleWithSAML API action.

The SAML assertion generated by the Identity Provider lacks the mandatory https://aws.amazon.com/SAML/Attributes/RoleSessionName attribute, causing the request to fail authorization.

Show answer & explanation

Answer: The trust policy of the target IAM role specifies the principal as the SAML provider but designates the action as sts:AssumeRole rather than sts:AssumeRoleWithSAML.

Answer

The trust policy of the target IAM role specifies the principal as the SAML provider but designates the action as sts:AssumeRole rather than sts:AssumeRoleWithSAML.

The correct answer is the option stating that the trust policy of the target IAM role specifies the action as sts:AssumeRole instead of sts:AssumeRoleWithSAML. For SAML federation, the trust policy (trust relationship) of the role must list the SAML Identity Provider as the principal and explicitly allow the 'sts:AssumeRoleWithSAML' action. If 'sts:AssumeRole' is specified instead, AWS will deny the assertion request because it does not match the correct API operation required for federating external users.

Step-by-Step Solution

Analyze the error message.

The message indicates that the security token service action sts:AssumeRoleWithSAML is not authorized for the incoming identity request.

This points to a misconfiguration in the trust relationship (trust policy) of the target IAM role being assumed.

Check the trust policy structure of the target IAM role.

Confirm that the action specified in the trust policy's Statement block is sts:AssumeRoleWithSAML.

The correct API action for SAML-based federation is sts:AssumeRoleWithSAML. Using sts:AssumeRole is incorrect because it is used for standard IAM role assumption (e.g., cross-account or by services) and will result in an authorization failure for SAML federation.

Differentiate trust policies from identity-based policies and SCPs.

Verify that no identity-based permission policies are required to allow the trust setup, and confirm that Service Control Policies (SCPs) do not explicitly deny the action.

SAML federation trust is established solely in the role's trust policy; identity-based policies do not control trust, and SCPs only filter permissions rather than granting them.

Key Concept

SAML 2.0 Federation IAM Role Trust Policy Configuration

Estimated Time:2m 0s

Question 1723Question →

A media company runs its video encoding application on Amazon EC2 instances in private subnets across multiple Availability Zones in a VPC in the `us-west-2` Region. The instances download $150\text{ TB}$ of raw video files monthly from an Amazon S3 bucket located in `us-west-2`. The VPC route tables currently direct all S3-bound traffic through NAT Gateways.

The company also generates $80\text{ TB}$ of transcoded video logs monthly on the EC2 instances, which are uploaded to a secondary S3 bucket in the `us-east-1` Region for long-term archival. These logs are currently uploaded over the internet through the NAT Gateways. The archival logs are rarely accessed but must be retained for at least $90\text{ days}$ .

Which combination of actions will reduce the data transfer and storage costs most effectively? (Select TWO.)

Select all that apply

Create a Gateway VPC Endpoint for Amazon S3 in the `us-west-2` Region and associate it with the route tables of the private subnets.

Configure an S3 Lifecycle policy on the destination S3 bucket in `us-east-1` to transition objects to Amazon S3 Glacier Flexible Retrieval after

1\text{ day}

and expire them after

90\text{ days}

Provision an Interface VPC Endpoint (AWS PrivateLink) for Amazon S3 in the VPC in `us-west-2` and configure the EC2 instances to use the endpoint DNS names.

Request an AWS Snowball Edge Storage Optimized device monthly, copy the log files to the device, and ship it to AWS to load the data into the S3 bucket in `us-east-1`.

Show answer & explanation

Answer: Create a Gateway VPC Endpoint for Amazon S3 in the `us-west-2` Region and associate it with the route tables of the private subnets.; Configure an S3 Lifecycle policy on the destination S3 bucket in `us-east-1` to transition objects to Amazon S3 Glacier Flexible Retrieval after $1\text{ day}$ and expire them after $90\text{ days}$ .

Answer

Create a Gateway VPC Endpoint for Amazon S3 in the source region and associate it with the route tables of the private subnets, and configure an S3 Lifecycle policy on the destination bucket in the destination region to transition objects to Amazon S3 Glacier Flexible Retrieval after one day and expire them after 90 days.

Creating a Gateway VPC Endpoint for Amazon S3 in the source region allows the EC2 instances in private subnets to route both local and cross-region S3 traffic privately. This bypasses the NAT Gateways completely, eliminating the NAT Gateway data processing charge. In addition, transitioning the archived logs to Amazon S3 Glacier Flexible Retrieval after one day using an S3 Lifecycle policy minimizes storage fees in the destination region, and expiring them after 90 days avoids long-term accumulation costs.

Step-by-Step Solution

Analyze the current route path and data volume for local and cross-region S3 traffic.

Identified that

150\text{ TB}

of local S3 traffic and

80\text{ TB}

of cross-region S3 traffic are traversing the NAT Gateways, incurring high NAT Gateway data processing fees (

0.045\text{ per GB}

To determine the source of high data transfer costs.

Evaluate Gateway VPC Endpoints vs Interface VPC Endpoints for S3.

A Gateway VPC Endpoint has no hourly or data processing fees and supports both local and cross-region S3 traffic. An Interface VPC Endpoint (PrivateLink) incurs a

0.01\text{ per GB}

data processing fee, which would be expensive for

230\text{ TB}

of data.

To select the most cost-effective private connection method to Amazon S3.

Analyze the storage and retention requirements for the transcoded video logs.

Logs are stored in S3 Standard in the destination region, which is expensive for rarely accessed archival data. Transitioning them to Amazon S3 Glacier Flexible Retrieval after

1\text{ day}

and deleting them after

90\text{ days}

meets the business requirement at minimal cost.

To optimize the storage costs of the archival data.

Key Concept

Data transfer cost optimization using Gateway VPC Endpoints and storage tiering using S3 Lifecycle policies.

Question 1724Question →

BioPharma Nexus is modernizing its legacy drug discovery simulation application by migrating it from on-premises servers to Amazon ECS on AWS Fargate. The application is deployed across multiple private subnets in a Workload VPC. The container images are hosted in an Amazon ECR repository in a centralized Shared Services AWS account. The tasks also retrieve database credentials from AWS Secrets Manager in the Workload account, which are encrypted using a customer managed AWS KMS key in the Workload account.

To comply with strict security standards, no internet gateways or NAT gateways are allowed in either VPC. An AWS Transit Gateway connects the Workload VPC and the Shared Services VPC. Interface VPC endpoints for ECR (api and dkr), Secrets Manager, and KMS are established in the Shared Services VPC. The Route 53 Private Hosted Zones (PHZs) for these endpoints are currently associated only with the Shared Services VPC.

When deploying the ECS tasks in the Workload VPC, they fail to transition to the RUNNING state, displaying the error: 'ResourceInitializationError: unable to pull secrets or registry auth'.

Which of the following solutions will resolve the initialization error and allow the tasks to run successfully?

Associate the ECR, Secrets Manager, and KMS Private Hosted Zones with the Workload VPC. Create an S3 Gateway VPC endpoint in the Shared Services VPC, and add a route in the Workload VPC route tables directing S3-bound traffic to the Transit Gateway.

Associate the ECR, Secrets Manager, and KMS Private Hosted Zones with the Workload VPC. Create an S3 Gateway VPC endpoint in the Workload VPC and associate it with the Workload VPC route tables. Ensure the ECS task execution role has permissions to pull ECR images, retrieve the Secrets Manager secret, and decrypt it using the customer managed KMS key.

Modify the ECS task definition to use host network mode to allow the container to bypass Fargate VPC endpoint restrictions. Associate the ECR, Secrets Manager, and KMS Private Hosted Zones with the Workload VPC, and create an S3 Gateway VPC endpoint in the Shared Services VPC.

Create ECR, Secrets Manager, and KMS Interface VPC endpoints locally in the Workload VPC. Configure the ECS tasks to use the default AWS-managed KMS key (aws/secretsmanager) to decrypt the database credentials, and update the key policy in the Workload account to trust the Workload task execution role.

Show answer & explanation

Answer: Associate the ECR, Secrets Manager, and KMS Private Hosted Zones with the Workload VPC. Create an S3 Gateway VPC endpoint in the Workload VPC and associate it with the Workload VPC route tables. Ensure the ECS task execution role has permissions to pull ECR images, retrieve the Secrets Manager secret, and decrypt it using the customer managed KMS key.

Answer

Associate the ECR, Secrets Manager, and KMS Private Hosted Zones with the Workload VPC, create an S3 Gateway VPC endpoint locally in the Workload VPC, and ensure the ECS task execution role has the necessary ECR, Secrets Manager, and customer managed KMS key permissions.

The correct solution involves associating the Private Hosted Zones of the centralized ECR, Secrets Manager, and KMS endpoints with the Workload VPC so that the tasks can resolve their DNS names privately. Additionally, because Amazon ECR stores image layers in Amazon S3, and S3 Gateway VPC endpoints cannot be transitively accessed over AWS Transit Gateway, a local S3 Gateway VPC endpoint must be created in the Workload VPC. Finally, the ECS task execution role must be granted permissions to pull from ECR, read the Secrets Manager secret, and decrypt it using the customer managed KMS key.

Step-by-Step Solution

Associate the Route 53 Private Hosted Zones (PHZs) for ECR, Secrets Manager, and KMS from the Shared Services VPC with the Workload VPC.

Enables ECS Fargate tasks in the Workload VPC to resolve ECR, Secrets Manager, and KMS endpoint DNS names to the private IP addresses of the endpoints in the Shared Services VPC.

PHZs must be explicitly associated with any VPC that needs private DNS resolution for those names.

Create a Gateway VPC Endpoint for Amazon S3 in the Workload VPC and associate it with the Workload VPC subnet route tables.

Allows ECS Fargate tasks to directly download container image layers from Amazon S3 over the private AWS network.

Amazon ECR stores image layers in S3. Since Gateway endpoints are non-transitive, they cannot be accessed over Transit Gateway from another VPC.

Verify that the ECS task execution role has permissions to pull container images from ECR, read the secret from Secrets Manager, and decrypt the secret using the customer managed KMS key.

Ensures the ECS agent running on Fargate has the necessary credentials and IAM authorization to pull the container image and retrieve the secret during task initialization.

The ECS task execution role (not the task role) is responsible for these initialization actions.

Key Concept

Private ECS Fargate deployment requiring cross-account ECR, Secrets Manager, and S3 Gateway endpoint transit limits.

Question 1725Question →

A smart energy utility provider is designing its AWS multi-account governance structure using AWS Organizations. The provider wants to automate the creation of new accounts for regional grid monitoring applications while enforcing strict guardrails. Specifically, they must prevent any member account from disabling AWS CloudTrail and ensure that a centralized security team can access all accounts using a pre-configured IAM role.

Which combination of actions should the Solutions Architect take to implement this governance model? (Select TWO.)

Select all that apply

Deploy an IAM role in each member account with a trust policy that allows the principal of the centralized security account to assume it, and attach appropriate administrative permissions.

Create a Service Control Policy (SCP) that denies the 'cloudtrail:StopLogging' and 'cloudtrail:DeleteTrail' actions, and attach it to the root of the AWS Organization or specific Organizational Units (OUs).

Create a Service Control Policy (SCP) that grants the centralized security account administrative permissions, and attach it to the member accounts to allow direct management access.

Enable AWS CloudTrail log file encryption using the default AWS-managed KMS key (aws/cloudtrail), and modify its key policy to allow cross-account access for the security auditing tools.

Create a centralized Amazon S3 bucket in the security account with a bucket policy that allows write access solely to member account IAM identities using the 'aws:PrincipalOrgID' condition to secure the log uploads.

Show answer & explanation

Answer: Deploy an IAM role in each member account with a trust policy that allows the principal of the centralized security account to assume it, and attach appropriate administrative permissions.; Create a Service Control Policy (SCP) that denies the 'cloudtrail:StopLogging' and 'cloudtrail:DeleteTrail' actions, and attach it to the root of the AWS Organization or specific Organizational Units (OUs).

Answer

To implement this governance model, the Solutions Architect should deploy an IAM role in each member account with a trust policy that allows the principal of the centralized security account to assume it, and create a Service Control Policy (SCP) that denies the 'cloudtrail:StopLogging' and 'cloudtrail:DeleteTrail' actions, attaching it to the root or specific Organizational Units.

The correct solution involves deploying a cross-account IAM role in each member account that trusts the centralized security account, allowing secure administration, and applying an SCP to the root or OUs that explicitly denies disabling or deleting CloudTrail, which serves as a global guardrail.

Step-by-Step Solution

Analyze the requirement to prevent member accounts from disabling CloudTrail.

Identify that a Service Control Policy (SCP) with an explicit Deny rule is the correct mechanism because it establishes guardrails that even administrators in member accounts cannot bypass.

SCPs define the maximum permissions for member accounts in an organization.

Analyze the requirement for centralized security team access to member accounts.

Identify that cross-account IAM roles are required. Each member account needs a role that trusts the centralized security account's principal.

SCPs cannot grant permissions directly; access must be facilitated via IAM trust relationships.

Evaluate the distractors based on security and operational constraints.

Discard the options proposing AWS-managed KMS key modification, SCPs granting permissions directly, and log bucket policies that block the CloudTrail service principal.

AWS-managed KMS keys cannot have modified policies, SCPs only restrict rather than grant permissions, and CloudTrail requires service principal access to write logs.

Key Concept

AWS multi-account governance relies on SCPs for organization-wide guardrails and cross-account IAM roles for secure management access.

Question 1726Question →

A global agricultural technology platform is preparing to migrate its core crop-yield analysis and logistics coordination system to AWS. The on-premises infrastructure includes:

* $180$ VMware vSphere VMs running Red Hat Enterprise Linux (RHEL) and Windows Server. These VMs host the API layers and distributed processing nodes. The team requires deep mapping of network dependencies (TCP connections) between these servers to group them into application stacks.
* $35$ bare-metal servers running Oracle Solaris, hosting legacy databases and proprietary data processing engines. These servers are located in a highly secure zone with no outbound internet connectivity, and the OS is not supported by the AWS Application Discovery Agent.

All outbound traffic from the VMware vSphere environment must go through an on-premises HTTP proxy. The platform team wants to use AWS Migration Hub as the single pane of glass to plan the migration, group servers, and track the migration status of these workloads.

Which combination of discovery mechanisms and tracking setup should a solutions architect recommend to satisfy these requirements?

Install the AWS Application Discovery Agent on the

180

VMware vSphere VMs, configuring the agents to communicate via the on-premises HTTP proxy. For the

35

bare-metal Solaris servers, manually collect configuration metadata and import it into AWS Migration Hub using a CSV file. Group the discovered assets into applications within Migration Hub, and track migration status using AWS Application Migration Service (MGN) or compatible third-party tools integrated with Migration Hub.

Deploy the AWS Application Discovery Agentless Collector on VMware vCenter to discover the

180

vSphere VMs and map their TCP network connections. Install the AWS Application Discovery Agent on the

35

bare-metal Solaris servers, configuring a local port forwarder to route the discovery data through the RHEL VMs' HTTP proxy. Group the assets in AWS Systems Manager Application Manager and track migration status there.

Deploy the AWS Application Discovery Agentless Collector on VMware vCenter. For the

35

bare-metal Solaris servers, establish a temporary IPSec VPN connection to AWS and install the AWS Application Discovery Agent on each server to stream discovery data. Group the servers into applications in AWS Migration Hub, and write custom AWS Lambda functions to query the Systems Manager Inventory API to update migration status.

Install the AWS Application Discovery Agent on all

180

VMware vSphere VMs and the

35

bare-metal Solaris servers, using the on-premises HTTP proxy for all outbound agent traffic. Group the discovered assets into applications in AWS Migration Hub. Track the migration status using AWS DataSync to monitor real-time virtual machine replication progress.

Show answer & explanation

Answer: Install the AWS Application Discovery Agent on the $180$ VMware vSphere VMs, configuring the agents to communicate via the on-premises HTTP proxy. For the $35$ bare-metal Solaris servers, manually collect configuration metadata and import it into AWS Migration Hub using a CSV file. Group the discovered assets into applications within Migration Hub, and track migration status using AWS Application Migration Service (MGN) or compatible third-party tools integrated with Migration Hub.

Answer

Install the AWS Application Discovery Agent on the VMware vSphere VMs, configuring the agents to communicate via the on-premises HTTP proxy. Manually collect metadata for the bare-metal Solaris servers and import it into AWS Migration Hub using a CSV file. Use Migration Hub-integrated migration tools to track migration status.

The correct recommendation is to install the AWS Application Discovery Agent on the VMware vSphere VMs because the team requires mapping of TCP network connections to group servers into application stacks, a capability that the Agentless Collector does not support. The Discovery Agent can be configured with proxy settings to route outbound traffic through the on-premises HTTP proxy. For the bare-metal Solaris servers, since Solaris is an unsupported operating system for the Discovery Agent, and they are not hosted on VMware, their configuration data must be manually collected and imported into AWS Migration Hub using a CSV file. Once assets are grouped into applications, migration status is natively tracked using Migration Hub-compatible tools such as AWS Application Migration Service.

Step-by-Step Solution

Determine the discovery mechanism for the VMware vSphere VMs that requires TCP network dependency mapping.

Select the AWS Application Discovery Agent (agent-based) because the Agentless Collector does not gather TCP network connection or process-level dependency data.

Agent-based discovery is required to map network dependencies between servers to identify application boundaries.

Determine the discovery mechanism for the bare-metal Solaris servers that are isolated and run an unsupported OS.

Select manual configuration import using a CSV template.

Solaris is not supported by the AWS Application Discovery Agent, and bare-metal servers cannot be discovered by the VMware Agentless Collector. An offline CSV import bypasses agent and network requirements.

Address the network proxy requirement for the discovery agents.

Configure the agent installation parameters to route outbound traffic through the on-premises HTTP proxy.

The agents require outbound connectivity to AWS endpoints to upload discovery data, which must go through the proxy per corporate security policy.

Set up tracking in AWS Migration Hub using integrated migration tools.

Group the discovered assets into applications in AWS Migration Hub, and execute the migration using AWS Application Migration Service (MGN) or other integrated tools.

Migration Hub tracks migration status natively only for tools that are registered and integrated with it, such as MGN.

Key Concept

Selecting and configuring the appropriate AWS Application Discovery Service and AWS Migration Hub tracking mechanisms based on OS compatibility, network constraints, and dependency mapping needs.

Estimated Time:2m 30s

Question 1727Question →

An airline company is designing a new global reservation system. The architecture must deploy across a primary AWS Region and a secondary AWS Region for disaster recovery. The database layer consists of an online transaction processing (OLTP) workload that handles active seat reservations.

The solution must satisfy the following requirements:
- Workload & Performance: Low-latency reservation writes ( $< 15 \text{ ms}$ ) under high traffic, with horizontal read scaling in the primary Region to handle spike searches from customers.
- Disaster Recovery: A target Recovery Point Objective (RPO) of $1 \text{ second}$ and a Recovery Time Objective (RTO) of $2 \text{ minutes}$ in the secondary Region.
- Cross-Account Archiving: Completed reservation receipts must be archived to an Amazon S3 bucket owned by a centralized compliance account (`Compliance-Acct`).
- Data Security: Archived files must be encrypted at rest using an AWS KMS key managed by the reservation application's production account (`Reservation-Acct`). Auditors operating in `Compliance-Acct` must be able to decrypt the receipts.

Which combination of storage and database strategy steps will satisfy these requirements? (Select TWO.)

Select all that apply

Deploy an Amazon RDS for PostgreSQL database in a Multi-AZ deployment in the primary Region. Direct search traffic to the standby instance in the secondary Availability Zone, and use RDS Read Replicas to scale reads if replication lag increases.

Deploy an Amazon Aurora PostgreSQL database as an Aurora Global Database. In the primary Region, configure Aurora Auto Scaling to dynamically adjust the number of Aurora Replicas to scale out read capacity for customer searches.

Deploy an Amazon Aurora PostgreSQL database in the primary Region. Configure AWS Backup to perform hourly snapshots of the primary database and replicate them to the secondary Region to meet disaster recovery objectives.

In the Reservation-Acct, create a KMS Customer Managed Key (CMK) and configure its key policy to allow the Compliance-Acct IAM roles to perform KMS decrypt operations. Configure the reservation application to write the S3 receipts using the CMK ARN for server-side encryption.

Encrypt the S3 receipts using the AWS-managed KMS key for S3 (aws/s3) in the Reservation-Acct. Edit the default key policy to delegate decryption permissions to the Compliance-Acct IAM roles.

Show answer & explanation

Answer: Deploy an Amazon Aurora PostgreSQL database as an Aurora Global Database. In the primary Region, configure Aurora Auto Scaling to dynamically adjust the number of Aurora Replicas to scale out read capacity for customer searches.; In the Reservation-Acct, create a KMS Customer Managed Key (CMK) and configure its key policy to allow the Compliance-Acct IAM roles to perform KMS decrypt operations. Configure the reservation application to write the S3 receipts using the CMK ARN for server-side encryption.

Answer

To meet the requirements, deploy an Amazon Aurora PostgreSQL database as an Aurora Global Database with Aurora Auto Scaling for read scaling, and create a KMS Customer Managed Key (CMK) in the Production account with a key policy allowing the Compliance account access to decrypt logs.

The correct solution involves deploying Amazon Aurora PostgreSQL as an Aurora Global Database to achieve near-instantaneous cross-region replication, which easily satisfies the 1-second RPO and 2-minute RTO. Aurora Auto Scaling dynamically manages Aurora Replicas to scale out reads horizontally. Additionally, cross-account encryption requires a Customer Managed Key (CMK) in the source account with key policy modifications that permit decryption by the target compliance account.

Step-by-Step Solution

Analyze database latency, read scaling, and disaster recovery requirements.

Identify that Amazon Aurora Global Database provides sub-second cross-region replication for RPO/RTO goals, and Aurora Auto Scaling handles dynamic read workloads.

Standard RDS Multi-AZ standbys cannot serve read traffic, and restoring from snapshots exceeds the 2-minute RTO / 1-second RPO limits.

Analyze the cross-account S3 archiving and encryption requirements.

Recognize that a KMS Customer Managed Key (CMK) is needed because AWS-managed keys cannot be modified or shared cross-account.

The key policy must explicitly delegate decrypt permissions to the external Compliance-Acct roles, which requires a CMK.

Key Concept

Selecting high-availability database engines with cross-region replication under strict RTO/RPO constraints, coupled with configuring cross-account KMS Customer Managed Keys for secure storage access.

Estimated Time:3m 0s

Question 1728Question →

A company is designing a multi-account network architecture on AWS consisting of three spoke VPCs in the us-east-1 region with CIDR blocks $10.1.0.0/16$ , $10.2.0.0/16$ , and $10.3.0.0/16$ . The architecture must support hybrid connectivity to an on-premises data center using an AWS Direct Connect connection. Additionally, all spoke VPCs must route outbound internet traffic through a centralized egress VPC to inspect traffic and control costs. Which of the following network designs meets these requirements with the least operational complexity?

Associate the Virtual Private Gateways (VGWs) of the spoke VPCs and the egress VPC directly with a single AWS Direct Connect Gateway using Private Virtual Interfaces (Private VIFs). Configure the Direct Connect Gateway to route internal inter-VPC traffic and redirect internet-bound traffic through the egress VPC.

Deploy an AWS Transit Gateway in the region, and attach the spoke VPCs and the egress VPC to it. Associate the Transit Gateway with an AWS Direct Connect Gateway using a Transit Virtual Interface (Transit VIF). Configure the routing tables in the spoke VPCs to direct all internet-bound traffic to the Transit Gateway, and configure the Transit Gateway route table to forward internet-bound traffic to the egress VPC attachment.

Establish a mesh of VPC peering connections between all spoke VPCs and the egress VPC. Deploy a single NAT Gateway in one Availability Zone in the egress VPC, and update all spoke VPC route tables to direct outbound internet traffic through the peering connections to the single NAT Gateway.

Deploy an AWS Transit Gateway and attach the spoke VPCs and the egress VPC to it. Associate the Transit Gateway with a Direct Connect Gateway. Create a Route 53 Private Hosted Zone (PHZ) for DNS resolution in the egress VPC, and rely on the Transit Gateway attachments to automatically resolve DNS queries from the spoke VPCs without associating the PHZ with them.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway in the region, and attach the spoke VPCs and the egress VPC to it. Associate the Transit Gateway with an AWS Direct Connect Gateway using a Transit Virtual Interface (Transit VIF). Configure the routing tables in the spoke VPCs to direct all internet-bound traffic to the Transit Gateway, and configure the Transit Gateway route table to forward internet-bound traffic to the egress VPC attachment.

Answer

The correct network design leverages AWS Transit Gateway as a centralized hub to connect multiple spoke VPCs and the egress VPC. By associating the Transit Gateway with an AWS Direct Connect Gateway using a Transit Virtual Interface (Transit VIF), the organization achieves hybrid connectivity to the on-premises datacenter. Traffic flow for outbound internet is directed to the Transit Gateway, which routes it transitively to the egress VPC containing the security inspection and NAT services, satisfying all architectural requirements with minimal administrative complexity.

Step-by-Step Solution

Evaluate the requirement for centralized egress traffic control and hybrid connectivity across multiple VPCs.

Identify that AWS Transit Gateway is the appropriate hub-and-spoke service to centralize VPC routing and on-premises connectivity.

AWS Transit Gateway acts as a cloud router, simplifying network topology and enabling transitive routing between VPCs and hybrid connections.

Determine the proper Direct Connect configuration for Transit Gateway.

Associate the Transit Gateway with a Direct Connect Gateway using a Transit Virtual Interface (Transit VIF).

A Transit VIF is required to connect an on-premises Direct Connect location to an AWS Transit Gateway via a Direct Connect Gateway.

Configure the routing paths for egress traffic.

Direct spoke VPC traffic to the Transit Gateway, which then forwards the traffic to the egress VPC for internet access.

This implements centralized internet egress by steering

0.0.0.0/0

routes from spokes through the Transit Gateway to the egress VPC.

Key Concept

Hub-and-spoke transit networking with AWS Transit Gateway and Direct Connect Gateway

Question 1729Question →

A company needs to migrate $850\text{ TB}$ of data from an on-premises SMB file share to Amazon EFS. The migration must be completed within $35\text{ days}$ . The company has an active $1\text{ Gbps}$ AWS Direct Connect connection, but due to production workloads, only $150\text{ Mbps}$ of bandwidth can be allocated for this migration. All data must be encrypted at rest using an AWS Key Management Service (AWS KMS) customer managed key that can be shared with a secondary auditing AWS account. Which migration strategy will meet these requirements within the specified timeline?

Order multiple AWS Snowball Edge Storage Optimized devices, specifying the customer managed KMS key during job creation. Copy the data from the on-premises SMB share to the devices. Once the data is imported into an intermediate Amazon S3 bucket, configure an AWS DataSync task to copy the data from the S3 bucket to the Amazon EFS file system. Finally, configure another DataSync task to sync any incremental changes from the on-premises SMB share directly to Amazon EFS over the Direct Connect connection.

Deploy multiple AWS DataSync agents on-premises. Configure a DataSync task to transfer the data directly from the on-premises SMB share to the Amazon EFS file system over the

150\text{ Mbps}

allocated Direct Connect bandwidth, using a customer managed KMS key to encrypt the files during transit and at rest.

Order multiple AWS Snowball Edge Storage Optimized devices. Establish an AWS Transit Gateway and configure transit routing to allow the physical Snowball Edge devices to establish an IPSec VPN tunnel directly to the on-premises network over the Direct Connect link. Copy the data from the SMB share to the devices over this secure tunnel, then return the devices to AWS to be loaded directly into Amazon EFS.

Order multiple AWS Snowball Edge Storage Optimized devices, specifying the AWS managed KMS key (`aws/s3`) for encryption. Copy the data from the on-premises SMB share to the devices. Once the data is loaded into an intermediate Amazon S3 bucket, use AWS DataSync to copy the data to Amazon EFS. Share the AWS managed key with the secondary auditing account to allow decryption of the S3 objects for verification.

Show answer & explanation

Answer: Order multiple AWS Snowball Edge Storage Optimized devices, specifying the customer managed KMS key during job creation. Copy the data from the on-premises SMB share to the devices. Once the data is imported into an intermediate Amazon S3 bucket, configure an AWS DataSync task to copy the data from the S3 bucket to the Amazon EFS file system. Finally, configure another DataSync task to sync any incremental changes from the on-premises SMB share directly to Amazon EFS over the Direct Connect connection.

Answer

The correct option correctly addresses both the bandwidth bottleneck and the security constraints. With only

150\text{ Mbps}

of available bandwidth, an online transfer of

850\text{ TB}

would take over

500\text{ days}

, making AWS Snowball Edge necessary. Since Snowball Edge does not load directly into Amazon EFS, loading the data into Amazon S3 first and then using AWS DataSync to copy it to EFS is the standard pattern. Using a customer managed KMS key enables the cross-account key policy modification required to share the key with the auditing account. Finally, running a small incremental sync via DataSync catches any write operations performed during the shipping time.

Step-by-Step Solution

Calculate the time required for a network-based transfer over the allocated bandwidth.

Transferring

850\text{ TB}

(

6.8 \times 10^{15}\text{ bits}

) over a

150\text{ Mbps}

(

1.5 \times 10^8\text{ bps}

) link would take approximately

4.53 \times 10^7\text{ seconds}

(about

524\text{ days}

), which exceeds the

35\text{-day}

limit.

Determines whether an online or offline migration strategy is required to meet the timeline.

Select the appropriate physical transfer mechanism and security configuration.

Identify AWS Snowball Edge Storage Optimized as the solution. Select a KMS customer managed key (CMK) during job creation to support the cross-account sharing requirement.

AWS managed KMS keys cannot be shared cross-account, necessitating a customer managed key.

Determine the path to the target storage system.

Import the data from Snowball Edge into an intermediate Amazon S3 bucket, and then use AWS DataSync to transfer the data from Amazon S3 to the target Amazon EFS file system.

Snowball Edge does not support direct ingestion into Amazon EFS.

Plan the final sync for delta changes.

Configure AWS DataSync to sync remaining delta changes from the on-premises SMB share to Amazon EFS over the Direct Connect connection once the bulk data import is complete.

Ensures that any files created or modified during the transit time of the Snowball devices are captured.

Key Concept

Selecting the optimal hybrid storage migration pattern using AWS Snowball Edge and AWS DataSync based on network capability, and configuring KMS Customer Managed Keys for cross-account security requirements.

Question 1730Question →

A digital ticketing platform's reservation service runs on Amazon EC2 instances within an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The instances are deployed in private subnets and require 6 minutes to retrieve static configuration assets and initialize the application server. During unannounced concert announcements, the platform experiences sudden flash traffic spikes, leading to HTTP 503 Service Unavailable errors on the ALB before new instances are fully operational. Furthermore, outbound API calls to third-party payment gateways fail during an outage of a single Availability Zone because all private subnets route outbound traffic through a single NAT Gateway. Which combination of actions should a solutions architect take to improve the scalability and fault tolerance of the platform? (Select TWO.)

Select all that apply

Deploy a NAT Gateway in each Availability Zone used by the Auto Scaling group and update the private subnet route tables to route outbound traffic through the NAT Gateway in the same Availability Zone.

Configure an Auto Scaling group warm pool with instances in a Stopped state to maintain pre-initialized instances that can quickly transition to active service.

Reduce the default cooldown period of the Auto Scaling group to 60 seconds to allow the group to quickly launch subsequent instances during sudden traffic spikes.

Deploy a single NAT Gateway in a shared public subnet across the primary Availability Zone and configure all private subnets to route outbound traffic to it to simplify network administration.

Request AWS Support to pre-warm the Application Load Balancer before every anticipated flash traffic spike to ensure it scales instantly without dropping requests.

Show answer & explanation

Answer: Deploy a NAT Gateway in each Availability Zone used by the Auto Scaling group and update the private subnet route tables to route outbound traffic through the NAT Gateway in the same Availability Zone.; Configure an Auto Scaling group warm pool with instances in a Stopped state to maintain pre-initialized instances that can quickly transition to active service.

Answer

Deploy a NAT Gateway in each Availability Zone used by the Auto Scaling group and update the route tables, and configure an Auto Scaling group warm pool with instances in a Stopped state.

Deploying a NAT Gateway in each Availability Zone ensures that outbound traffic routes locally and eliminates cross-AZ single points of failure, preserving fault tolerance. Configuring an Auto Scaling group warm pool with stopped instances maintains pre-initialized instances that bypass the 6-minute application bootstrap time during a scaling event, resolving the Application Load Balancer HTTP 503 errors during flash traffic spikes.

Step-by-Step Solution

Analyze the scaling issue caused by the 6-minute bootstrapping delay.

Identify that a warm pool with pre-initialized instances in a Stopped state allows instances to bootstrap ahead of time and scale out in a fraction of the time, preventing HTTP 503 errors.

Resolves the long startup time of the custom initialization script during flash traffic spikes.

Analyze the fault tolerance issue with outbound traffic.

Deploy a NAT Gateway in each Availability Zone and associate them with the respective private subnet route tables.

Eliminates the single point of failure of a single NAT Gateway and ensures that an outage in one Availability Zone does not impact outbound API calls from other zones.

Key Concept

Auto Scaling Warm Pools and Multi-AZ NAT Gateway Redundancy

Question 1731Question →

A company is implementing a multi-account strategy using AWS Organizations. The company wants to centralize access management to all AWS accounts by integrating AWS IAM Identity Center with their external identity provider (IdP), Okta, which supports SAML 2.0 and SCIM. The solutions architect needs to configure automatic synchronization of users and groups from Okta to AWS, and assign permissions to these users. Which two configurations should the solutions architect implement to meet these requirements?

Select all that apply

Enable SAML 2.0 identity federation in AWS IAM Identity Center by exchanging metadata documents with Okta, and configure automatic provisioning using System for Cross-domain Identity Management (SCIM) by generating a SCIM endpoint and access token in IAM Identity Center and configuring them in Okta.

Create permission sets within AWS IAM Identity Center containing the required IAM policies, and assign these permission sets to the synchronized Okta groups within the target AWS accounts in the organization.

Create an IAM SAML identity provider in each target AWS account, configure a trust relationship using the sts:AssumeRoleWithSAML action, and map Okta groups to local IAM roles in each account individually.

Create Service Control Policies (SCPs) at the root of AWS Organizations to define the permitted IAM actions for each synchronized Okta group, relying on SCP inheritance to grant permissions across accounts without local IAM policies or permission sets.

Show answer & explanation

Answer: Enable SAML 2.0 identity federation in AWS IAM Identity Center by exchanging metadata documents with Okta, and configure automatic provisioning using System for Cross-domain Identity Management (SCIM) by generating a SCIM endpoint and access token in IAM Identity Center and configuring them in Okta.; Create permission sets within AWS IAM Identity Center containing the required IAM policies, and assign these permission sets to the synchronized Okta groups within the target AWS accounts in the organization.

Answer

The solutions architect must enable SAML 2.0 identity federation in AWS IAM Identity Center and configure SCIM provisioning for automatic synchronization. Additionally, they must create permission sets in IAM Identity Center and assign them to the synchronized groups in the target AWS accounts.

Centralizing access management using AWS IAM Identity Center requires configuring an external identity provider via SAML 2.0 and enabling SCIM for automatic provisioning of users and groups. To grant permissions, a solutions architect must create permission sets in IAM Identity Center and assign them to the synchronized groups for specific target AWS accounts.

Step-by-Step Solution

Configure identity source in AWS IAM Identity Center to use an external identity provider (Okta) and exchange SAML metadata to establish trust.

Federated authentication is established between Okta and AWS IAM Identity Center.

Allows users to authenticate to AWS using their existing Okta credentials.

Enable SCIM provisioning in AWS IAM Identity Center, copy the SCIM endpoint and access token, and configure provisioning in Okta.

Users and groups from Okta are automatically synchronized to AWS IAM Identity Center.

Ensures that group membership changes in Okta are automatically reflected in AWS without manual intervention.

Create permission sets in AWS IAM Identity Center and assign them to the synchronized groups within specific target AWS accounts.

Synchronized users gain the appropriate access levels to their assigned AWS accounts based on their Okta group membership.

Centralizes permission management across the multi-account AWS Organization.

Key Concept

AWS IAM Identity Center with external SAML IdP and SCIM provisioning

Question 1732Question →

An enterprise is establishing centralized security monitoring across its multi-account environment using AWS Organizations. A solutions architect needs to configure Amazon GuardDuty so that all security alerts are consolidated into a dedicated Security Tooling member account. The solution must ensure that member accounts cannot disable GuardDuty or modify its configurations, while allowing the Security Tooling account to manage the service.

Arrange the following steps in the correct chronological sequence to implement this governance and security architecture.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is to first enable trusted access for Amazon GuardDuty from the AWS Organizations management account, then designate the Security Tooling account as the delegated administrator from the management account. After delegation, attach a Service Control Policy (SCP) to the member OUs restricting GuardDuty modifications while exempting the delegated administrator. Finally, sign in to the Security Tooling account to enable GuardDuty and configure it to automatically enable the service for all current and future member accounts.

The correct sequence begins with the AWS Organizations management account enabling trusted access for GuardDuty, which is a prerequisite for delegation. The management account then registers the dedicated Security Tooling account as the delegated administrator. Next, the solutions architect secures the deployment by attaching an SCP to the member OUs to prevent local modification of GuardDuty settings, ensuring the delegated administrator role is exempted from this restriction. Finally, the solutions architect signs in to the Security Tooling account to enable the service and configure automatic onboarding for all current and future member accounts.

Step-by-Step Solution

Enable trusted access for Amazon GuardDuty from the AWS Organizations management account.

Enables integration between AWS Organizations and Amazon GuardDuty.

Before a member account can be registered as a delegated administrator, the service principal must be granted trusted access to the Organization's structure.

Grants the Security Tooling account permission to manage GuardDuty for the organization.

Delegated administration shifts operational control of the security service from the management account to the designated security account, adhering to the principle of least privilege.

Apply a Service Control Policy (SCP) to member OUs to prevent disabling GuardDuty.

Restricts member accounts from tampering with GuardDuty detector status, while allowing the delegated administrator role to perform its tasks.

SCPs establish organization-wide guardrails. To prevent member accounts from deleting or disabling the security monitoring, the policy must deny these APIs, while using a condition to exempt the admin role/account.

Enable and configure GuardDuty in the Security Tooling account to auto-enable for all member accounts.

Activates monitoring across all current and future member accounts.

With administrative authority delegated and governance guardrails active, the security tooling account can enable the service centrally and ensure immediate coverage for any new accounts joined to the organization.

Key Concept

Delegated administration and centralized security governance in AWS Organizations allow operational tasks to be securely managed from a dedicated security account, enforced by organization-wide SCP guardrails.

Estimated Time:3m 0s

Question 1733Question →

An automotive manufacturing company is migrating its legacy telemetry processing servers ( $8$ virtual machines running on-premises hypervisors) to AWS using AWS Application Migration Service (MGN). The migration must use a dedicated AWS Direct Connect connection connected via a transit virtual interface (VIF) to an AWS Transit Gateway. The target staging area VPC has no direct internet access, and all data replication traffic must be kept entirely private. The migration team has installed the replication agent on the source virtual machines, but the agent fails to establish a connection with the replication servers in the staging area VPC. Which of the following configuration steps must be performed to establish private replication connectivity and resolve the issue? (Select TWO.)

Select all that apply

Configure the on-premises firewall and the MGN staging area security groups to allow outbound TCP port

1500

traffic from the source servers to the replication servers in the staging area subnet.

Configure the AWS Application Migration Service replication template to use private IP addresses for data routing and ensure the Transit Gateway routes traffic between the Direct Connect connection and the staging area VPC.

Associate the Route 53 Private Hosted Zone created for the MGN control plane endpoints with the Transit Gateway to allow the replication agent to resolve the endpoints.

Deploy a single NAT Gateway in the staging area subnet and configure the route tables to route all TCP port

1500

replication traffic through it to the on-premises environment.

Configure the Direct Connect Gateway to enable direct transitive routing between the staging VPC and the inspection VPC without passing traffic through the Transit Gateway.

Show answer & explanation

Answer: Configure the on-premises firewall and the MGN staging area security groups to allow outbound TCP port $1500$ traffic from the source servers to the replication servers in the staging area subnet.; Configure the AWS Application Migration Service replication template to use private IP addresses for data routing and ensure the Transit Gateway routes traffic between the Direct Connect connection and the staging area VPC.

Answer

To establish private replication connectivity, you must configure the on-premises firewall and staging area security groups to allow TCP port

1500

traffic, and configure the MGN replication template to use private IP addresses while ensuring the Transit Gateway routes traffic over the Direct Connect connection.

The correct configuration requires opening TCP port

1500

for replication traffic and modifying the replication template to use private IP addresses. AWS Application Migration Service replicates data using the MGN replication agent over TCP port

1500

. If this port is blocked on the source firewall or staging security groups, connectivity fails. Additionally, to ensure replication traffic flows privately over Direct Connect and Transit Gateway, the replication template must be configured to use private IP addresses.

Step-by-Step Solution

Verify the network port requirements for AWS Application Migration Service replication.

Determine that TCP port

1500

must be open outbound from the source servers to the replication servers in the staging area VPC.

MGN replicates data at the block level over TCP port

1500

Configure routing and IP addressing settings in the MGN replication template.

Set the replication template to route data replication traffic over private networks using private IP addresses.

This forces replication traffic over the Direct Connect connection rather than trying to use public endpoints.

Verify routing transitiveness through the Transit Gateway.

Ensure the Transit Gateway routing tables associate and propagate paths between the on-premises gateway and the staging area VPC.

The Transit Gateway acts as the hub for routing private traffic over the Direct Connect connection.

Key Concept

Data replication in AWS Application Migration Service (MGN) requires TCP port

1500

to be open between the source agent and the staging area replication servers, and private routing must be enabled in the replication template to utilize Direct Connect or VPN connections.

Question 1734Question →

A healthcare software provider is planning to migrate its legacy patient portal and clinical analytics platform to AWS. The on-premises infrastructure consists of 80 VMware vSphere VMs running supported Linux and Windows operating systems, and 10 physical bare-metal servers running legacy AIX. The security team prohibits installing any software agents on the virtualized database VMs due to compliance requirements, but requires identifying system configurations and CPU/memory utilization. For the remaining VMs, the migration team must identify active network connections, running processes, and inbound/outbound traffic destinations to map dependencies. The migration progress must be tracked centrally alongside a third-party migration tool. Which combination of discovery mechanisms and tracking tools should the solutions architect recommend?

Deploy the AWS Application Discovery Agent on the non-database VMware VMs. Deploy the AWS Application Discovery Agentless Collector in the VMware environment to collect database VM configuration and performance metrics. Import details for the physical AIX servers using a CSV template, and track migration status centrally via AWS Migration Hub.

Deploy the AWS Application Discovery Agent on all VMware VMs and physical AIX servers. Use AWS Application Discovery Agentless Collector to monitor network traffic at the hypervisor level for the database VMs, and track the progress in AWS Systems Manager.

Deploy the AWS Application Discovery Agentless Collector in the VMware environment to discover the database VMs and non-database VMs. Use the AWS Schema Conversion Tool (SCT) to scan the legacy AIX servers, and track the migration progress using AWS Resource Access Manager.

Deploy the AWS Application Discovery Agent on the database VMs, and deploy the AWS Application Discovery Agentless Collector in the VMware environment for the non-database VMs. Install the AWS Application Migration Service (MGN) agent on the physical AIX servers, and track migration progress using AWS Systems Manager OpsCenter.

Show answer & explanation

Answer: Deploy the AWS Application Discovery Agent on the non-database VMware VMs. Deploy the AWS Application Discovery Agentless Collector in the VMware environment to collect database VM configuration and performance metrics. Import details for the physical AIX servers using a CSV template, and track migration status centrally via AWS Migration Hub.

Answer

The correct option addresses all server categories and tracking needs: the AWS Application Discovery Agent is used where process-level network dependencies are needed and permitted; the AWS Application Discovery Agentless Collector is deployed in the VMware environment to gather metadata for the database VMs without agent installation; the unsupported physical AIX servers are imported using a CSV template; and AWS Migration Hub is used to aggregate the data and track progress alongside third-party tools.

Step-by-Step Solution

Analyze the requirements for the VMware vSphere database virtual machines.

Since software agents are prohibited on database VMs, but basic configuration and utilization metrics are required, the AWS Application Discovery Agentless Collector is chosen because it runs as a VM inside VMware vCenter and does not install agents on individual guest OSs.

Ensures compliance with the security team's restriction while obtaining the necessary utilization and configuration details.

Analyze the requirements for the remaining VMware virtual machines.

The remaining VMs require process-level network connections and inbound/outbound mappings. The AWS Application Discovery Agent must be installed on these VMs since the Agentless Collector cannot collect network dependency mapping details.

Provides deep discovery details including network and process relationships needed for migration grouping.

Determine the discovery mechanism for the physical bare-metal AIX servers.

Neither the AWS Application Discovery Agent nor the Agentless Collector supports physical AIX servers. The configuration details of these servers must be imported into AWS Application Discovery Service using a formatted CSV file.

Allows capturing and listing unsupported legacy architectures in the migration inventory.

Determine the tracking dashboard and tool integration requirements.

AWS Migration Hub must be utilized because it centralizes migration tracking across both AWS discovery tools and supported third-party migration tools.

Fulfills the requirement to centrally track migration progress alongside third-party tools.

Key Concept

Selecting the correct discovery mechanisms (Agent, Agentless, and Import) based on operating system support and security compliance, and tracking migration progress centrally with AWS Migration Hub.

Question 1735Question →

An enterprise is using AWS Organizations to manage its multi-account environment. The security team wants to restrict developers in the Sandbox organizational unit (OU) to launching Amazon EC2 instances only in the us-east-1 and us-west-2 Regions, and prevent them from launching GPU-based instance types (such as p or g families). The solution must prevent non-compliant resource creation even if local administrators have full administrative access within their accounts. Which strategy meets these requirements with the least administrative overhead?

Attach a Service Control Policy (SCP) to the Sandbox OU that denies ec2:RunInstances if the requested Region is not us-east-1 or us-west-2, or if the instance type matches p* or g*. Configure local IAM policies within the sandbox accounts to grant developers the required ec2:RunInstances permissions.

Attach a Service Control Policy (SCP) to the Sandbox OU that allows ec2:RunInstances only in us-east-1 and us-west-2 for instance types other than p* or g*. Remove local IAM policies from the sandbox accounts to let the SCP directly control developer access.

Configure an IAM role in a central governance account with the required Region and instance type restrictions. Set up web identity federation to allow developers in the sandbox accounts to assume this role directly and launch resources.

Define an IAM permissions boundary restricting Region and instance type usage in the management account. Use AWS Resource Access Manager (RAM) to share this permissions boundary with the Sandbox OU, and configure AWS RAM to automatically apply it to all IAM users and roles in the member accounts.

Show answer & explanation

Answer: Attach a Service Control Policy (SCP) to the Sandbox OU that denies ec2:RunInstances if the requested Region is not us-east-1 or us-west-2, or if the instance type matches p* or g*. Configure local IAM policies within the sandbox accounts to grant developers the required ec2:RunInstances permissions.

Answer

Attach a Service Control Policy (SCP) to the Sandbox OU that denies ec2:RunInstances if the requested Region is not us-east-1 or us-west-2, or if the instance type matches p* or g*, and configure local IAM policies within the sandbox accounts to grant developers the required permissions.

The correct strategy uses a Service Control Policy (SCP) with an explicit Deny effect applied to the Sandbox organizational unit. In AWS Organizations, SCPs act as guardrails that define the maximum permissions for member accounts. An explicit Deny in an SCP overrides any Allow permissions granted by local IAM policies, including those of administrators. However, since SCPs do not grant permissions directly, local IAM policies must still be created within the member accounts to grant developers the ability to run instances.

Step-by-Step Solution

Analyze the requirements for restricting EC2 regions and instance types across multiple sandbox accounts, ensuring the restrictions apply even to local administrators.

Identify that Service Control Policies (SCPs) are the primary mechanism in AWS Organizations to enforce maximum permission boundaries across accounts, including for local administrators.

SCPs apply to all users and roles in member accounts, including the root user and administrators, making them ideal for enforcing compliance constraints centrally.

Determine the correct policy structure for the SCP.

Construct an SCP with a Deny effect that blocks ec2:RunInstances when the region is not us-east-1/us-west-2, or when the instance type matches GPU families.

Explicit deny statements in SCPs override any local allow policies, ensuring compliance without restricting local administrative flexibility for other actions.

Define local IAM roles or policies in the member accounts to grant the actual permissions.

Create local IAM policies that allow developers to run instances.

SCPs do not grant permissions directly; they only restrict the maximum permissions. Local IAM policies are still required to grant the permissions to the identity.

Key Concept

Service Control Policies (SCPs) act as guardrails in AWS Organizations to limit the maximum permissions in member accounts, but they do not grant permissions directly; local IAM policies are still required.

Question 1736Question →

A medical device manufacturing company is planning to migrate its core supply chain and regulatory compliance systems to AWS. The on-premises environment consists of two distinct segments:

1. A cluster of VMware vSphere 7.0 virtual machines (VMs) running supported Enterprise Linux operating systems inside a secure network zone. These VMs have no direct internet access but can communicate outbound through an authenticated HTTP/HTTPS proxy. The company's compliance policy strictly prohibits installing any software at the hypervisor level (ESXi hosts), but permits guest-level agent installations.
2. Several physical bare-metal servers running a highly customized legacy Linux kernel that does not support the installation of the AWS Application Discovery Agent.

The migration team must discover the server configurations, monitor CPU and memory utilization for right-sizing, map network dependencies (specifically active TCP connections between servers), and track the overall migration status in AWS Migration Hub. The team also wants to integrate this tracking with their existing Jira Service Management platform for change management.

Which two actions should a solutions architect recommend to satisfy these discovery and tracking requirements? (Select two.)

Select all that apply

Install the AWS Application Discovery Agent on the VMware VMs, configure the agents to use the authenticated HTTP/HTTPS proxy for outbound communication, and enable the Jira Service Management integration in AWS Migration Hub.

Manually record the hardware configuration and network connections of the bare-metal servers, format the data into the standard Application Discovery Service CSV import templates, and upload them to the Migration Hub console.

Deploy the AWS Application Discovery Agentless Collector in the VMware environment, configure it to run network dependency scanning on the VMs via vCenter APIs, and use a custom script to run the Agentless Collector in loopback mode on the bare-metal servers.

Install the AWS Application Discovery Agent directly on the VMware ESXi hosts to capture network packet flows from all VMs without VM-level installation, and import the bare-metal server data using AWS Application Migration Service (AWS MGN) replication templates.

Configure AWS Application Discovery Agentless Collector to query the VMware VMs using guest OS credentials, and deploy a third-party discovery agent on the bare-metal servers that syncs directly to AWS Systems Manager Inventory to bypass Migration Hub.

Show answer & explanation

Answer: Install the AWS Application Discovery Agent on the VMware VMs, configure the agents to use the authenticated HTTP/HTTPS proxy for outbound communication, and enable the Jira Service Management integration in AWS Migration Hub.; Manually record the hardware configuration and network connections of the bare-metal servers, format the data into the standard Application Discovery Service CSV import templates, and upload them to the Migration Hub console.

Answer

Install the AWS Application Discovery Agent on the VMware VMs while routing outbound data through the proxy, integrate Migration Hub with Jira Service Management, and manually import the bare-metal server configurations and network dependencies using the CSV import templates.

The correct options state that we must install the guest-level AWS Application Discovery Agent on the VMware VMs (configuring it to use the proxy) and manually import the configuration and dependency data of the bare-metal servers using CSV templates. The Discovery Agent is required because the Agentless Collector does not collect the requested network connection details. Since the bare-metal legacy Linux servers cannot run agents and are not virtualized on VMware, their data must be uploaded manually via CSV. Additionally, AWS Migration Hub natively integrates with Jira Service Management to centralize and track ticketed migration workflows.

Step-by-Step Solution

Determine the discovery mechanism for the VMware VMs based on the network dependency mapping requirement.

Since network connection mapping (TCP dependencies) is required, the Agentless Collector cannot be used. The AWS Application Discovery Agent must be installed on the VMs.

Agentless Collector only gathers VM specifications and utilization metrics at the vCenter level, lacking the capability to map process-to-process or network connections.

Configure the Application Discovery Agents to comply with the secure zone's network constraints.

Configure the agent's proxy settings using the authenticated HTTP/HTTPS proxy configuration options.

The agents require outbound connectivity to AWS endpoints to upload collected data, which must route through the proxy in a no-direct-internet zone.

Evaluate the discovery options for the physical bare-metal legacy Linux servers.

Since the legacy Linux kernel prevents agent installation and they are physical servers (excluding VMware Agentless collection), use the Application Discovery Service CSV import templates.

Importing via CSV is the standard mechanism to manually inject server configuration, performance, and dependency data for unsupported or untracked legacy infrastructure.

Configure the centralized tracking integration in AWS Migration Hub.

Link AWS Migration Hub with Jira Service Management using the integrated connector.

This satisfies the requirement to track the overall migration progress and coordinate change management tickets within the existing Jira platform.

Key Concept

Selecting and configuring the correct AWS Application Discovery Service tool (Agent-based vs. Agentless vs. CSV Import) based on OS compatibility, virtualization type, network topology, and the requirement to map network dependencies.

Question 1737Question →

A financial company is planning to migrate a critical payment application from an on-premises VMware vSphere cluster to VMware Cloud on AWS (VMC). The application consists of $40$ application server virtual machines (VMs) that can tolerate a brief service interruption (less than $5$ minutes) during switchover, and $2$ transactional database VMs that must remain online with zero downtime and zero data loss ( $RPO = 0$ , $RTO = 0$ ) during the migration.

The company's AWS multi-account environment is structured as follows:
* Account A hosts the VMC on AWS Software-Defined Data Center (SDDC).
* Account B hosts a Shared Services VPC containing Active Directory servers and Amazon Route 53 Private Hosted Zones (PHZs).
* Account C hosts native production spoke VPCs.

A customer-managed AWS Transit Gateway (TGW) in a central network account connects the Shared Services VPC and the Account C production spoke VPCs. Physical connectivity to the on-premises datacenter is established via a $2\text{ Gbps}$ AWS Direct Connect connection terminated on a customer-managed Direct Connect Gateway (DXGW).

The target architecture must enable bidirectional DNS resolution between all environments, allow on-premises administrators to manage the SDDC VMs post-migration, and enable private communication between SDDC VMs and native AWS resources.

Which combination of migration techniques and network configurations will meet these requirements?

Use VMware HCX Bulk Migration for the

40

application VMs and VMware HCX Replication Assisted vMotion (RAV) for the

2

database VMs. Configure VMware Transit Connect (VTGW) for the SDDC, peer VTGW with the customer-managed TGW, and associate the DXGW with both VTGW and the customer-managed TGW. Associate the Route 53 PHZs in Account B with the SDDC's connected VPC, and configure Route 53 Resolver outbound endpoints to forward on-premises DNS queries.

Use VMware HCX Bulk Migration for all

42

VMs. Configure VMware Transit Connect (VTGW) for the SDDC, peer VTGW with the customer-managed TGW, and associate the DXGW with the customer-managed TGW. Route all SDDC traffic to the on-premises datacenter transitively through the customer-managed TGW. Associate the Route 53 PHZs with the SDDC's connected VPC, and use Route 53 Resolver endpoints for hybrid DNS.

Use VMware HCX Bulk Migration for the

40

application VMs and VMware HCX Replication Assisted vMotion (RAV) for the

2

database VMs. Peer VMware Transit Connect (VTGW) with the customer-managed TGW, and associate the DXGW only with the customer-managed TGW. Route SDDC traffic to the on-premises datacenter transitively via the TGW peering connection. Associate the Route 53 PHZs with the SDDC's connected VPC, and configure Route 53 Resolver endpoints.

Use VMware HCX Replication Assisted vMotion (RAV) for all

42

VMs. Peer VMware Transit Connect (VTGW) with the customer-managed TGW, and associate the DXGW with both VTGW and the customer-managed TGW. Associate the Route 53 PHZs in Account B only with the Shared Services VPC, relying on default VPC DNS delegation to resolve native AWS resource names from the SDDC overlay networks. Configure Route 53 Resolver endpoints for hybrid DNS.

Show answer & explanation

Answer: Use VMware HCX Bulk Migration for the $40$ application VMs and VMware HCX Replication Assisted vMotion (RAV) for the $2$ database VMs. Configure VMware Transit Connect (VTGW) for the SDDC, peer VTGW with the customer-managed TGW, and associate the DXGW with both VTGW and the customer-managed TGW. Associate the Route 53 PHZs in Account B with the SDDC's connected VPC, and configure Route 53 Resolver outbound endpoints to forward on-premises DNS queries.

Answer

Use VMware HCX Bulk Migration for the application servers and VMware HCX Replication Assisted vMotion (RAV) for the databases. Configure VMware Transit Connect (VTGW), peer it with the customer-managed TGW, and associate the Direct Connect Gateway (DXGW) with both VTGW and the customer-managed TGW. Associate the Route 53 Private Hosted Zones in Account B with the SDDC's connected VPC, and configure Route 53 Resolver outbound endpoints to forward on-premises DNS queries.

The correct solution correctly maps the migration tools to the workload requirements: HCX Bulk Migration is ideal for parallel, low-downtime replication of the

40

application VMs, and HCX Replication Assisted vMotion (RAV) ensures zero-downtime live migration for the database VMs. For networking, associating the Direct Connect Gateway (DXGW) with both VMware Transit Connect and the customer-managed Transit Gateway is required because AWS Transit Gateway peering does not support transitive routing to/from a DXGW. Finally, associating the Route 53 Private Hosted Zones in Account B with the SDDC's connected VPC in Account A allows the SDDC VMs to resolve internal AWS domain names, and Route 53 Resolver endpoints enable hybrid DNS resolution.

Step-by-Step Solution

Determine the appropriate migration technique for each workload tier based on downtime requirements.

Identify that the

40

application VMs can use HCX Bulk Migration since they tolerate a reboot, whereas the

2

database VMs require Replication Assisted vMotion (RAV) to achieve live migration with zero downtime.

HCX Bulk Migration replicates data in parallel and executes a cold switchover (reboot), while RAV combines replication with vMotion to perform a hot switchover with no downtime.

Design the network routing architecture between VMware Cloud on AWS, native AWS VPCs, and on-premises.

Deploy VMware Transit Connect (VTGW), peer it with the customer-managed AWS Transit Gateway (TGW), and associate the Direct Connect Gateway (DXGW) to both VTGW and the customer TGW.

AWS Transit Gateway peering does not support transitive routing to/from a Direct Connect Gateway. Therefore, to ensure on-premises connectivity for both SDDC and native VPCs, the DXGW must be directly associated with both Transit Gateways.

Configure DNS resolution for the hybrid multi-account environment.

Associate the Route 53 Private Hosted Zones (PHZs) in Account B with the SDDC's connected VPC in Account A, and configure Route 53 Resolver endpoints for hybrid DNS forwarding.

Since SDDC VMs query the Amazon Provided DNS (169.254.169.253) of the connected VPC, the PHZs must be associated with the connected VPC to resolve native AWS DNS names.

Key Concept

Designing hybrid VMware migrations and multi-account connectivity using HCX, VMware Transit Connect, Transit Gateway peering, and Route 53 Resolver associations while adhering to transitive routing limits.

Estimated Time:3m 0s

Question 1738Question →

A company is designing a new financial reporting platform. The platform requires a database to handle a bursty OLTP transaction history workload with dynamic, auto-scaling read capability. For caching, the application requires sub-key eviction, persistence, and Multi-AZ replication. Finally, financial reports must be exported to an Amazon S3 bucket located in a separate, dedicated audit AWS account. These exports must be encrypted at rest using key material controlled by the company, and the audit account must have permissions to immediately read the files. Which two database and storage configurations should a Solutions Architect select to satisfy these requirements?

Select all that apply

Deploy an Amazon Aurora PostgreSQL DB cluster with Auto Scaling enabled for Aurora Replicas to handle read traffic spikes, and provision Amazon ElastiCache for Redis with Multi-AZ enabled for caching.

Configure the S3 bucket to use server-side encryption with AWS KMS Customer Managed Keys (SSE-KMS), and configure cross-account access by updating both the S3 bucket policy and the KMS key policy in the primary account.

Deploy an Amazon RDS for PostgreSQL DB instance in a Multi-AZ deployment and configure the standby replica to serve read traffic during query bursts, alongside Amazon ElastiCache for Memcached.

Store the reporting exports in the audit S3 bucket encrypted with the AWS-managed KMS key for Amazon S3 (aws/s3), and configure cross-account access by modifying the default KMS policy to trust the audit account.

Deploy an Amazon Aurora PostgreSQL DB cluster with Multi-AZ, and configure Amazon ElastiCache for Memcached to provide persistent caching and sub-key eviction controls.

Show answer & explanation

Answer: Deploy an Amazon Aurora PostgreSQL DB cluster with Auto Scaling enabled for Aurora Replicas to handle read traffic spikes, and provision Amazon ElastiCache for Redis with Multi-AZ enabled for caching.; Configure the S3 bucket to use server-side encryption with AWS KMS Customer Managed Keys (SSE-KMS), and configure cross-account access by updating both the S3 bucket policy and the KMS key policy in the primary account.

Answer

Deploying an Amazon Aurora PostgreSQL DB cluster with Auto Scaling for Aurora Replicas alongside Amazon ElastiCache for Redis, and encrypting the S3 exports using Customer Managed Keys (CMKs) with appropriate cross-account policies.

The correct configurations involve using Amazon Aurora PostgreSQL because Aurora Replicas can serve reads and auto-scale dynamically, and Amazon ElastiCache for Redis because it satisfies the persistence and sub-key eviction requirements. For S3 encryption, using a Customer Managed Key (CMK) with SSE-KMS is necessary for cross-account S3 access because AWS-managed keys cannot be shared cross-account, and both S3 bucket policies and key policies must explicitly permit access.

Step-by-Step Solution

Select the appropriate database and caching engines.

Amazon Aurora PostgreSQL with auto-scaled Aurora Replicas is selected for handling bursty OLTP read workloads. Amazon ElastiCache for Redis is selected to fulfill persistence, replication, and sub-key eviction requirements.

Aurora Replicas, unlike RDS Multi-AZ standby instances, can actively serve read traffic and auto-scale. Redis supports persistence and sub-key eviction, which Memcached does not.

Determine the S3 encryption and cross-account access mechanism.

An S3 bucket is configured with SSE-KMS using a Customer Managed Key (CMK), with policies updated to grant cross-account access.

AWS-managed KMS keys (like aws/s3) cannot be shared across accounts. A customer-managed CMK must be used, and its key policy along with the S3 bucket policy must allow access to the external audit account.

Key Concept

Selecting appropriate database replication and caching mechanisms, and configuring secure cross-account storage encryption.

Question 1739Question →

A healthcare software company is designing a new patient record archiving platform. The application stores high-resolution medical scan files as object storage and a metadata catalog as an OLTP database. The metadata database must support read operations across two AWS Regions with a disaster recovery target of near-zero RPO and an RTO of under $1 \text{ minute}$ . The system must automatically scale read capacity during peak query hours. Additionally, the scan files must be shared securely with an external auditor's AWS account, requiring encryption using keys that support cross-account policy delegation. Which database and storage strategy meets these requirements?

Deploy a single-region Amazon Aurora PostgreSQL database. Configure AWS Backup to take hourly database snapshots and replicate them to the secondary Region. In a disaster recovery event, use a Pilot Light strategy to restore the database in the secondary Region. Store the medical scan files in Amazon S3 buckets in both Regions, configured with S3 Cross-Region Replication (CRR).

Deploy Amazon RDS for PostgreSQL with Multi-AZ configured across two Regions. Configure the standby DB instance to serve read traffic and auto-scale dynamically during peak hours. Store the medical scan files in Amazon S3 buckets in both Regions, configured with S3 Cross-Region Replication (CRR) and encrypted using Customer Managed Keys (CMKs).

Deploy an Amazon Aurora Global Database. Use Aurora Auto Scaling to dynamically adjust the number of Aurora Replicas in both Regions. Store the medical scan files in Amazon S3 buckets in both Regions, configured with S3 Cross-Region Replication (CRR) and encrypted using Customer Managed Keys (CMKs) with key policies that allow cross-account access.

Deploy an Amazon Aurora Global Database. Use Aurora Auto Scaling to dynamically adjust the number of Aurora Replicas in both Regions. Store the medical scan files in Amazon S3 buckets in both Regions, configured with S3 Cross-Region Replication (CRR) and encrypted using the default AWS managed key (aws/s3), allowing the external auditor to access the files via S3 bucket policies.

Show answer & explanation

Answer: Deploy an Amazon Aurora Global Database. Use Aurora Auto Scaling to dynamically adjust the number of Aurora Replicas in both Regions. Store the medical scan files in Amazon S3 buckets in both Regions, configured with S3 Cross-Region Replication (CRR) and encrypted using Customer Managed Keys (CMKs) with key policies that allow cross-account access.

Answer

Deploy an Amazon Aurora Global Database, using Aurora Auto Scaling to dynamically scale Aurora Replicas in both Regions. Store the medical scan files in Amazon S3 buckets in both Regions, configured with S3 Cross-Region Replication (CRR) and encrypted using Customer Managed Keys (CMKs) with key policies that allow cross-account access.

The correct option correctly pairs Amazon Aurora Global Database to achieve the required sub-minute RTO and near-zero RPO, utilizes Aurora Auto Scaling to scale read capacity dynamically via Aurora Replicas, and uses Customer Managed Keys (CMKs) to enable cross-account access delegation for the external auditor to decrypt S3 object data.

Step-by-Step Solution

Select the database engine that supports multi-region read capacity scaling and low-latency disaster recovery metrics (RTO < 1 minute, near-zero RPO).

Amazon Aurora Global Database provides sub-second replication latency across regions, satisfying the near-zero RPO and under 1 minute RTO requirements.

Traditional RDS snapshots or standard RDS Multi-AZ deployments do not support cross-region active reads or near-zero RPO with sub-minute failovers.

Configure read scaling mechanisms for the global database.

Apply Aurora Auto Scaling to dynamically adjust the number of Aurora Replicas in both regions based on CPU utilization or connection count.

This offloads read traffic from the primary instance and dynamically scales capacity during peak hours.

Select the encryption and cross-account access strategy for medical scan files in Amazon S3.

Encrypt the S3 buckets with Customer Managed Keys (CMKs) and configure key policies to allow cross-account KMS access for the external auditor.

AWS-managed KMS keys (like aws/s3) cannot be modified to delegate access to other AWS accounts, making customer-managed CMKs mandatory for cross-account sharing.

Key Concept

Selecting and configuring AWS database and storage services to meet specific RTO/RPO, scaling, and cross-account encryption requirements.

Estimated Time:2m 0s

Question 1740Question →

A media broadcasting company is migrating its critical live-stream metadata ingest applications, consisting of 12 legacy servers, from an on-premises data center to AWS using AWS Application Migration Service (MGN). The replication must occur over a private network connection using an AWS Direct Connect (DX) connection with a private virtual interface attached to an AWS Transit Gateway. Due to strict security compliance, neither the on-premises servers nor the staging subnets in the replication VPC can have outbound internet access. Which two configuration steps must a solutions architect perform to establish replication while meeting these requirements? (Select TWO.)

Select all that apply

Configure the AWS MGN replication template to use private IP routing, and deploy interface VPC endpoints (AWS PrivateLink) for AWS MGN and Amazon S3 in the staging area VPC.

Configure the on-premises corporate firewall and the staging area subnet security groups to allow outbound and inbound traffic on TCP port 1500.

Configure the on-premises firewall to permit outbound traffic on TCP port 443 only, as AWS MGN tunnels replication data through the control plane protocol.

Bypass the AWS Transit Gateway by associating the Direct Connect gateway directly with the replication staging area VPC, relying on Direct Connect gateway transitive routing.

Create a Route 53 Private Hosted Zone for the MGN interface endpoints in a central shared services VPC without associating it with the replication staging VPC.

Show answer & explanation

Answer: Configure the AWS MGN replication template to use private IP routing, and deploy interface VPC endpoints (AWS PrivateLink) for AWS MGN and Amazon S3 in the staging area VPC.; Configure the on-premises corporate firewall and the staging area subnet security groups to allow outbound and inbound traffic on TCP port 1500.

Answer

The correct options are configuring the AWS MGN replication template to use private IP routing with interface VPC endpoints for AWS MGN and Amazon S3, and configuring the on-premises firewall and staging area security groups to permit TCP port 1500.

The correct options are: 1) Configuring the replication template to use private IP routing and establishing interface VPC endpoints for MGN and S3. This allows the agents and replication servers to communicate securely and privately with the MGN control plane and download necessary agent components without traversing the public internet. 2) Allowing TCP port 1500 between the source servers and the replication staging area subnets, which is required for transmitting replicated block data.

Step-by-Step Solution

Enable private IP routing in the AWS MGN replication template.

The replication agents will use private IP addresses to communicate with replication servers in the staging VPC.

Neither the on-premises environment nor the staging area subnets have outbound internet access, necessitating private routing over the Direct Connect.

Deploy interface VPC endpoints for AWS MGN and Amazon S3 in the staging VPC.

Private paths are created within the VPC for MGN API calls and software downloads.

The MGN replication agents and servers require secure access to the MGN control plane and S3 to download the replication software.

Allow TCP port 1500 through the on-premises firewall and the staging subnet security groups.

Block-level replication data can flow from the source servers to the replication servers.

AWS MGN replicates block-level data over TCP port 1500, which must be open in transit firewalls and security groups.

Key Concept

Establishing private block-level replication using AWS Application Migration Service (MGN) in a highly secure, non-internet-facing hybrid environment.

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