All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A retail company is designing a new global e-commerce order processing platform. The database must support an OLTP workload with strong transactional consistency, scale read operations automatically during flash sales, and support a disaster recovery strategy with a recovery point objective (RPO) of less than 1 minute and a recovery time objective (RTO) of less than 15 minutes. Additionally, corporate security policy mandates that all data be encrypted at rest using a Customer Managed Key (CMK) owned by a centralized security AWS account. Which database and storage strategy meets these requirements with the lowest operational overhead?

Deploy an Amazon Aurora PostgreSQL Global Database. Encrypt the primary cluster using a Customer Managed Key (CMK) from the centralized security account, and configure cross-region replication to a secondary region using a replica CMK. Enable Aurora Auto Scaling for read replicas in both regions to handle peak read loads, and promote the secondary cluster if the primary region experiences an outage.

Deploy an Amazon Aurora PostgreSQL Global Database. Encrypt the primary cluster using the default AWS-managed KMS key (aws/rds). Share the primary cluster with the secondary region by updating the default key policy to allow cross-account access for the database service roles, and configure Aurora Auto Scaling for read replicas.

Deploy an Amazon RDS PostgreSQL database in a Multi-AZ configuration with cross-region read replicas. Encrypt the primary instance using a Customer Managed Key (CMK) from the centralized security account. Configure the primary DB instance's passive standby replica in the secondary Availability Zone to automatically scale and accept read traffic to handle sudden spikes.

Deploy a single-region Amazon Aurora PostgreSQL cluster encrypted with a Customer Managed Key (CMK) from the centralized security account. Implement a pilot light disaster recovery solution by copying automated database snapshots hourly to the secondary region, and maintain a pre-provisioned, scaled-down database instance in the secondary region to restore snapshots during failover.

Show answer & explanation

Answer: Deploy an Amazon Aurora PostgreSQL Global Database. Encrypt the primary cluster using a Customer Managed Key (CMK) from the centralized security account, and configure cross-region replication to a secondary region using a replica CMK. Enable Aurora Auto Scaling for read replicas in both regions to handle peak read loads, and promote the secondary cluster if the primary region experiences an outage.

Answer

Deploy an Amazon Aurora PostgreSQL Global Database, encrypting the primary cluster with a Customer Managed Key (CMK) from the centralized security account, using a replica CMK in the secondary region, configuring Aurora Auto Scaling for read replicas, and promoting the secondary cluster during a failover.

The correct strategy leverages Amazon Aurora Global Database to achieve low-latency cross-region replication (RPO < 1 second) and fast region promotion (RTO < 1 minute). By utilizing Customer Managed Keys (CMKs) rather than AWS-managed keys, the key policies can be updated to delegate cross-account use by the database cluster service roles. Aurora Auto Scaling dynamically manages read replica capacity across multiple Availability Zones to handle read spikes during peak hours.

Step-by-Step Solution

Analyze database performance, transactional consistency, and scalability requirements.

The platform requires an OLTP database supporting strong consistency and automated read scaling. Amazon Aurora PostgreSQL supports these capabilities natively.

Aurora offers up to 15 read replicas with Auto Scaling and provides ACID-compliant OLTP execution.

Evaluate disaster recovery requirements (RPO < 1 minute, RTO < 15 minutes).

Amazon Aurora Global Database provides sub-second replication latency (RPO < 1 second) and can be promoted to a primary region in under a minute (RTO < 1 minute).

This exceeds the business requirements while keeping operational overhead minimal compared to snapshot restoration.

Assess security and KMS encryption mandates for a multi-account structure.

A Customer Managed Key (CMK) must be used because it supports key policy delegation, allowing cross-account sharing and replication of encrypted snapshots or storage volumes. A replica CMK is deployed in the secondary region.

AWS-managed keys (aws/rds) cannot be modified or shared across different AWS accounts, rendering them unusable for this design.

Key Concept

Amazon Aurora Global Database architecture combined with cross-account AWS KMS Customer Managed Keys (CMKs) to satisfy high-availability, scalability, and strict security compliance mandates.

Estimated Time:2m 0s

Question 382Question →

A solutions architect is migrating an on-premises Oracle database to an Amazon Aurora PostgreSQL-Compatible Edition DB cluster using AWS Database Migration Service (AWS DMS) and the AWS Schema Conversion Tool (AWS SCT). The solutions architect successfully converts the schema, creates the target tables, and configures an AWS DMS task with full load and Change Data Capture (CDC) enabled. The full load phase completes successfully, but the replication task immediately fails and stalls upon transitioning to the CDC phase. Which two actions should the solutions architect take to resolve this issue and resume replication? (Select two.)

Select all that apply

Enable minimal supplemental logging at the database level and add supplemental logging for primary keys on all tables selected for replication on the source Oracle database.

Configure the source Oracle database in ARCHIVELOG mode and ensure that archived redo logs are retained on the source server for a sufficient duration, such as at least 24 hours.

Enable logical replication on the target Aurora PostgreSQL DB cluster by setting the rds.logical_replication parameter to 1 in the DB parameter group.

Install and configure the AWS Schema Conversion Tool (AWS SCT) agent on an EC2 instance in the same VPC as the replication instance to capture transactions from the Oracle database log writer (LGWR).

Create a new AWS DMS task with the replication type set to replicate data changes only, and configure the task to start from the current Oracle System Change Number (SCN) without enabling supplemental logging on the source.

Show answer & explanation

Answer: Enable minimal supplemental logging at the database level and add supplemental logging for primary keys on all tables selected for replication on the source Oracle database.; Configure the source Oracle database in ARCHIVELOG mode and ensure that archived redo logs are retained on the source server for a sufficient duration, such as at least 24 hours.

Answer

Enable minimal supplemental logging at the database level and add supplemental logging for primary keys on all tables selected for replication on the source Oracle database, and configure the source Oracle database in ARCHIVELOG mode and ensure archived redo logs are retained on the source server for a sufficient duration.

The correct configurations involve setting the source Oracle database to ARCHIVELOG mode, retaining the archived redo logs for at least 24 hours, and enabling minimal supplemental logging at the database level along with primary key supplemental logging on the replicated tables. These steps ensure that the Oracle database writes the changed data values to its transaction logs and keeps them available for AWS DMS to read during the CDC phase.

Step-by-Step Solution

Analyze the failure mode of the AWS DMS CDC task.

The task successfully completes the full load phase but fails immediately upon starting the CDC phase, which suggests a failure to read source transaction logs.

DMS CDC for Oracle source relies on reading redo logs and archived logs. If they are not configured correctly, the task fails immediately when transitioning to replication.

Verify Oracle source database logging configuration.

Supplemental logging is missing or not enabled for the primary keys of the tables, and the database must be in ARCHIVELOG mode.

Without supplemental logging, Oracle does not write the necessary columns to the redo logs for DMS to reconstruct the changes.

Identify the correct logging configurations required for the migration.

Enable minimal supplemental logging, enable supplemental logging for primary keys, configure ARCHIVELOG mode, and retain archived redo logs.

These steps ensure that transaction log details are preserved and accessible by AWS DMS for ongoing replication.

Key Concept

Replication log requirements for AWS DMS CDC from an Oracle source

Question 383Question →

An enterprise has a multi-account AWS environment with VPCs in the us-east-1 and us-west-2 regions. Each region contains an AWS Transit Gateway (TGW-East and TGW-West), and the two Transit Gateways are peered. The on-premises datacenter uses the IP address range $172.16.0.0/12$ .

The datacenter connects to AWS using a Direct Connect Gateway (DXGW) associated with both Transit Gateways via Transit Virtual Interfaces (VIFs). As a backup, AWS Site-to-Site VPN connections are established from the datacenter directly to both TGW-East and TGW-West.

The Solutions Architect must design a routing policy for us-east-1 spoke VPCs to access the $172.16.0.0/12$ network. The policy must prioritize the paths in the following order:
1. Primary: The local Direct Connect link via TGW-East.
2. Secondary: The local backup Site-to-Site VPN via TGW-East.
3. Tertiary: The peered TGW link to TGW-West, then via the us-west-2 Direct Connect link.

Additionally, traffic from the datacenter to the us-east-1 VPCs must prefer the Direct Connect link over the VPN link.

Which TWO configurations should the Solutions Architect implement to meet these requirements?

Select all that apply

Configure a static route for

172.0.0.0/8

pointing to the TGW peering attachment in the TGW-East route table, and enable route propagation for the local Direct Connect Gateway and VPN attachments to dynamically learn the

172.16.0.0/12

prefix.

Configure the on-premises customer gateway router to assign a higher BGP Local Preference value to routes received from AWS via the Direct Connect connection than those received via the Site-to-Site VPN.

Configure a static route for

172.16.0.0/12

pointing to the TGW peering attachment in the TGW-East route table, and configure the route propagation for the local Direct Connect Gateway and VPN attachments.

Enable dynamic BGP route propagation for the TGW peering attachment in TGW-East, allowing TGW-West to advertise the

172.16.0.0/12

prefix with a larger AS-Path attribute than the local VPN connection.

Deploy a single NAT Gateway in a public subnet of the us-east-1 VPCs, and route all outbound on-premises traffic through it to translate the source IP to a public IP before reaching the peered TGW connection.

Show answer & explanation

Answer: Configure a static route for $172.0.0.0/8$ pointing to the TGW peering attachment in the TGW-East route table, and enable route propagation for the local Direct Connect Gateway and VPN attachments to dynamically learn the $172.16.0.0/12$ prefix.; Configure the on-premises customer gateway router to assign a higher BGP Local Preference value to routes received from AWS via the Direct Connect connection than those received via the Site-to-Site VPN.

Answer

Configure a static route for

172.0.0.0/8

pointing to the TGW peering attachment in the TGW-East route table, and enable route propagation for the local Direct Connect Gateway and VPN attachments. Also, configure the on-premises customer gateway router to assign a higher BGP Local Preference value to routes received from AWS via the Direct Connect connection than those received via the Site-to-Site VPN.

The correct architecture uses a summarized static route (such as

172.0.0.0/8

) in the local Transit Gateway route table pointing to the peering attachment. This ensures that the local Direct Connect and VPN dynamic advertisements for

172.16.0.0/12

take priority due to longest prefix match. If both local paths fail, the dynamic routes are withdrawn, and traffic falls back to the peering attachment. Additionally, configuring a higher BGP Local Preference on the on-premises router for routes learned via Direct Connect ensures that return traffic from the customer network to AWS prefers the Direct Connect path over the backup VPN.

Step-by-Step Solution

Analyze Transit Gateway route preference rules.

Static routes always take precedence over dynamically propagated BGP routes of the same prefix length. Therefore, configuring a static route for the exact prefix

172.16.0.0/12

pointing to the peering attachment would incorrectly make the peered path the primary path.

To ensure correct path preference, the peered path must be configured with a less specific prefix (e.g.,

172.0.0.0/8

) so that the more specific dynamic routes (

172.16.0.0/12

) are preferred via longest prefix match.

Evaluate Transit Gateway peering limitations.

TGW peering attachments do not support dynamic routing or BGP propagation. Routes across peering links must be configured statically.

This rules out any options proposing BGP propagation or dynamic advertisements over TGW peering.

Determine path selection for on-premises to AWS traffic.

To make the customer gateway router prefer the Direct Connect path for outbound traffic to AWS, BGP Local Preference should be set higher for the Direct Connect routes on the customer's on-premises router.

BGP Local Preference is an administrative attribute used within an Autonomous System (AS) to select the outbound exit point.

Key Concept

AWS Transit Gateway route evaluation order and TGW peering static routing constraints.

Question 384Question →

A media streaming company is setting up centralized logging for its multi-account AWS environment consisting of $20$ member accounts managed by AWS Organizations. The security team wants to store all AWS CloudTrail logs in a single Amazon S3 bucket located within a dedicated Security account. The security team also requires that the logs be encrypted at rest using an AWS KMS key that they manage. Which combination of configuration steps will allow AWS CloudTrail to successfully deliver the encrypted logs to the centralized S3 bucket?

Configure the S3 bucket policy in the Security account to grant s3:PutObject permissions to the root user of each member account. Create a customer managed KMS key in the Security account with a key policy that grants kms:GenerateDataKey* permissions to the member accounts' root ARNs, and configure the trails in each member account to write to the bucket.

Configure the S3 bucket policy in the Security account to grant s3:PutObject permissions to the cloudtrail.amazonaws.com service principal, conditioned on the AWS Organization ID. Create a customer managed KMS key in the Security account with a key policy that allows the cloudtrail.amazonaws.com service principal to use the kms:GenerateDataKey* and kms:DescribeKey actions, and configure the organization trail to use this key.

Configure the S3 bucket policy in the Security account to grant s3:PutObject permissions to the cloudtrail.amazonaws.com service principal, conditioned on the AWS Organization ID. Configure the organization trail to encrypt the logs using the default AWS-managed key for CloudTrail (aws/cloudtrail) in the Security account, and update its key policy to allow cross-account access.

Attach a Service Control Policy (SCP) to the organization root that allows member accounts' CloudTrail services to write to the centralized S3 bucket. Create a customer managed KMS key in the Security account, and configure the trail to use it by granting the member accounts' IAM admin roles permission to access the KMS key.

Show answer & explanation

Answer: Configure the S3 bucket policy in the Security account to grant s3:PutObject permissions to the cloudtrail.amazonaws.com service principal, conditioned on the AWS Organization ID. Create a customer managed KMS key in the Security account with a key policy that allows the cloudtrail.amazonaws.com service principal to use the kms:GenerateDataKey* and kms:DescribeKey actions, and configure the organization trail to use this key.

Answer

Configure the S3 bucket policy to allow the cloudtrail.amazonaws.com service principal to write logs, and use a customer managed KMS key with a key policy allowing the cloudtrail.amazonaws.com service principal to generate data keys.

The correct option is correct because cross-account CloudTrail log delivery requires granting permissions to the cloudtrail.amazonaws.com service principal in both the S3 bucket policy and the KMS key policy. A customer managed KMS key must be used because default AWS-managed keys (such as aws/cloudtrail) cannot be shared across accounts or have their key policies altered.

Step-by-Step Solution

Determine S3 permissions required for CloudTrail.

The target S3 bucket policy in the central Security account must explicitly allow the 'cloudtrail.amazonaws.com' service principal to perform 's3:PutObject' actions, restricted to the organization's accounts using condition keys like 'aws:PrincipalOrgID'.

CloudTrail writes logs as a service principal, which requires direct resource-based policy allowance to write cross-account.

Select the correct KMS key type for cross-account encryption.

Create a Customer Managed Key (CMK) in the central Security account, as AWS-managed keys (like aws/cloudtrail) are restricted to single-account usage and their key policies cannot be modified.

Cross-account access to KMS keys requires custom key policies that can only be defined on Customer Managed Keys.

Configure the KMS key policy to permit CloudTrail usage.

Grant the 'cloudtrail.amazonaws.com' service principal the permissions to run 'kms:GenerateDataKey*' and 'kms:DescribeKey' in the KMS key policy.

CloudTrail must be able to generate data keys using the KMS key to encrypt the log objects before delivering them to S3.

Key Concept

Cross-account AWS CloudTrail log consolidation requires configuring resource policies (S3 bucket policy and KMS key policy) to trust the cloudtrail.amazonaws.com service principal. A Customer Managed Key (CMK) is mandatory because AWS-managed keys cannot be shared cross-account.

Estimated Time:2m 0s

Question 385Question →

An enterprise is configuring federated single sign-on (SSO) for its systems administrators using PingFederate as an external SAML 2.0 Identity Provider (IdP). The administrators must be able to authenticate and access a shared development account in their AWS Organizations. You need to configure the trust relationship in AWS so that the PingFederate IdP can exchange SAML assertions for temporary AWS credentials.

Which of the following configuration steps must be performed in the target AWS account to successfully establish this federation? (Select TWO.)

Select all that apply

Create a SAML identity provider in IAM using the metadata document generated by PingFederate.

Create an IAM role with a trust policy that grants assume role permissions to the SAML provider ARN using the sts:AssumeRoleWithSAML action.

Configure the IAM role trust policy to allow the sts:AssumeRole action for the federated PingFederate entity.

Attach a Service Control Policy (SCP) to the target account's Organization Unit (OU) that explicitly grants sts:AssumeRoleWithSAML access to the external identity provider.

Show answer & explanation

Answer: Create a SAML identity provider in IAM using the metadata document generated by PingFederate.; Create an IAM role with a trust policy that grants assume role permissions to the SAML provider ARN using the sts:AssumeRoleWithSAML action.

Answer

To configure SAML 2.0 federation, you must create a SAML identity provider in IAM using the PingFederate metadata document, and create an IAM role with a trust policy that specifies the SAML provider as the principal and allows the sts:AssumeRoleWithSAML action.

To establish SAML federation, AWS IAM requires a SAML identity provider object containing the external provider's metadata, and an IAM role with a trust policy that specifically allows the action 'sts:AssumeRoleWithSAML' with the SAML provider as the principal.

Step-by-Step Solution

Download the SAML metadata document from PingFederate.

A metadata XML file containing the identity provider's configuration and certificates.

This document is required by AWS to establish a trust relationship with the PingFederate server.

Create the SAML identity provider in the target AWS account's IAM console or via the CLI using the metadata document.

An IAM SAML provider resource with an ARN representing the PingFederate IdP.

This establishes the trust relationship between AWS IAM and the external IdP.

Create an IAM role with a trust policy referencing the SAML provider's ARN as the Principal and specifying the action sts:AssumeRoleWithSAML.

An IAM role that federated users can assume upon successful authentication at the IdP.

This allows the PingFederate IdP to assume the role using SAML assertions and obtain temporary credentials.

Key Concept

Establishing trust for external SAML 2.0 Identity Providers (IdP) in AWS IAM using SAML metadata and IAM role trust policies.

Question 386Question →

A pharmaceutical company is migrating its core inventory management system, consisting of 10 on-premises virtual machines, to AWS using AWS Application Migration Service (MGN). The migration network path utilizes a secure IPSec VPN connection terminating on an AWS Transit Gateway, which is associated with a staging VPC. After installing the AWS Replication Agent on the source servers, the replication status displays as stalled. The on-premises network monitoring tools show that the replication agents are failing to communicate with the replication servers in the staging VPC subnet. Which of the following is the most direct and necessary configuration change to resolve this replication issue?

Adjust the on-premises firewall policies to permit outbound traffic on TCP port 1500 to the staging subnet CIDR, and configure the staging area's security group to allow inbound traffic on TCP port 1500 from the on-premises network.

Modify the Transit Gateway route tables to establish transitive VPC-to-VPC routing for the replication traffic, and replace the VPN with a Direct Connect gateway configuration to handle the data flow without Transit Gateway attachment.

Create a Route 53 private hosted zone for the MGN replication endpoint in the staging VPC, and ensure that this private hosted zone is associated with all local and remote VPCs to resolve the endpoint address.

Deploy a single NAT Gateway in the staging VPC to route the replication traffic, and update the routing tables of all staging subnets to route outbound replication traffic destined for the on-premises network through this NAT Gateway.

Show answer & explanation

Answer: Adjust the on-premises firewall policies to permit outbound traffic on TCP port 1500 to the staging subnet CIDR, and configure the staging area's security group to allow inbound traffic on TCP port 1500 from the on-premises network.

Answer

AWS Application Migration Service uses TCP port 1500 for continuous replication of data blocks from the on-premises AWS Replication Agent to the replication servers in the staging area. Restricting this port blocks the replication stream, causing a stalled state. Adjusting the on-premises firewall and staging area security group resolves this block.

Step-by-Step Solution

Identify the data replication port required by the AWS Replication Agent.

Determine that the AWS Replication Agent requires TCP port 1500 to communicate with the replication servers.

This is the default and mandatory port used by AWS Application Migration Service for data transit.

Examine firewall configurations on both the source and destination networks.

Identify that the firewall on-premises and the staging area security groups must explicitly allow TCP port 1500 traffic.

Security controls must be aligned to prevent packets from being dropped at either end of the VPN tunnel.

Apply the rule changes to allow communication.

The replication agent establishes a connection, changing the replication status from stalled to active synchronization.

Allowing the port permits the control and data channel to be successfully initialized.

Key Concept

Replication Agent network requirements for AWS Application Migration Service (MGN)

Question 387Question →

An online education platform leverages AWS Organizations to manage $48$ member accounts. To meet strict regulatory standards, the platform's security team needs to implement centralized auditing by consolidating AWS CloudTrail logs from all member accounts into a secure, dedicated Amazon S3 bucket within a centralized Security account. The logs must be encrypted at rest using a key managed by the platform's security team. The setup must ensure that individual member accounts can deliver logs to the central bucket but cannot access or decrypt logs from other accounts. Which configuration strategy should the solutions architect recommend to satisfy these requirements?

Configure an Organization Trail in the management account that delivers logs to an Amazon S3 bucket in the Security account. Create a customer managed KMS key in the Security account, and update its key policy to allow the AWS CloudTrail service principal to perform 'kms:GenerateDataKey*' and 'kms:DescribeKey' operations with a condition restricting access to the organization's ID. Configure the S3 bucket policy in the Security account to grant 's3:PutObject' permissions to the CloudTrail service principal with a condition for the organization's ID.

Configure an Organization Trail in the management account that delivers logs to an Amazon S3 bucket in the Security account. Enable encryption on the target S3 bucket using the default AWS managed KMS key (aws/s3) in the Security account to avoid the overhead of custom key policy maintenance, as AWS managed keys automatically permit cross-account log delivery by CloudTrail.

Configure an Organization Trail in the management account that delivers logs to an Amazon S3 bucket in the Security account. Instead of modifying the S3 bucket policy in the Security account, configure local IAM roles in each member account with write permissions to the central S3 bucket, and configure CloudTrail to assume these roles in each respective account to perform log delivery.

Configure an Organization Trail in the management account that delivers logs to an Amazon S3 bucket in the Security account. Attach a Service Control Policy (SCP) to the organization's root that explicitly grants 's3:PutObject' permissions on the Security account's S3 bucket to all member accounts, eliminating the need to modify the S3 bucket policy in the Security account.

Show answer & explanation

Answer: Configure an Organization Trail in the management account that delivers logs to an Amazon S3 bucket in the Security account. Create a customer managed KMS key in the Security account, and update its key policy to allow the AWS CloudTrail service principal to perform 'kms:GenerateDataKey*' and 'kms:DescribeKey' operations with a condition restricting access to the organization's ID. Configure the S3 bucket policy in the Security account to grant 's3:PutObject' permissions to the CloudTrail service principal with a condition for the organization's ID.

Answer

Configure an Organization Trail in the management account that delivers logs to an Amazon S3 bucket in the Security account, utilizing a customer managed KMS key in the Security account with a key policy allowing the CloudTrail service principal, and configuring S3 bucket policy permissions for the CloudTrail service principal.

An Organization Trail consolidates log delivery across the AWS Organization. For security-account S3 buckets, the bucket policy must grant 's3:PutObject' permissions to the CloudTrail service principal. When encrypting using KMS, a customer managed key is required because AWS managed KMS keys cannot be shared across accounts or have their key policies edited to allow cross-account write access from CloudTrail.

Step-by-Step Solution

Analyze the requirements for centralized logging across a multi-account AWS Organization.

Identify that AWS CloudTrail Organization Trails can write logs from all member accounts directly to a centralized S3 bucket in a Security account.

This avoids having to manually configure individual trails in each member account, ensuring compliance and centralizing management.

Determine the S3 bucket policy requirements for cross-account log delivery.

The target S3 bucket policy must allow 's3:PutObject' permissions for the CloudTrail service principal ('cloudtrail.amazonaws.com') with conditions specifying the Organization ID.

AWS CloudTrail writes logs directly using its service principal, which needs explicit write access in the destination bucket policy.

Evaluate the encryption requirements (customer managed key vs AWS managed key).

Select a customer managed KMS key and configure its key policy to grant the CloudTrail service principal 'kms:GenerateDataKey*' and 'kms:DescribeKey' permissions.

AWS-managed keys (like 'aws/s3') cannot be shared cross-account or have their policies modified, meaning they cannot support cross-account CloudTrail log encryption.

Key Concept

Cross-account AWS CloudTrail logging requires a combination of S3 bucket policies and custom KMS key policies that permit the CloudTrail service principal to write and encrypt logs from all member accounts.

Question 388Question →

An organization needs to migrate $150\text{ TB}$ of unstructured media files from an on-premises SFTP server to an Amazon S3 bucket located in a separate, newly created AWS account. The organization has a dedicated $100\text{ Mbps}$ internet connection available for this migration, and the entire transfer must be completed within $21$ days. Active clients must continue to upload new files to the SFTP service during the migration, and the migration must not require client-side configuration or hostname changes. All migrated data must be encrypted at rest in the target S3 bucket using AWS Key Management Service (AWS KMS). Which strategy should a solutions architect recommend to meet these requirements?

Deploy AWS DataSync agents on-premises to transfer the

150\text{ TB}

of historical data directly over the

100\text{ Mbps}

internet connection to the destination Amazon S3 bucket. Create an AWS Transfer Family SFTP endpoint in the target account, and associate it with the S3 bucket. Update the public DNS record of the SFTP hostname to point to the Transfer Family endpoint.

Order two AWS Snowball Edge Storage Optimized devices to transfer the

150\text{ TB}

of historical data. Configure the destination Amazon S3 bucket to use the default AWS-managed KMS key (`aws/s3`) for encryption. Set up AWS Transfer Family in the target account, grant the SFTP service role cross-account access to the bucket, and update the DNS record to point to the new Transfer Family endpoint.

Order two AWS Snowball Edge Storage Optimized devices to transfer the

150\text{ TB}

of historical data. Create an AWS Customer Managed Key (CMK) in the target account, configure its key policy to allow cross-account access, and encrypt the destination Amazon S3 bucket with it. Create an AWS Transfer Family SFTP endpoint associated with the S3 bucket, and update the DNS record to point to the Transfer Family endpoint.

Order two AWS Snowball Edge Storage Optimized devices. Establish an AWS Transit Gateway VPN connection over the

100\text{ Mbps}

internet connection. Deploy AWS DataSync agents to mount the Snowball Edge devices on-premises and sync the data over the VPN to S3, using Transit Gateway for cross-account routing. Associate AWS Transfer Family with the S3 bucket and update the DNS record.

Show answer & explanation

Answer: Order two AWS Snowball Edge Storage Optimized devices to transfer the $150\text{ TB}$ of historical data. Create an AWS Customer Managed Key (CMK) in the target account, configure its key policy to allow cross-account access, and encrypt the destination Amazon S3 bucket with it. Create an AWS Transfer Family SFTP endpoint associated with the S3 bucket, and update the DNS record to point to the Transfer Family endpoint.

Answer

Order two AWS Snowball Edge Storage Optimized devices to transfer the historical data, encrypt the destination Amazon S3 bucket with a Customer Managed Key (CMK) configured for cross-account access, and deploy an AWS Transfer Family SFTP endpoint to handle client uploads using the existing hostname via a DNS update.

The correct strategy uses AWS Snowball Edge Storage Optimized devices for the bulk migration because transferring

150\text{ TB}

over a

100\text{ Mbps}

connection would take approximately

139

days, violating the

21

-day timeline. Cross-account access to the target Amazon S3 bucket requires encrypting the bucket with an AWS KMS Customer Managed Key (CMK), as the default AWS-managed KMS key (`aws/s3`) cannot be shared across accounts or have its key policy modified. AWS Transfer Family hosting the SFTP endpoint allows clients to connect using the same hostname via a DNS update, ensuring no client-side changes are required.

Step-by-Step Solution

Calculate network transfer time to determine if online migration is possible.

Transferring

150\text{ TB}

over a

100\text{ Mbps}

link takes

\approx 139

days, which is far greater than the

21

-day migration window. Therefore, an offline migration using AWS Snowball Edge is required.

Ensures that the timeline constraint is verified before selecting the data transfer mechanism.

Evaluate KMS encryption requirements for cross-account data transfer.

AWS-managed KMS keys like `aws/s3` cannot have their key policies edited and cannot be shared across accounts. A Customer Managed Key (CMK) must be created in the target account to allow the cross-account role/user to write and decrypt data.

Ensures compliance and security policies are met while allowing cross-account ingestion.

Configure AWS Transfer Family and DNS routing to allow continuous uploads.

Deploy an AWS Transfer Family SFTP server endpoint associated with the S3 bucket in the target account. Update the DNS CNAME record of the SFTP domain to resolve to the new endpoint, preserving the hostname for clients.

Allows seamless cutover of client application uploads without requiring configuration changes on the client side.

Key Concept

Selecting the optimal hybrid data transfer service based on bandwidth constraints, cross-account security limitations of KMS keys, and endpoint protocol migration using AWS Transfer Family.

Estimated Time:2m 0s

Question 389Question →

A multinational enterprise is migrating its vSphere-based workloads to a VMware Cloud on AWS Software-Defined Data Center (SDDC) linked to a multi-account AWS environment. The workloads to migrate consist of:

1. A production cluster of $12$ critical database virtual machines (VMs) that must remain online during the initial data synchronization phase and experience near-zero downtime during the final switchover.
2. A development and testing environment consisting of $150$ VMs that can tolerate up to $3$ hours of downtime during a scheduled cutover window.

The enterprise has configured a $10\text{ Gbps}$ AWS Direct Connect connection to the on-premises data center.
Additionally, the migrated VMs in the SDDC must resolve internal service endpoints in a Private Hosted Zone (PHZ) for `corp.local` hosted in a Shared Services VPC in a separate AWS account. The SDDC is connected to this Shared Services VPC using VMware Cloud on AWS Transit Connect.

Which two actions should the solutions architect take to meet these requirements? (Select two.)

Select all that apply

Configure VMware HCX Replication Assisted vMotion (RAV) to migrate the

12

database VMs to achieve parallel replication and live switchover, and use VMware HCX Bulk Migration to migrate the

150

development and testing VMs in scheduled waves.

Deploy Route 53 Resolver Inbound Endpoints in the Shared Services VPC, and configure the SDDC DNS Forwarder in the VMware Cloud Console to route queries for `corp.local` to the IP addresses of the Inbound Endpoints.

Configure VMware HCX Cold Migration for the

12

database VMs to ensure zero write activity during the transfer, and use VMware HCX vMotion to migrate the

150

development and testing VMs concurrently.

Associate the `corp.local` Private Hosted Zone directly with the VMC SDDC management VPC, and configure the migrated VMs to query the AWS default VPC resolver (

169.254.169.253

) of the associated VPC.

Configure a Virtual Private Gateway (VGW) in the Shared Services VPC, attach it to the Direct Connect Gateway (DXGW) used by the SDDC, and configure transitive routing to pass DNS traffic from the SDDC to the Shared Services VPC.

Show answer & explanation

Answer: Configure VMware HCX Replication Assisted vMotion (RAV) to migrate the $12$ database VMs to achieve parallel replication and live switchover, and use VMware HCX Bulk Migration to migrate the $150$ development and testing VMs in scheduled waves.; Deploy Route 53 Resolver Inbound Endpoints in the Shared Services VPC, and configure the SDDC DNS Forwarder in the VMware Cloud Console to route queries for `corp.local` to the IP addresses of the Inbound Endpoints.

Answer

Configure VMware HCX Replication Assisted vMotion (RAV) for the database VMs and VMware HCX Bulk Migration for the development/testing VMs, and deploy Route 53 Resolver Inbound Endpoints in the Shared Services VPC while configuring the SDDC DNS Forwarder to route queries to them.

The correct choices are the options recommending the use of VMware HCX Replication Assisted vMotion (RAV) for the databases and HCX Bulk Migration for the development/testing workloads, alongside deploying Route 53 Resolver Inbound Endpoints in the Shared Services VPC and configuring the SDDC DNS Forwarder. VMware HCX RAV provides parallel replication with a live vMotion switchover, ensuring the database VMs remain online and experience near-zero downtime. HCX Bulk Migration allows efficient, parallel scheduled switchover (with a brief reboot) of the 150 development/testing VMs within their downtime window. For DNS resolution, Route 53 Resolver Inbound Endpoints are required to receive forwarded queries from the VMC SDDC NSX-T DNS forwarder, as VMC subnets cannot query the default Route 53 resolver directly.

Step-by-Step Solution

Analyze the database migration requirements.

The database VMs require zero replication downtime and near-zero downtime during switchover, which points to VMware HCX Replication Assisted vMotion (RAV) or HCX vMotion. However, because there are multiple VMs (

12

) that need parallel replication, RAV is the appropriate choice as standard vMotion replicates serially.

HCX RAV allows parallel replication and scheduling of a live migration switchover, meeting the near-zero downtime and parallel migration needs.

Analyze the development/testing environment migration requirements.

The

150

VMs can tolerate up to

3

hours of downtime. A bulk migration approach is optimal.

HCX Bulk Migration allows parallel replication and scheduled switchover (with a reboot), which is highly efficient for migrating a large volume of non-production VMs that can tolerate downtime.

Determine the DNS resolution architecture.

The migrated VMs in the SDDC need to resolve records in a Private Hosted Zone in the Shared Services VPC. Because Route 53 resolvers do not accept direct queries from outside the local VPC CIDR, the VMC SDDC must forward DNS requests to Route 53 Resolver Inbound Endpoints deployed in the Shared Services VPC.

This enables cross-VPC DNS resolution from the VMC SDDC over the Transit Connect peering connection.

Key Concept

Selecting appropriate VMware HCX migration methods (RAV vs. Bulk) based on downtime requirements and designing cross-account DNS resolution using Route 53 Resolver Inbound Endpoints over VMware Transit Connect.

Question 390Question →

A company is planning to migrate its on-premises VMware vSphere virtual machines (VMs) to native Amazon EC2 instances using AWS Application Migration Service (MGN). The migration network path must utilize an existing $1\text{ Gbps}$ AWS Direct Connect connection with a backup Site-to-Site VPN. The company's compliance policy mandates that replication traffic must be encrypted and remain entirely within a private network path without traversing the public internet. The migration requires a Recovery Point Objective (RPO) of less than $10$ minutes and a replication cutover window with less than $15$ minutes of downtime. During the initial agent deployment, the replication status remains in the 'Establishing connection' state, and data replication cannot start. Security groups and network ACLs are configured to allow HTTPS traffic (TCP port 443) to AWS endpoints. Which network configuration modification will resolve the replication connection issue while adhering to all compliance constraints?

Configure the on-premises firewall and the staging area security groups to allow inbound and outbound traffic over TCP port 1500, and enable the use of private IP addresses for data replication in the AWS MGN replication template.

Configure a Direct Connect public virtual interface to establish connectivity to the AWS MGN public endpoints, and configure the staging area security groups to allow inbound traffic on TCP port 443.

Associate the AWS MGN service endpoints with a Route 53 Private Hosted Zone in a central shared services account, and configure the replication template to use public IP addresses over the Direct Connect private virtual interface.

Configure a Direct Connect Gateway directly to handle the transitive routing of replication traffic between the on-premises VMware environment and the staging VPC, and ensure that TCP port 8080 is open in the on-premises firewall.

Show answer & explanation

Answer: Configure the on-premises firewall and the staging area security groups to allow inbound and outbound traffic over TCP port 1500, and enable the use of private IP addresses for data replication in the AWS MGN replication template.

Answer

Allowing inbound and outbound traffic over TCP port 1500 on the on-premises firewall and staging area security groups, and enabling the use of private IP addresses in the replication template resolves the connection block and routes data replication over the private Direct Connect path, satisfying the security and connectivity compliance constraints.

Step-by-Step Solution

Identify the network ports required by AWS Application Migration Service (MGN) for replication data transfer.

Determine that while control plane traffic uses TCP port 443, the actual data replication traffic from source agents to replication servers in the staging area occurs over TCP port 1500.

Replication will fail to initiate and remain in an 'Establishing connection' state if TCP port 1500 is blocked in the firewalls or security groups.

Analyze compliance requirements regarding the data path of replication traffic.

Determine that traffic must route via private IPs over the Direct Connect connection or VPN to keep the data entirely within the private network path.

By default, MGN replication traffic uses public IP addresses. Setting the replication template to use private IP addresses routes the replication traffic over the private virtual interface (VIF) of the Direct Connect connection.

Key Concept

AWS MGN data replication requires TCP port 1500 to be open between source servers and the staging area, and private IP replication must be enabled to comply with private-path constraints.

Question 391Question →

An enterprise with $85$ member accounts managed under a single organization in AWS Organizations is setting up a centralized logging architecture. The solutions architect is configuring an organization-wide AWS CloudTrail trail to deliver log files to a single Amazon S3 bucket located in a dedicated Log Archive account. To satisfy security policies, all logs must be encrypted at rest using an AWS KMS Customer Managed Key (CMK) managed by the security team, and member account administrators must not be able to disable the trail or modify the logging configurations. Which TWO configurations are required to establish this architecture? (Select TWO.)

Select all that apply

In the Log Archive account, configure the S3 bucket policy to allow the cloudtrail.amazonaws.com service principal to perform s3:PutObject actions, using the aws:PrincipalOrgID condition key to restrict write access to the organization.

Configure the KMS key policy for the Customer Managed Key to allow the cloudtrail.amazonaws.com service principal to perform kms:GenerateDataKey* and kms:DescribeKey operations, using the aws:SourceArn condition to restrict access to the organization's trails.

Enable encryption on the centralized S3 bucket using the default AWS-managed KMS key (aws/s3) and configure a cross-account IAM policy in the member accounts to grant the CloudTrail service principal permissions to use this key.

Configure the S3 bucket policy in the Log Archive account to grant the administrator IAM roles of individual member accounts the s3:PutObject permission to allow them to deliver the CloudTrail logs.

Attach a Service Control Policy (SCP) to the organization's root that explicitly grants cloudtrail:StartLogging and kms:GenerateDataKey permissions to all member accounts to authorize the delivery of encrypted logs.

Show answer & explanation

Answer: In the Log Archive account, configure the S3 bucket policy to allow the cloudtrail.amazonaws.com service principal to perform s3:PutObject actions, using the aws:PrincipalOrgID condition key to restrict write access to the organization.; Configure the KMS key policy for the Customer Managed Key to allow the cloudtrail.amazonaws.com service principal to perform kms:GenerateDataKey* and kms:DescribeKey operations, using the aws:SourceArn condition to restrict access to the organization's trails.

Answer

In the Log Archive account, the S3 bucket policy must allow the CloudTrail service principal to perform s3:PutObject actions restricted by the organization ID, and the KMS Customer Managed Key policy must allow the CloudTrail service principal to generate data keys and describe the key restricted by the trail ARN.

The correct solution involves configuring the S3 bucket policy to allow the CloudTrail service principal to write logs using the aws:PrincipalOrgID condition to secure the bucket across the entire organization. Additionally, since the requirements specify using a Customer Managed Key, the key policy must explicitly allow the CloudTrail service principal to generate data keys and describe the key to encrypt the files upon delivery.

Step-by-Step Solution

Analyze the log delivery mechanism for AWS CloudTrail.

Determine that logs are delivered by the cloudtrail.amazonaws.com service principal directly, not by local IAM users or roles in member accounts.

This establishes that permissions must be granted to the service principal in both S3 bucket policies and KMS key policies.

Configure S3 bucket access control.

Implement an S3 bucket policy in the Log Archive account allowing the CloudTrail service principal to put objects, constrained by the aws:PrincipalOrgID condition to restrict access to the organization.

This prevents unauthorized accounts outside the organization from writing to the centralized bucket while allowing all member accounts to do so.

Configure KMS encryption permissions.

Define a key policy for the Customer Managed Key (CMK) that permits the CloudTrail service principal to perform kms:GenerateDataKey* and kms:DescribeKey actions.

AWS-managed KMS keys do not support cross-account sharing or key policy updates, so a Customer Managed Key is required. The key policy must explicitly authorize CloudTrail to generate data keys for file encryption.

Key Concept

Centralized Monitoring, Logging, and Auditing Solutions

Question 392Question →

An enterprise is migrating its legacy database and application servers from an on-premises data center to AWS using AWS Application Migration Service (MGN). The on-premises network is connected to a staging VPC in AWS via an AWS Direct Connect connection attached to an AWS Transit Gateway. Immediately after installing the AWS Replication Agent on the on-premises servers, the migration console shows the replication status as stalled. The on-premises servers cannot establish communication with the replication servers in the staging VPC or the MGN control plane. Which TWO of the following actions must the solutions architect take to resolve this issue and start replication? (Select TWO)

Select all that apply

Configure the security group of the staging area in the staging VPC to allow inbound traffic on TCP port 1500 from the on-premises CIDR block, and ensure the on-premises firewall allows outbound traffic on TCP port 1500 to the staging VPC CIDR block.

Ensure that the on-premises servers can resolve and access the AWS Application Migration Service regional endpoints over HTTPS port 443, updating the on-premises firewall to allow outbound port 443 traffic if necessary.

Modify the target VPC security group to allow inbound traffic on TCP port 1500, and configure the on-premises agents to use a custom port for data replication to bypass the on-premises firewall.

Configure a Direct Connect gateway to handle transitive routing between the target VPC and the staging VPC without using the Transit Gateway, and update the on-premises firewall to permit all traffic over UDP port 1500.

Show answer & explanation

Answer: Configure the security group of the staging area in the staging VPC to allow inbound traffic on TCP port 1500 from the on-premises CIDR block, and ensure the on-premises firewall allows outbound traffic on TCP port 1500 to the staging VPC CIDR block.; Ensure that the on-premises servers can resolve and access the AWS Application Migration Service regional endpoints over HTTPS port 443, updating the on-premises firewall to allow outbound port 443 traffic if necessary.

Answer

To resolve the stalled replication, the solutions architect must allow inbound TCP port 1500 on the staging area security groups from the on-premises network, allow outbound TCP port 1500 traffic on the on-premises firewall, and verify that the on-premises servers can connect to the regional MGN control plane endpoints over HTTPS port 443.

The AWS Replication Agent relies on two network paths to start replication: HTTPS (port 443) outbound to the MGN regional control plane service endpoints to authenticate and pull configurations, and TCP port 1500 to push block-level data to the replication servers in the staging VPC. Allowing inbound TCP port 1500 on the staging area security group from the on-premises network and enabling outbound port 443 on the on-premises firewall resolves both communication failures.

Step-by-Step Solution

Examine the outbound rules on the on-premises firewall and the inbound rules on the staging area security group in the staging VPC.

Identify that TCP port 1500 replication traffic is blocked between the on-premises servers and the replication servers.

Data replication requires a clear network path over TCP port 1500 to send disk block changes.

Review DNS resolution and network access from the on-premises servers to the AWS Application Migration Service control plane regional endpoints.

Ensure port 443 outbound to mgn.<region>.amazonaws.com is allowed.

The replication agent cannot register or receive configuration without control plane access over HTTPS port 443.

Key Concept

AWS Application Migration Service (MGN) network configuration requirements for replication and control plane connectivity.

Question 393Question →

An enterprise needs to migrate $450\text{ TB}$ of medical imaging data from an on-premises NFSv3 storage system to an Amazon EFS file system. The migration must be completed within a strict $3\text{-week}$ window. The enterprise has a dedicated $500\text{ Mbps}$ internet connection available for this migration. All data must be encrypted at rest throughout the migration process. Which strategy should a solutions architect recommend to meet these requirements?

Order multiple AWS Snowball Edge Storage Optimized devices, specifying an AWS Key Management Service (AWS KMS) customer managed key for encryption. Copy the data to the devices using the NFS interface, ship the devices back to AWS to import the data into an Amazon S3 bucket, and then run an AWS DataSync task to copy the data from the S3 bucket to the Amazon EFS file system.

Order multiple AWS Snowball Edge Storage Optimized devices, specifying the default AWS-managed KMS key for Amazon S3 (`aws/s3`) for encryption. Copy the data to the devices using the NFS interface, ship the devices back to AWS to import the data into an Amazon S3 bucket, and then run an AWS DataSync task to copy the data from the S3 bucket to the Amazon EFS file system.

Deploy AWS DataSync agents on-premises, configure the agents to connect to the Amazon EFS file system, and run a DataSync task to transfer the data directly from the local NFS file system to the target Amazon EFS file system over the

500\text{ Mbps}

internet connection.

Order multiple AWS Snowball Edge Storage Optimized devices, specifying an AWS Key Management Service (AWS KMS) customer managed key for encryption. Copy the data to the devices using the NFS interface, ship the devices back to AWS, and configure the import job to write the data directly to the target Amazon EFS file system.

Show answer & explanation

Answer: Order multiple AWS Snowball Edge Storage Optimized devices, specifying an AWS Key Management Service (AWS KMS) customer managed key for encryption. Copy the data to the devices using the NFS interface, ship the devices back to AWS to import the data into an Amazon S3 bucket, and then run an AWS DataSync task to copy the data from the S3 bucket to the Amazon EFS file system.

Answer

Order multiple AWS Snowball Edge Storage Optimized devices with a customer managed key, copy data using the NFS interface, ship back to AWS for S3 import, and then use AWS DataSync to copy to Amazon EFS.

The correct strategy uses AWS Snowball Edge Storage Optimized devices to physical transfer the data because the network bandwidth (

500\text{ Mbps}

) is insufficient to transfer

450\text{ TB}

within the

3\text{-week}

deadline. A customer managed key is specified since default AWS-managed keys are not supported for Snowball jobs. Because Snowball Edge cannot import directly to Amazon EFS, data is imported into Amazon S3 first, and then AWS DataSync is used to efficiently replicate the data from Amazon S3 to Amazon EFS.

Step-by-Step Solution

Calculate the minimum network transfer time.

500\text{ Mbps}

, transferring

450\text{ TB}

of data requires at least

7.2 \times 10^6\text{ seconds}

(approximately

83.3\text{ days}

), which exceeds the

3\text{-week}

(

21\text{-day}

) timeline limit.

To verify if online network transfer is a viable option.

Select the appropriate migration family and determine destination compatibility.

AWS Snowball Edge is chosen for offline physical transport. Since Snowball Edge cannot import directly into Amazon EFS, Amazon S3 must be used as the initial import destination.

To plan the physical transport and target endpoints based on AWS service capabilities.

Verify KMS encryption settings for the Snowball job.

Identify that a customer managed key must be created and specified. Default AWS-managed KMS keys are not supported.

To ensure compliance with the requirement of keeping data encrypted at rest during the physical transfer.

Determine the migration step from the intermediate store to the final destination.

Run an AWS DataSync task to copy the imported data from the Amazon S3 bucket to the target Amazon EFS file system.

To move the migrated data from the intermediate S3 staging bucket to the required Amazon EFS production destination.

Key Concept

Selecting the correct hybrid migration tool based on dataset size, available bandwidth, timeline constraints, target service support, and security requirements.

Question 394Question →

An enterprise manages an AWS Organization with fifteen VPCs in a single AWS Region: five Production VPCs, five Development VPCs, and five Shared Services VPCs. The enterprise has established an AWS Direct Connect connection to its on-premises data center. The network design must satisfy the following requirements:

* Production and Development VPCs must be completely isolated from each other.
* Both Production and Development VPCs must be able to communicate with the Shared Services VPCs.
* Only Production VPCs and Shared Services VPCs are permitted to communicate with the on-premises data center.
* Administrative overhead and routing table complexity must be minimized.

The enterprise deploys an AWS Transit Gateway and connects it to a Direct Connect Gateway using a transit virtual interface (Transit VIF).

Which TWO actions should the Solutions Architect take to configure the Transit Gateway routing to meet these requirements? (Select TWO.)

Select all that apply

Create three distinct Transit Gateway route tables designated for Production, Development, and Hybrid/Shared Services. Associate the Production VPC attachments, Development VPC attachments, and the Direct Connect Gateway attachment with their corresponding route tables.

Configure route propagations such that the Production route table propagates Shared Services and Direct Connect Gateway attachments; the Development route table propagates only Shared Services attachments; and the Hybrid/Shared Services route table propagates Production, Shared Services, and Direct Connect Gateway attachments.

Configure a single, shared Transit Gateway route table for all attachments. Implement network isolation by associating a Route 53 Private Hosted Zone only with the Production and Shared Services VPCs, using DNS resolution restrictions to block the Development VPC's access to the on-premises network.

Configure a single, shared Transit Gateway route table. Route all cross-VPC and hybrid traffic through a single NAT Gateway deployed in the Shared Services VPC to manage network access lists and traffic filtering centrally.

Show answer & explanation

Answer: Create three distinct Transit Gateway route tables designated for Production, Development, and Hybrid/Shared Services. Associate the Production VPC attachments, Development VPC attachments, and the Direct Connect Gateway attachment with their corresponding route tables.; Configure route propagations such that the Production route table propagates Shared Services and Direct Connect Gateway attachments; the Development route table propagates only Shared Services attachments; and the Hybrid/Shared Services route table propagates Production, Shared Services, and Direct Connect Gateway attachments.

Answer

Create three distinct Transit Gateway route tables for Production, Development, and Hybrid/Shared Services VPCs. Associate each attachment with its respective route table, and configure route propagations so that routes are shared only between allowed destinations, keeping Production and Development isolated while selectively enabling hybrid connectivity.

To achieve the required network isolation and selective hybrid connectivity, the Solutions Architect must implement a Transit Gateway hub-and-spoke model with multiple route tables. Creating three separate route tables (Production, Development, and Hybrid/Shared Services) creates isolated routing domains. The Production route table associates with Production VPCs and propagates Shared Services and Direct Connect Gateway attachments, enabling connectivity to those destinations. The Development route table associates with Development VPCs and propagates only Shared Services VPCs, preventing communication with Production VPCs and the on-premises network. The Hybrid/Shared Services route table associates with Shared Services and Direct Connect Gateway attachments, and propagates Production, Shared Services, and Direct Connect Gateway attachments. This ensures that on-premises traffic can only route to Production and Shared Services VPCs, while Shared Services VPCs can communicate with all environments.

Step-by-Step Solution

Identify the network segmentation and routing requirements.

Production and Development must be isolated; both need Shared Services access; only Production and Shared Services need hybrid access.

This establishes the necessary boundaries for configuring AWS Transit Gateway route tables and association domains.

Design route table associations for Transit Gateway attachments.

Associate Production VPC attachments to a Production route table, Development VPC attachments to a Development route table, and Shared Services and Direct Connect Gateway attachments to a Hybrid/Shared Services route table.

Associating attachments to separate route tables defines which routing table is looked up when traffic originates from those attachments.

Design route propagations to dynamically share routes.

Propagate Shared Services and Direct Connect Gateway attachments into the Production route table; propagate only Shared Services into the Development route table; propagate Production, Shared Services, and Direct Connect Gateway attachments into the Hybrid/Shared Services route table.

This ensures that traffic from the Production and Development VPCs can reach Shared Services, but they cannot reach each other. Furthermore, only Production and Shared Services VPCs can route to and from the Direct Connect Gateway.

Key Concept

Transit Gateway route table association and propagation properties allow for fine-grained routing segmentation and isolation in a multi-account AWS environment.

Estimated Time:2m 0s

Question 395Question →

A global retail group manages $135$ AWS accounts within an AWS Organization. To comply with strict regulatory audit requirements, a solutions architect must establish an organization-wide AWS CloudTrail trail that delivers log files from all AWS Regions to a centralized Amazon S3 bucket located in a dedicated Auditing account. The organization requires that the logs be encrypted at rest using an AWS Key Management Service (AWS KMS) key. The security team dictates that member accounts must not have permissions to decrypt the CloudTrail logs once written, nor should they be able to disable the logging configuration. Which combination of configuration steps will satisfy these requirements?

Create the Amazon S3 bucket and a KMS customer managed key (CMK) in the Auditing account. Configure the S3 bucket policy to allow the CloudTrail service principal to perform s3:PutObject and s3:GetBucketAcl operations, restricted by the aws:PrincipalOrgID condition. Configure the KMS key policy to allow the CloudTrail service principal to perform kms:GenerateDataKey* and kms:DescribeKey operations, restricted by the aws:PrincipalOrgID condition. Create an organization trail in the management account that points to the centralized S3 bucket and uses the Auditing account CMK. Apply a Service Control Policy (SCP) to the organization root that denies cloudtrail:StopLogging, cloudtrail:DeleteTrail, and cloudtrail:UpdateTrail actions.

Create the Amazon S3 bucket in the Auditing account. Configure the S3 bucket policy to allow the CloudTrail service principal to perform s3:PutObject and s3:GetBucketAcl operations, restricted by the aws:PrincipalOrgID condition. Configure the organization trail to encrypt logs using the default AWS-managed KMS key for CloudTrail (aws/cloudtrail) in the Auditing account. Create an organization trail in the management account that points to the centralized S3 bucket. Apply a Service Control Policy (SCP) to the organization root that denies cloudtrail:StopLogging, cloudtrail:DeleteTrail, and cloudtrail:UpdateTrail actions.

Create the Amazon S3 bucket and a KMS customer managed key (CMK) in the Auditing account. Create a unique IAM role in each of the

135

member accounts with permissions to put objects in the Auditing account S3 bucket and generate data keys using the CMK. Configure CloudTrail in each member account individually to assume this local IAM role for log delivery, pointing to the centralized S3 bucket. Apply a Service Control Policy (SCP) to the organization root that denies the delete and disable actions on CloudTrail.

Create the Amazon S3 bucket and a KMS customer managed key (CMK) in the Auditing account. In the Auditing account, configure the S3 bucket policy and the KMS key policy to trust the organization management account. Apply a Service Control Policy (SCP) to the organization root that explicitly allows the CloudTrail service principal to perform s3:PutObject, kms:GenerateDataKey*, and kms:DescribeKey actions across all accounts, while denying member accounts access to modify CloudTrail configurations.

Show answer & explanation

Answer: Create the Amazon S3 bucket and a KMS customer managed key (CMK) in the Auditing account. Configure the S3 bucket policy to allow the CloudTrail service principal to perform s3:PutObject and s3:GetBucketAcl operations, restricted by the aws:PrincipalOrgID condition. Configure the KMS key policy to allow the CloudTrail service principal to perform kms:GenerateDataKey* and kms:DescribeKey operations, restricted by the aws:PrincipalOrgID condition. Create an organization trail in the management account that points to the centralized S3 bucket and uses the Auditing account CMK. Apply a Service Control Policy (SCP) to the organization root that denies cloudtrail:StopLogging, cloudtrail:DeleteTrail, and cloudtrail:UpdateTrail actions.

Answer

Create the Amazon S3 bucket and a Customer Managed Key (CMK) in the Auditing account, configure both resource policies to allow the CloudTrail service principal with an Organization ID constraint, deploy an organization-wide trail, and enforce logging with a Service Control Policy (SCP) at the root.

The correct option correctly uses a Customer Managed Key (CMK) in the Auditing account, which supports modifying the key policy to allow cross-account access by the CloudTrail service principal. Both the S3 bucket policy and the KMS key policy correctly authorize the cloudtrail.amazonaws.com service principal with a condition checking the organization's ID (aws:PrincipalOrgID). The organization trail ensures all accounts are covered, and the SCP prevents member accounts from modifying the logging configuration without attempting to grant access itself.

Step-by-Step Solution

Set up centralized storage and encryption resources in the Auditing account.

An S3 bucket is created to store logs, and a KMS Customer Managed Key (CMK) is provisioned to encrypt the logs.

Centralizing logs in a dedicated account isolates audit data from member accounts, and a CMK allows policy modifications necessary for cross-account service principal access.

Configure the S3 bucket policy and KMS key policy to permit cross-account CloudTrail delivery.

The S3 bucket policy allows the CloudTrail service principal to write objects, and the KMS key policy allows it to generate data keys, both restricted to the specific organization using the aws:PrincipalOrgID condition.

CloudTrail operates under its own service principal rather than member IAM roles, requiring resource-based policies to permit delivery while restricting access to the specified organization.

Create an organization-wide trail from the management account and apply a Service Control Policy (SCP) to protect the configuration.

An organization trail is deployed to capture all events across all regions and member accounts, and an SCP is attached to the organization root to deny delete, stop, or update trail actions.

An organization trail ensures uniform and secure log collection, while the SCP prevents member accounts (including root users) from altering or disabling the audit logging.

Key Concept

Centralized multi-account logging requires resource-based policies on S3 and KMS CMKs that explicitly trust the CloudTrail service principal, combined with organization-wide trails and SCP guardrails to prevent tampering.

Question 396Question →

An enterprise is configuring federated access to their multi-account AWS environment using an external SAML 2.0 Identity Provider (IdP). The identity team wants to allow users to authenticate through the IdP and assume specific IAM roles in multiple target AWS accounts managed under AWS Organizations. The solutions architect needs to configure the trust relationships and identity provider configurations.

Which TWO configurations must the solutions architect implement to establish this trust and allow users to federate directly into the target accounts? (Select TWO.)

Select all that apply

Create a SAML identity provider entity in each target AWS account pointing to the external IdP's metadata document.

Configure the trust policy of the IAM roles in the target accounts to allow the sts:AssumeRoleWithSAML action for the target SAML provider ARN.

Configure the trust policy of the IAM roles in the target accounts with the sts:AssumeRole action and specify the external SAML provider as the principal.

Attach a Service Control Policy (SCP) at the root of the AWS Organization that explicitly grants sts:AssumeRoleWithSAML access to the external IdP's entity.

Create a single central SAML identity provider entity in the organization's management account and configure target account roles to trust the management account's provider using sts:AssumeRole.

Show answer & explanation

Answer: Create a SAML identity provider entity in each target AWS account pointing to the external IdP's metadata document.; Configure the trust policy of the IAM roles in the target accounts to allow the sts:AssumeRoleWithSAML action for the target SAML provider ARN.

Answer

To establish direct SAML federation, the solutions architect must create a SAML identity provider entity in each target AWS account pointing to the external IdP's metadata document, and configure the trust policy of the IAM roles in the target accounts to allow the sts:AssumeRoleWithSAML action for the target SAML provider ARN.

Direct SAML 2.0 federation requires the target AWS accounts to trust the external IdP. To establish this, a SAML identity provider entity must be created in each target AWS account. The target IAM roles must also have trust policies allowing the federated users to assume them via the sts:AssumeRoleWithSAML action using the specific provider ARN.

Step-by-Step Solution

A unique SAML identity provider ARN is generated in each target AWS account, establishing a trusted configuration between that account and the external IdP.

AWS Security Token Service (STS) requires a registered provider entity within the target account to authenticate federated tokens locally.

Update the trust policy of the target IAM roles to specify the registered SAML provider ARN as the Principal and allow the sts:AssumeRoleWithSAML action.

The target IAM roles are authorized to accept SAML assertions matching the provider's trust metadata.

This establishes the trust relationship, allowing STS to issue temporary credentials when the external IdP issues a valid assertion.

Key Concept

Direct SAML 2.0 federation in a multi-account environment requires both a registered SAML identity provider entity in every target AWS account and target IAM role trust policies configured to allow the sts:AssumeRoleWithSAML action referencing the specific provider ARN.

Question 397Question →

An online travel agency is migrating its legacy customer loyalty application, which runs on 8 on-premises virtual machines, to AWS using AWS Application Migration Service (MGN). The network architecture connects the on-premises data center to a staging VPC in AWS via a 1 Gbps AWS Direct Connect connection terminated at an AWS Transit Gateway. During the migration setup, the MGN agents are successfully installed on the source servers, but the replication status on the MGN console remains stuck in the 'Initiating data replication' state with 0% progress. The network routing and security configurations must maintain a private traffic path. Which of the following actions should the Solutions Architect take to resolve this replication issue?

Modify the on-premises firewall rules and the staging VPC security groups to allow outbound and inbound traffic over TCP port 1500, routing the replication traffic privately through the Transit Gateway to the replication servers.

Configure the replication template to use public IP addresses for the replication servers, and verify that the on-premises firewall allows outbound traffic over TCP port 443 to the MGN control plane endpoints.

Bypass the Transit Gateway by associating the Direct Connect Gateway directly with the staging VPC's route table, and configure a public hosted zone in Route 53 to resolve the replication endpoints.

Deploy a single NAT Gateway in the staging VPC to route replication traffic to the internet, and configure the MGN agent to use the NAT Gateway's elastic IP address for data transit.

Show answer & explanation

Answer: Modify the on-premises firewall rules and the staging VPC security groups to allow outbound and inbound traffic over TCP port 1500, routing the replication traffic privately through the Transit Gateway to the replication servers.

Answer

The correct action is to modify the on-premises firewall and staging VPC security groups to allow outbound and inbound TCP port 1500 traffic. AWS Application Migration Service requires TCP port 1500 for block-level data replication from the source agents to the replication servers in the staging area. Using the existing Direct Connect and Transit Gateway path satisfies the privacy requirement.

Step-by-Step Solution

Analyze the replication status and network path.

The MGN agents are installed (meaning TCP port 443 control plane connectivity is active), but replication is stuck at 0% (indicating the data plane is blocked). The path must remain private using the Direct Connect and Transit Gateway connection.

To identify why the control plane is communicating but the data replication has not started.

Identify the port requirements for MGN data replication.

MGN requires TCP port 1500 for continuous block-level data replication from the source servers to the replication servers in the staging area VPC.

To pinpoint the specific protocol and port blocking the replication stream.

Update firewall and security group rules to permit TCP port 1500.

On-premises firewalls allow outbound TCP port 1500, and the security groups associated with the MGN replication servers in the staging VPC allow inbound TCP port 1500 over the private network path.

To establish the replication data tunnel privately and allow data transfer to progress past the initiation phase.

Key Concept

AWS Application Migration Service (MGN) separates orchestration traffic (TCP port 443) from block-level data replication traffic (TCP port 1500). In a hybrid network using AWS Direct Connect or VPN, both ports must be appropriately routed and allowed through local firewalls and security groups to enable successful replication.

Estimated Time:2m 0s

Question 398Question →

A company's production application runs on Amazon EC2 instances managed by an Auto Scaling group behind an Application Load Balancer (ALB). A solutions architect is designing a deployment pipeline using AWS CodeDeploy to update the application with zero downtime.

The deployment strategy must meet the following requirements:
1. The new version must be deployed to a completely separate set of EC2 instances for validation.
2. Production traffic must not be routed to the new instances until the development team manually verifies the deployment.
3. Once verified, production traffic must be switched to the new instances.
4. The original EC2 instances must be kept running for 2 hours after traffic is redirected to allow for a quick manual rollback if issues arise, after which they must be terminated.

Which TWO configurations should the solutions architect specify in the AWS CodeDeploy deployment group to meet these requirements? (Select two.)

Select all that apply

Set the deployment type to Blue/Green, and configure the environment settings to copy the existing Auto Scaling group to provision the replacement instances.

Configure the traffic rerouting setting to manually reroute traffic, and set the original revision termination wait time to 2 hours.

Set the deployment type to In-Place with the CodeDeployDefault.OneAtATime configuration, and configure an ALB test listener to route validation traffic to the updated instances.

Set the deployment type to Blue/Green, and select an AWS-managed canary deployment configuration to automatically shift traffic from the original instances to the new instances over 120 minutes.

Set the deployment type to Blue/Green, and configure the deployment group to use the AWS::CodeDeploy::BlueGreen CloudFormation transform to manage the Auto Scaling group lifecycle.

Show answer & explanation

Answer: Set the deployment type to Blue/Green, and configure the environment settings to copy the existing Auto Scaling group to provision the replacement instances.; Configure the traffic rerouting setting to manually reroute traffic, and set the original revision termination wait time to 2 hours.

Answer

To meet the requirements, the solutions architect must set the deployment type to Blue/Green, configure the environment settings to copy the existing Auto Scaling group, configure the traffic rerouting setting to manually reroute traffic, and set the original revision termination wait time to 2 hours.

For EC2 Auto Scaling groups, AWS CodeDeploy supports Blue/Green deployments by cloning the original Auto Scaling group to create a replacement environment. By setting the traffic rerouting configuration to manual, CodeDeploy will deploy the application and wait in a 'Ready' state, allowing the team to test the new instances before routing production traffic. The original instances can be kept active for a designated period (such as 2 hours) before termination, which provides a simple rollback mechanism.

Step-by-Step Solution

Determine the deployment type and environment settings.

Selected Blue/Green deployment and configured CodeDeploy to copy the existing Auto Scaling group.

This creates a separate cloned Auto Scaling group with the new application version, keeping the existing instances untouched.

Configure traffic rerouting for manual verification.

Traffic rerouting is configured to manual.

This prevents CodeDeploy from immediately shifting production traffic to the new instances, allowing the team to manually test the green environment first.

Configure original instance lifecycle rules.

The original revision termination wait time is set to 2 hours.

This ensures the original instances remain active for 2 hours post-traffic swap for quick rollback capability, and are terminated automatically thereafter.

Key Concept

AWS CodeDeploy Blue/Green deployments for EC2 Auto Scaling groups

Question 399Question →

A medical records company is launching a new patient portal that requires a highly available relational database for a read-heavy OLTP workload. During morning hours, read traffic increases tenfold, while write volume remains low and stable. The database must be encrypted at rest. In the event of an Availability Zone failure, the database must fail over automatically with zero data loss (RPO = 0) and a recovery time of less than 2 minutes (RTO < 2 minutes). Additionally, the database security audit logs must be securely shared with a centralized compliance account in the organization. Which database and storage strategy meets these requirements?

Deploy an Amazon RDS DB instance in a Multi-AZ deployment. Direct the application's read queries to the standby DB instance's endpoint to distribute the load during peak hours. Encrypt the DB instance using an AWS KMS Customer Managed Key.

Deploy an Amazon RDS DB instance in a single Availability Zone. Enable automated backups and configure a script to restore the DB instance to a different Availability Zone if a failure occurs. Encrypt the DB instance using an AWS KMS Customer Managed Key.

Deploy an Amazon RDS DB instance in a Multi-AZ deployment. Create RDS Read Replicas to handle the read traffic and configure Auto Scaling for the replicas. Encrypt the DB instance and its replicas using an AWS KMS Customer Managed Key.

Deploy an Amazon RDS DB instance in a Multi-AZ deployment with Read Replicas. Encrypt the primary DB instance using the default AWS-managed KMS key for Amazon RDS (aws/rds). Configure a cross-account key policy on the default key to share access with the centralized compliance account.

Show answer & explanation

Answer: Deploy an Amazon RDS DB instance in a Multi-AZ deployment. Create RDS Read Replicas to handle the read traffic and configure Auto Scaling for the replicas. Encrypt the DB instance and its replicas using an AWS KMS Customer Managed Key.

Answer

The correct strategy uses an Amazon RDS Multi-AZ deployment to provide synchronous replication, achieving zero data loss (RPO = 0) and automatic failover in 1-2 minutes (RTO < 2 minutes). Read replicas are created with Auto Scaling to handle the tenfold read traffic spike, as the passive standby DB instance cannot serve reads. Encrypting the DB instances using a Customer Managed Key allows the key policy to be customized, enabling secure cross-account logging and access sharing.

Step-by-Step Solution

Evaluate high availability and disaster recovery requirements.

The target workload requires synchronous replication for zero data loss (RPO = 0) and automated failover in under 2 minutes (RTO < 2 minutes).

An Amazon RDS Multi-AZ deployment replicates data synchronously to a standby instance in another Availability Zone, providing automatic failover within 1 to 2 minutes during an outage.

Address the read scalability requirements.

The portal expects a tenfold increase in read traffic during peak hours.

Amazon RDS Read Replicas must be used to scale reads horizontally. The standby DB instance in an RDS Multi-AZ deployment is passive and cannot serve read traffic.

Examine the database encryption and cross-account access constraints.

The database must be encrypted at rest, and audit logs/access must be shared with a centralized compliance account.

An AWS KMS Customer Managed Key must be selected because default AWS-managed keys (like aws/rds) cannot have their key policies modified and cannot be shared across different AWS accounts.

Key Concept

Amazon RDS Multi-AZ deployments provide high availability and synchronous replication for zero data loss, while Read Replicas are utilized for scaling read workloads. Customer Managed Keys are required for cross-account sharing.

Estimated Time:2m 0s

Question 400Question →

An enterprise is migrating its on-premises VMware vSphere workloads to VMware Cloud on AWS. The virtual machines (VMs) are being migrated to a VMware Cloud on AWS Software-Defined Data Center (SDDC). In the AWS cloud environment, a Route $53$ Private Hosted Zone (PHZ) named `corp.internal` is associated with a shared services VPC. The migrated VMs in the SDDC must resolve resources in the `corp.internal` domain. The VMware Cloud on AWS SDDC is connected to the AWS environment using a Transit Gateway via VMware Transit Connect. Which configuration should the solutions architect implement to enable DNS resolution for the migrated VMs?

Create Route

53

Resolver Inbound Endpoints in the Connected VPC, associate the private hosted zone `corp.internal` with the Connected VPC, and configure the VMware Cloud on AWS Compute Gateway (CGW) DNS forwarder to point to the Inbound Endpoint IP addresses.

Associate the private hosted zone `corp.internal` directly with the VMware Cloud on AWS management VPC, and configure the VMware Cloud on AWS Management Gateway (MGW) to allow DNS traffic from the compute network.

Create Route

53

Resolver Outbound Endpoints in the VMware Cloud on AWS SDDC management network, and configure a resolver rule to forward DNS queries directly to the shared services VPC Route

53

Resolver IP address `

169.254.169.253

Configure the VMware Cloud on AWS Compute Gateway (CGW) to route DNS queries for `corp.internal` over the AWS Transit Connect attachment directly to the AWS Direct Connect Gateway, utilizing transitive routing to reach the shared services VPC Route

53

Resolver.

Show answer & explanation

Answer: Create Route $53$ Resolver Inbound Endpoints in the Connected VPC, associate the private hosted zone `corp.internal` with the Connected VPC, and configure the VMware Cloud on AWS Compute Gateway (CGW) DNS forwarder to point to the Inbound Endpoint IP addresses.

Answer

Create Route

53

To resolve names in a Route

53

Private Hosted Zone (PHZ) from virtual machines inside the VMware Cloud on AWS SDDC, you must associate the PHZ with the Connected VPC (the VPC attached to the SDDC during provisioning) and create Route

53

Resolver Inbound Endpoints in that Connected VPC. The VMware Cloud on AWS Compute Gateway (CGW) DNS service can then be configured to forward queries for the specific domain (e.g., `corp.internal`) to the IP addresses of the Inbound Endpoints. This allows the queries to flow over the high-speed elastic network interface (ENI) connection between the SDDC and the Connected VPC.

Step-by-Step Solution

Identify the connectivity path between the VMware Cloud on AWS SDDC and the AWS environment.

The SDDC is connected directly to the Connected VPC via high-speed Elastic Network Interfaces (ENIs).

Understanding the direct link between the SDDC and the Connected VPC is critical for determining the most efficient query resolution path.

Configure Route

53

Resolver Inbound Endpoints in the Connected VPC.

Inbound Endpoints are provisioned with IP addresses in the Connected VPC subnets.

These endpoints accept DNS queries from resources outside the VPC (including the SDDC) and forward them to the Route

53

Resolver.

Associate the Route

53

Private Hosted Zone (PHZ) with the Connected VPC.

The PHZ named `corp.internal` is now associated with the Connected VPC.

This ensures that DNS queries arriving at the Connected VPC's Route

53

Resolver can resolve names within the `corp.internal` domain.

Configure the VMware Cloud on AWS Compute Gateway (CGW) DNS forwarder.

The CGW is configured to forward all DNS queries for the domain `corp.internal` to the IP addresses of the Inbound Endpoints.

This routes VM DNS queries for `corp.internal` directly to the Route

53

Inbound Endpoints in the Connected VPC over the ENI connection.

Key Concept

Integration of VMware Cloud on AWS SDDC DNS resolution with AWS Route

53

Private Hosted Zones using Inbound Resolver Endpoints.

Estimated Time:2m 0s

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