All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A media company operates a video transcoding application on Amazon EC2 instances in an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The instances require 7 minutes to download custom profiles and initialize the transcoding daemon before they can accept tasks. During scheduled flash promotional events, the application experiences sudden, massive surges in traffic. The ASG scales out, but it continuously launches unnecessary instances, leading to excessive costs. Additionally, the ALB drops connection requests during the first few minutes of the event. Which combination of actions will resolve the over-provisioning issue and prevent connection drops?

Decrease the default cooldown period of the Auto Scaling group to 60 seconds to allow faster resource provisioning, and configure the Application Load Balancer to use cross-zone load balancing.

Implement a target tracking scaling policy on the Auto Scaling group with an instance warmup period of 450 seconds, and route all outbound internet traffic through a single NAT Gateway to speed up the instance bootstrapping process.

Implement a target tracking scaling policy on the Auto Scaling group with an instance warmup period of 450 seconds, and submit a request to AWS Support for Application Load Balancer pre-warming prior to the promotional events.

Implement a target tracking scaling policy on the Auto Scaling group with an instance warmup period of 450 seconds, and rely on the default auto-scaling behavior of the Application Load Balancer to dynamically scale out during the traffic spikes.

Show answer & explanation

Answer: Implement a target tracking scaling policy on the Auto Scaling group with an instance warmup period of 450 seconds, and submit a request to AWS Support for Application Load Balancer pre-warming prior to the promotional events.

Answer

The correct option is the configuration that recommends setting the instance warmup period to 450 seconds and requesting ALB pre-warming. Since the EC2 instances require 7 minutes (

420 \text{ seconds}

) to bootstrap, the warmup period must exceed this value to prevent the Auto Scaling group from launching extra instances before the first batch is ready. Furthermore, pre-warming the Application Load Balancer ensures that it is provisioned with sufficient capacity to absorb the massive, sudden traffic surge without dropping incoming requests.

Step-by-Step Solution

Convert the bootstrapping time of the instances from minutes to seconds.

The bootstrapping time is

7 \text{ minutes} \times 60 \text{ seconds/minute} = 420 \text{ seconds}

This calculation establishes the minimum timeframe that a new instance needs before it can contribute to handling the application load.

Determine the minimum warmup duration for the Auto Scaling group's target tracking scaling policy.

The instance warmup period must be configured to be greater than the bootstrap time, which is why 450 seconds is selected.

Setting the warmup period to 450 seconds ensures the Auto Scaling group waits for the newly launched instances to become fully ready before evaluating the metric again, preventing over-provisioning.

Select the appropriate load balancer scaling strategy to prevent connection drops during flash traffic spikes.

Submit a pre-warming request to AWS Support before the scheduled promotional events.

Application Load Balancers scale dynamically but gradually. For a massive, instantaneous traffic spike, pre-warming ensures that the ALB has pre-allocated capacity ready to handle the load immediately without dropping packets.

Key Concept

Aligning scaling policy warmup durations with instance bootstrap time and requesting Application Load Balancer pre-warming for sudden traffic surges.

Estimated Time:2m 0s

Question 1742Question →

AeroVigil Systems is modernizing an on-premises network security monitoring tool by migrating the workload to Amazon ECS. The application is a packet-inspection agent that requires direct access to the host's physical network interfaces to sniff and analyze network traffic in promiscuous mode. To meet high availability requirements, the containerized workload must be distributed across multiple Availability Zones. Additionally, the solutions architect must ensure compliance with the following enterprise constraints:

1. All container images must be securely stored and pulled from an Amazon Elastic Container Registry (ECR) repository located in a central Shared Services AWS account.
2. The ECS tasks must resolve internal server endpoints using a Route 53 Private Hosted Zone (PHZ) for internal.aerovigil.com that is managed in the Shared Services AWS account.
3. The design must minimize operational overhead where possible, without compromising the core packet-sniffing functionality.

Which architecture should the solutions architect recommend to satisfy these requirements?

Deploy the tasks on Amazon ECS using the AWS Fargate launch type to minimize operational overhead. Configure the task definition to use the host network mode. In the Shared Services AWS account, authorize a Route 53 Private Hosted Zone association with the VPC in the ECS account. In the ECS account, associate the Private Hosted Zone with the ECS VPC.

Deploy the tasks on Amazon ECS using the EC2 launch type. Configure the task definition to use the bridge network mode. Create a duplicate Route 53 Private Hosted Zone for internal.aerovigil.com in the ECS account, associate it with the ECS VPC, and deploy a cron-based sync mechanism to copy DNS records from the Shared Services account.

Deploy the tasks on Amazon ECS using the EC2 launch type. Configure the task definition to use the host network mode. In the Shared Services AWS account, authorize a Route 53 Private Hosted Zone association with the VPC in the ECS account. In the ECS account, associate the Private Hosted Zone with the ECS VPC.

Deploy the tasks on Amazon ECS using the EC2 launch type. Configure the task definition to use the host network mode. Set up an AWS Transit Gateway to establish connectivity between the ECS VPC and the Shared Services VPC, relying on default Transit Gateway route propagation to resolve private DNS queries.

Show answer & explanation

Answer: Deploy the tasks on Amazon ECS using the EC2 launch type. Configure the task definition to use the host network mode. In the Shared Services AWS account, authorize a Route 53 Private Hosted Zone association with the VPC in the ECS account. In the ECS account, associate the Private Hosted Zone with the ECS VPC.

Answer

Deploy the tasks on Amazon ECS using the EC2 launch type with the host network mode, and configure a cross-account Route 53 Private Hosted Zone association between the Shared Services account and the ECS VPC.

The correct solution involves deploying the packet-inspection agent on Amazon ECS with the EC2 launch type, configuring the task definition to use host network mode, and setting up a cross-account Route 53 Private Hosted Zone association. Since the containerized agent needs direct access to the physical host interfaces to sniff traffic, host networking is required. AWS Fargate is incompatible because it only supports awsvpc networking. Resolving the private domain from the Shared Services account requires establishing a cross-account PHZ association, which is authorized by the owner account and accepted by the consumer VPC.

Step-by-Step Solution

Determine the required Amazon ECS launch type and networking mode.

The packet-inspection agent requires raw access to the host's physical network interface, which necessitates using the host network mode on the Amazon ECS EC2 launch type. AWS Fargate is ruled out because it only supports the awsvpc network mode, which abstracts host network access.

Host networking binds the container ports and network interfaces directly to the container instance's interfaces, enabling packet sniffing.

Configure cross-account private DNS resolution.

Authorize the association of the Shared Services Route 53 Private Hosted Zone (PHZ) with the ECS VPC from the Shared Services account. Then, submit the association request from the ECS VPC account.

This allows tasks in the ECS VPC to query and resolve internal hostnames managed by the centralized PHZ without duplicate zones or additional DNS server deployments.

Configure ECR cross-account registry permissions.

Add a registry policy to the ECR repository in the Shared Services account to permit the ECS task execution role and ECS container instances in the member account to pull container images.

This ensures the container runtime on the EC2 instances can securely download the monitoring agent images.

Key Concept

Host network mode implementation on ECS EC2 for network-dependent workloads, combined with Route 53 cross-account Private Hosted Zone association.

Question 1743Question →

An enterprise implements a multi-account strategy using AWS Organizations. Users authenticate via an external corporate Identity Provider (IdP) using SAML 2.0. A solutions architect configures direct SAML federation to each member account by creating an IAM SAML identity provider and a federated IAM role in each account. The security team requires that federated users must only be allowed to assume the role if the authentication request originates from the corporate network range of $203.0.113.0/24$ , and once authenticated, they must be prevented from performing any actions if they leave the corporate network. The solutions architect implements a Service Control Policy (SCP) at the root level of the organization that denies all actions ( $*$ ) if the request context does not originate from $203.0.113.0/24$ . The security team discovers that federated users are still able to successfully perform the initial authentication and obtain active AWS session credentials from outside the corporate network, although they cannot run any subsequent commands after the role is assumed. Which of the following modifications should the solutions architect make to ensure the entire authentication flow and subsequent actions are restricted to the corporate network?

Modify the root-level Service Control Policy (SCP) to explicitly deny the sts:AssumeRole and sts:AssumeRoleWithSAML actions for all principals if the request does not originate from the

203.0.113.0/24

range.

Configure the IAM role trust policy in each member account to use the sts:AssumeRole action instead of sts:AssumeRoleWithSAML, and add a condition block that checks the SAML:iss and SAML:aud attributes along with the aws:SourceIp restriction.

Configure the IAM role trust policy in each member account to include a condition block that restricts the sts:AssumeRoleWithSAML action to the aws:SourceIp range of

203.0.113.0/24

, while retaining the root-level SCP.

Move the existing Service Control Policy (SCP) from the organization root to each specific Organizational Unit (OU) containing the member accounts, and add a statement to exclude the AWS STS service endpoints from the IP restriction condition.

Show answer & explanation

Answer: Configure the IAM role trust policy in each member account to include a condition block that restricts the sts:AssumeRoleWithSAML action to the aws:SourceIp range of $203.0.113.0/24$ , while retaining the root-level SCP.

Answer

Configure the IAM role trust policy in each member account to include a condition block that restricts the sts:AssumeRoleWithSAML action to the aws:SourceIp range of

203.0.113.0/24

, while retaining the root-level SCP.

The correct answer is correct because the initial request to assume a role via SAML federation is made via the sts:AssumeRoleWithSAML API call to the AWS STS service. Because the caller is an external entity (federated user) and does not yet have an IAM principal identity in the AWS Organization, Service Control Policies (SCPs) do not apply to this initial call. Therefore, the SCP cannot block the role assumption based on source IP. To restrict the ability to assume the role, the source IP condition must be evaluated during the trust evaluation, which requires placing the IP restriction directly within the trust policy of the IAM role. The SCP will then properly enforce the IP restriction on any subsequent API requests made by the assumed role's session credentials.

Step-by-Step Solution

Analyze the lifecycle of a federated request via SAML 2.0.

The client POSTs the SAML assertion to the AWS STS endpoint to assume a federated role.

To determine where the request is evaluated and which policies apply at the time of authentication.

Evaluate the applicability of Service Control Policies (SCPs) on the initial STS call.

Since the external caller is not an IAM principal within the Organization, the SCP does not apply to the sts:AssumeRoleWithSAML call.

To understand why the user can still authenticate and obtain credentials from unauthorized networks despite the root-level SCP.

Formulate the correct configuration to secure both role assumption and session usage.

Add the source IP restriction using the aws:SourceIp condition key directly to the IAM role trust policy for the sts:AssumeRoleWithSAML action, while keeping the SCP to restrict subsequent session actions.

To ensure the trust policy restricts the authentication phase and the SCP restricts the active session phase.

Key Concept

Evaluation of trust policies versus Service Control Policies (SCPs) in SAML federation.

Estimated Time:3m 0s

Question 1744Question →

An international automotive logistics enterprise is migrating its legacy ERP and distribution scheduling workloads comprising $45$ physical servers from an on-premises data center to AWS. Security policies mandate that all migration traffic must be completely private, bypassing the public internet. The hybrid network architecture consists of a $10\text{ Gbps}$ AWS Direct Connect connection linked to a Direct Connect Gateway, which is attached to an AWS Transit Gateway. The Transit Gateway routes traffic to a target spoke VPC and a dedicated replication staging area VPC across multiple Availability Zones. The migration team has installed the AWS Application Migration Service (AWS MGN) replication agent on the source servers and configured the replication template to use private IP addresses. However, replication fails to initiate. The agent logs show that the source servers cannot connect to either the AWS MGN control plane endpoints or the replication servers in the staging VPC. Which configuration steps should the solutions architect implement to establish replication connectivity while adhering to the security requirements?

Deploy Interface VPC Endpoints for AWS MGN in the replication staging area VPC. Associate the Amazon Route 53 private hosted zone for the endpoints with the staging area VPC, and configure a Route 53 Resolver inbound endpoint to resolve the service domain from the on-premises environment. Open outbound TCP port

443

and TCP port

1500

on the on-premises firewall to the staging VPC subnets, and configure the AWS Transit Gateway routing tables to allow bidirectional traffic between the on-premises data center and the staging VPC.

Deploy Interface VPC Endpoints for AWS MGN in the replication staging area VPC. Configure Route 53 Resolver inbound endpoints for service name resolution. Open outbound TCP port

443

and TCP port

80

on the on-premises firewall to the staging VPC subnets, and configure a single non-redundant NAT Gateway in the staging VPC to handle outbound traffic. Rely on the NAT Gateway to route the replication traffic over the Direct Connect public virtual interface.

Establish a Direct Connect Gateway connected directly to the target spoke VPC and replication staging VPC using virtual private gateways (VGWs) to bypass the AWS Transit Gateway. Configure Route 53 Resolver outbound endpoints to forward DNS queries to on-premises DNS servers. Open outbound TCP port

443

and TCP port

1500

on the on-premises firewall to the staging VPC CIDR, and configure the staging area security groups to restrict access.

Deploy Interface VPC Endpoints for AWS MGN in the target spoke VPC. Configure Route 53 Resolver inbound endpoints to handle DNS queries from the on-premises network. Open outbound TCP port

443

and TCP port

1500

on the on-premises firewall to the target VPC CIDR. Rely on the assumption that associating the Route 53 Private Hosted Zone with the target VPC automatically enables name resolution and interface endpoint routing for the staging VPC without explicit association.

Show answer & explanation

Answer: Deploy Interface VPC Endpoints for AWS MGN in the replication staging area VPC. Associate the Amazon Route 53 private hosted zone for the endpoints with the staging area VPC, and configure a Route 53 Resolver inbound endpoint to resolve the service domain from the on-premises environment. Open outbound TCP port $443$ and TCP port $1500$ on the on-premises firewall to the staging VPC subnets, and configure the AWS Transit Gateway routing tables to allow bidirectional traffic between the on-premises data center and the staging VPC.

Answer

The configuration option that deploys Interface VPC Endpoints in the replication staging area VPC, configures Route 53 Resolver inbound endpoints, opens TCP ports

443

and

1500

on the firewall, and ensures proper Transit Gateway routing.

Establishing Interface VPC Endpoints for AWS MGN in the replication staging VPC allows the replication servers and agents to access MGN control plane endpoints privately. Associating the Route 53 private hosted zone with the staging VPC and configuring Route 53 Resolver inbound endpoints allows the on-premises servers to resolve the endpoint domain names. Opening outbound TCP port

443

(for control plane communication) and TCP port

1500

(for data replication) on the firewall ensures the agent can establish connectivity. Finally, configuring Transit Gateway routes enables bidirectional private communication between the on-premises environment and the replication staging area.

Step-by-Step Solution

Deploy Interface VPC Endpoints for AWS MGN (e.g., mgn.region.amazonaws.com) in the staging VPC.

Enables private access to the AWS MGN control plane without routing traffic over the public internet.

Security policies prevent any public internet traversal, requiring interface endpoints for control plane API calls.

Associate the Route 53 Private Hosted Zone (PHZ) with the staging VPC and set up Route 53 Resolver inbound endpoints.

Allows on-premises source servers to resolve the AWS MGN endpoint domain names to their private IP addresses in the staging VPC.

The replication agent installed on-premises needs to resolve the control plane endpoints to the private VPC endpoint IPs.

Configure the on-premises firewall to permit outbound traffic to the staging VPC CIDR on TCP port

443

and TCP port

1500

Allows the on-premises agent to establish control plane communication (port

443

) and begin block-level data replication (port

1500

AWS MGN uses TCP port

1500

for data replication to the replication servers and TCP port

443

for control plane orchestration.

Ensure that the AWS Transit Gateway routing tables allow bidirectional traffic between the on-premises network CIDR and the staging VPC subnets.

Establishes network-level connectivity between the source servers and both the interface endpoints and replication servers.

Replication fails if Transit Gateway or Direct Connect Gateway routing blocks bidirectional pathing.

Key Concept

Private infrastructure replication using AWS Application Migration Service (MGN) over Direct Connect and Transit Gateway.

Estimated Time:2m 30s

Question 1745Question →

NovusPay is modernizing its transaction processing engine by migrating it from on-premises virtual machines to Amazon ECS on AWS Fargate in a production AWS account. The container images will be stored in a centralized Amazon ECR repository located in a separate Shared Services AWS account. To comply with strict financial regulations, the ECS tasks must run in private subnets with no route to the internet, and all network traffic to download container images and decrypt keys must be routed privately within the AWS network. The ECR repository must be encrypted at rest, and the production ECS tasks must be able to pull images securely. Which combination of actions should a solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

In the production VPC, create Interface VPC Endpoints (AWS PrivateLink) for com.amazonaws.region.ecr.dkr, com.amazonaws.region.ecr.api, and com.amazonaws.region.kms with Private DNS enabled. Attach a security group to these endpoints that allows inbound HTTPS traffic on port 443 from the security group associated with the Fargate tasks.

Configure the Shared Services ECR repository to use a Customer Managed Key (CMK) for encryption. Update the CMK key policy to grant the production account's ECS task execution role permissions for kms:Decrypt and kms:DescribeKey. In the ECS task definition, configure the network mode to awsvpc.

In the production VPC, create Interface VPC Endpoints for com.amazonaws.region.ecr.dkr, com.amazonaws.region.ecr.api, and com.amazonaws.region.kms. In the ECS task definition, configure the network mode to bridge to enable container port mapping and link the task container to the ECS host network.

Create a Route 53 Private Hosted Zone for ECR in the Shared Services account. Associate this hosted zone only with the Shared Services VPC, and configure a Transit Gateway static route from the production VPC to resolve ECR DNS queries via the Shared Services resolver.

Configure the Shared Services ECR repository to use the AWS-managed KMS key (aws/ecr) for encryption. Modify the key policy in the Shared Services account to grant the production account's ECS task execution role permissions for kms:Decrypt and kms:DescribeKey.

Show answer & explanation

Answer: In the production VPC, create Interface VPC Endpoints (AWS PrivateLink) for com.amazonaws.region.ecr.dkr, com.amazonaws.region.ecr.api, and com.amazonaws.region.kms with Private DNS enabled. Attach a security group to these endpoints that allows inbound HTTPS traffic on port 443 from the security group associated with the Fargate tasks.; Configure the Shared Services ECR repository to use a Customer Managed Key (CMK) for encryption. Update the CMK key policy to grant the production account's ECS task execution role permissions for kms:Decrypt and kms:DescribeKey. In the ECS task definition, configure the network mode to awsvpc.

Answer

Create Interface VPC Endpoints for ECR and KMS in the production VPC with Private DNS enabled, and configure the Shared Services ECR repository with a Customer Managed Key (CMK) that grants the production account's ECS task execution role access to decrypt the key, while using the awsvpc network mode in the task definition.

To support private cross-account image pulling on AWS Fargate without internet routing, the production VPC must have Interface VPC Endpoints (PrivateLink) configured for both ECR endpoints (api and dkr) and KMS, with private DNS enabled so the tasks resolve the endpoints locally. Additionally, Fargate tasks must use the awsvpc network mode. Because the ECR repository is in a separate account, it must be encrypted with a Customer Managed Key (CMK) rather than the default AWS-managed key, because the policy of an AWS-managed key cannot be altered to grant cross-account permissions to the production account's ECS task execution role.

Step-by-Step Solution

Analyze Fargate network mode requirements.

Identify that AWS Fargate tasks exclusively use the awsvpc network mode, which rules out options using host or bridge network configurations.

Choosing the correct network mode is required for Fargate tasks to initialize and launch successfully.

Address private connection requirements to AWS services.

Create Interface VPC Endpoints (PrivateLink) for com.amazonaws.region.ecr.dkr, com.amazonaws.region.ecr.api, and com.amazonaws.region.kms in the production VPC.

Since the tasks run in private subnets with no internet route, image downloading and KMS calls must traverse AWS PrivateLink.

Resolve cross-account KMS key requirements for ECR.

Avoid using the default AWS-managed KMS key (aws/ecr) because it cannot be modified. Configure a Customer Managed Key (CMK) on the ECR repository and authorize the production account's ECS task execution role in its key policy.

Cross-account access to encrypted ECR images requires a CMK with a resource-based policy that explicitly grants access to the external account's role.

Key Concept

Configuring private cross-account image pulling for AWS Fargate using VPC interface endpoints and custom KMS key policies.

Estimated Time:3m 0s

Question 1746Question →

An organization is modernizing its legacy logistics tracking application by migrating its backend logic to AWS Lambda functions fronted by Amazon API Gateway. The Lambda functions must access an Amazon RDS for PostgreSQL database located in a private subnet of a VPC, and must also invoke external carrier APIs over the internet. Additionally, the application must write encrypted daily tracking reports to an S3 bucket in a separate billing-focused AWS account managed by a compliance team.

The system regularly experiences sudden, high-volume bursts of requests. The modernization architecture must meet the following constraints:
- High Availability: Internet-bound outbound traffic from the Lambda functions must remain functional even during an Availability Zone outage.
- Security: The compliance reports in S3 must be encrypted using a key managed by the compliance account, with permission safely granted to the logistics Lambda function.
- Resource Protection: A sudden surge in tracking API requests must not exhaust the execution capacity of other critical serverless workloads running in the same regional AWS account.
- Deployment Safety: Deployments of new Lambda function versions must shift traffic progressively and rollback automatically if execution errors spike.

Which of the following architectural designs satisfies all of these requirements?

Deploy the Lambda functions in private subnets across multiple Availability Zones, routing outbound internet traffic via redundant NAT Gateways (one per Availability Zone). Configure Reserved Concurrency on the Lambda functions to protect the shared account concurrency pool. Use AWS CodeDeploy with a Canary configuration and CloudWatch Alarms to handle deployments and rollbacks. Configure the compliance S3 bucket to use the default AWS-managed KMS key (aws/s3) in the compliance account, and grant the Lambda function's IAM role permissions to use this key.

Deploy the Lambda functions in private subnets across multiple Availability Zones, routing outbound internet traffic via redundant NAT Gateways (one per Availability Zone). Configure Reserved Concurrency on the Lambda functions to protect the shared account concurrency pool. Use AWS CodeDeploy with a Canary configuration and CloudWatch Alarms to handle deployments and rollbacks. Configure the compliance S3 bucket to use a KMS Customer Managed Key in the compliance account, and update its key policy to allow access from the Lambda function's IAM role.

Deploy the Lambda functions in private subnets across multiple Availability Zones, routing outbound internet traffic through a single NAT Gateway located in a single public subnet to simplify the network topology. Configure Reserved Concurrency on the Lambda functions to protect the shared account concurrency pool. Use AWS CodeDeploy with a Canary configuration and CloudWatch Alarms to handle deployments and rollbacks. Configure the compliance S3 bucket to use a KMS Customer Managed Key in the compliance account, and update its key policy to allow access from the Lambda function's IAM role.

Deploy the Lambda functions in private subnets across multiple Availability Zones, routing outbound internet traffic via redundant NAT Gateways (one per Availability Zone). Rely on the regional unreserved concurrency pool to allow the Lambda functions to scale dynamically during spikes. Use AWS CodeDeploy with a Canary configuration and CloudWatch Alarms to handle deployments and rollbacks. Configure the compliance S3 bucket to use a KMS Customer Managed Key in the compliance account, and update its key policy to allow access from the Lambda function's IAM role.

Show answer & explanation

Answer: Deploy the Lambda functions in private subnets across multiple Availability Zones, routing outbound internet traffic via redundant NAT Gateways (one per Availability Zone). Configure Reserved Concurrency on the Lambda functions to protect the shared account concurrency pool. Use AWS CodeDeploy with a Canary configuration and CloudWatch Alarms to handle deployments and rollbacks. Configure the compliance S3 bucket to use a KMS Customer Managed Key in the compliance account, and update its key policy to allow access from the Lambda function's IAM role.

Answer

Deploy the Lambda functions in private subnets across multiple Availability Zones with redundant NAT Gateways, configure Reserved Concurrency, use CodeDeploy Canary shifting with CloudWatch Alarms, and encrypt S3 uploads with a cross-account KMS Customer Managed Key.

The correct solution addresses all architecture requirements: 1) deploying redundant NAT Gateways across Availability Zones prevents a single AZ outage from interrupting outbound internet connectivity; 2) specifying Reserved Concurrency prevents concurrency exhaustion for other applications in the same account; 3) configuring AWS CodeDeploy with a Canary configuration allows automated progressive shifting and metric-based rollback; 4) a Customer Managed Key in the compliance account can be explicitly shared with the Lambda role via key policy, which is impossible with AWS-managed keys.

Step-by-Step Solution

Configure networking and NAT Gateways for multi-AZ high availability.

Deploying the Lambda function across private subnets in multiple Availability Zones and routing internet-bound traffic through redundant NAT Gateways (one per Availability Zone) ensures that an outage in a single Availability Zone does not impact outbound traffic.

Outbound internet access is required to connect to external carrier APIs, and redundant NAT Gateways prevent single points of failure.

Configure Lambda Reserved Concurrency.

Reserved Concurrency limits the maximum concurrent executions of the tracking function and guarantees that execution capacity is set aside for it.

This prevents a sudden, high-volume spike from consuming the entire regional unreserved concurrency limit, protecting other serverless workloads in the account from throttling.

Establish progressive traffic shifting and rollback mechanism.

CodeDeploy handles progressive traffic shifting (Canary) between Lambda versions, monitoring CloudWatch Alarms for errors to trigger an automatic rollback.

This meets the deployment safety constraint to shift traffic gradually and roll back on failures automatically.

Configure cross-account KMS Customer Managed Key.

The compliance account creates a Customer Managed Key (CMK) and updates its key policy to allow the tracking Lambda's execution role to perform encryption operations. The Lambda function uses this CMK when uploading to S3.

AWS-managed KMS keys (like aws/s3) cannot be shared across accounts because their key policies cannot be customized. Only Customer Managed Keys support cross-account sharing.

Key Concept

Designing highly available, secure, and isolated serverless architectures involving cross-account resource access, redundant VPC networking, and concurrency controls.

Estimated Time:3m 0s

Question 1747Question →

A multinational retail company uses a centralized CI/CD pipeline in a Tooling AWS account to deploy and update infrastructure across multiple target accounts in an AWS Organization. The pipeline uses AWS CloudFormation StackSets to deploy standard Amazon EC2 instances and associated security groups. Recently, developers in target accounts have manually modified security group ingress rules to troubleshoot connectivity issues. These manual changes have created security vulnerabilities and caused subsequent CI/CD pipeline updates to fail due to undetected configuration drift. The company needs a solution that prevents manual modifications to resources managed by CloudFormation, ensures that deployment templates are securely shared and accessible cross-account, and automatically alerts the DevOps team if drift is detected. Which solution should the solutions architect implement to meet these requirements?

Store the CloudFormation templates in an S3 bucket in the Tooling account encrypted with a Customer Managed Key (CMK). Configure the CMK key policy and S3 bucket policy to allow read access from the target accounts. Implement a Service Control Policy (SCP) that denies all IAM users and roles in target accounts from modifying resources containing the tag 'aws:cloudformation:stack-name', unless the caller is the CloudFormation service role or the CI/CD pipeline role. Configure AWS Config in the target accounts to run the 'cloudformation-stack-drift-detection-check' rule and send alerts via Amazon SNS.

Store the CloudFormation templates in an S3 bucket in the Tooling account encrypted with the default AWS-managed KMS key ('aws/s3'). Configure the S3 bucket policy and the target accounts' IAM policies to allow cross-account access to read the templates. Configure AWS Config in the target accounts to monitor security groups and automatically delete any drifted resources to force them back to the template state.

Store the CloudFormation templates in an S3 bucket in the Tooling account encrypted with a Customer Managed Key (CMK). Attach a Service Control Policy (SCP) to the target OUs that explicitly grants read and write permissions to the CI/CD pipeline role and denies modification of security groups for all other roles. Rely on this SCP to grant the necessary deployment permissions in the target accounts without configuring local IAM policies.

Store the CloudFormation templates in an S3 bucket in the Tooling account. Allow developers to modify security groups manually. Configure AWS Config rules in target accounts to detect drift. When drift is detected, trigger an AWS Systems Manager State Manager association to run a script that uses the AWS CLI to force the CloudFormation stack status to 'UPDATE_COMPLETE' in the target account, and then manually run 'aws ec2 authorize-security-group-ingress' to align the configuration.

Show answer & explanation

Answer: Store the CloudFormation templates in an S3 bucket in the Tooling account encrypted with a Customer Managed Key (CMK). Configure the CMK key policy and S3 bucket policy to allow read access from the target accounts. Implement a Service Control Policy (SCP) that denies all IAM users and roles in target accounts from modifying resources containing the tag 'aws:cloudformation:stack-name', unless the caller is the CloudFormation service role or the CI/CD pipeline role. Configure AWS Config in the target accounts to run the 'cloudformation-stack-drift-detection-check' rule and send alerts via Amazon SNS.

Answer

Store templates in an S3 bucket encrypted with a Customer Managed Key (CMK) while sharing it cross-account, use an SCP to deny modifications to resources containing the CloudFormation stack tag unless performed by the deployment roles, and configure AWS Config to detect and alert on stack drift.

The correct option correctly uses a Customer Managed Key (CMK) to allow cross-account access, which is required because default AWS-managed KMS keys do not support key policy modifications for cross-account sharing. It also applies an SCP with a condition on the 'aws:cloudformation:stack-name' tag to prevent manual drift while allowing the deployment roles to perform updates. Finally, it uses the native AWS Config stack drift detection rule for automated compliance monitoring.

Step-by-Step Solution

Select the correct KMS key type for cross-account artifact sharing.

Use a Customer Managed Key (CMK) instead of the default AWS-managed KMS key, since the default key's policy cannot be modified to grant cross-account permissions.

Target accounts need to decrypt and read the CloudFormation templates stored in the Tooling account's S3 bucket.

Enforce infrastructure-as-code configuration limits using Service Control Policies (SCPs).

Implement an SCP that denies resource modifications for resources tagged with 'aws:cloudformation:stack-name', with an exception for the CloudFormation service role and the pipeline execution role.

This prevents manual modifications in target accounts that cause configuration drift, while allowing authorized CI/CD deployment roles to update the infrastructure.

Configure compliance monitoring and alerting.

Deploy the AWS Config rule 'cloudformation-stack-drift-detection-check' to automatically monitor stack drift and alert via SNS.

This ensures the DevOps team receives immediate notifications when configuration drift is detected, allowing for investigation and remediation.

Key Concept

Cross-account deployment automation, KMS key sharing constraints, and configuration drift prevention using SCPs and AWS Config.

Question 1748Question →

An enterprise operates a multi-account environment within AWS Organizations consisting of 80 member accounts. The security team requires all AWS CloudTrail API activity logs to be consolidated into a single Amazon S3 bucket located in a dedicated Security account. The logs must be encrypted at rest using a customer managed key (KMS CMK) to comply with regulatory standards. The solution must also prevent member accounts from modifying or disabling the logging configuration. Which TWO actions must the solutions architect perform to implement this solution?

Select all that apply

Create a multi-region organization trail from the organization's management account that delivers logs to the S3 bucket in the Security account, and configure a key policy on a customer managed KMS key in the Security account that grants the AWS CloudTrail service principal permissions to perform the kms:GenerateDataKey* and kms:Decrypt actions.

Configure the S3 bucket policy in the Security account to allow s3:PutObject and s3:GetBucketAcl actions for the AWS CloudTrail service principal, specifying the organization's management account ID in the S3 resource path and applying a condition that matches the AWS Organization ID.

Enable default encryption on the centralized S3 bucket using the AWS-managed KMS key (aws/s3) in the Security account, and configure the key policy of aws/s3 to allow cross-account access for the CloudTrail service principal.

Attach a Service Control Policy (SCP) to the organization root that explicitly grants s3:PutObject permissions to all member accounts, allowing local IAM roles to write log files directly to the centralized S3 bucket.

Configure the S3 bucket policy in the Security account to grant read and write access to all member accounts by using a wildcard principal (*) and relying on AWS Resource Access Manager (RAM) to share the bucket with the organization.

Show answer & explanation

Answer: Create a multi-region organization trail from the organization's management account that delivers logs to the S3 bucket in the Security account, and configure a key policy on a customer managed KMS key in the Security account that grants the AWS CloudTrail service principal permissions to perform the kms:GenerateDataKey* and kms:Decrypt actions.; Configure the S3 bucket policy in the Security account to allow s3:PutObject and s3:GetBucketAcl actions for the AWS CloudTrail service principal, specifying the organization's management account ID in the S3 resource path and applying a condition that matches the AWS Organization ID.

Answer

Create a multi-region organization trail from the organization's management account that delivers logs to the S3 bucket in the Security account, configure a key policy on a customer managed KMS key in the Security account that grants the AWS CloudTrail service principal permissions to perform the kms:GenerateDataKey* and kms:Decrypt actions, and configure the S3 bucket policy in the Security account to allow s3:PutObject and s3:GetBucketAcl actions for the AWS CloudTrail service principal under the organization ID condition.

To implement centralized CloudTrail logging across an AWS Organization, a multi-region organization trail must be created from the management account. This trail consolidates logs in the target S3 bucket and prevents member accounts from tampering with the configuration. The target S3 bucket policy must explicitly permit the CloudTrail service principal to perform write operations, and the customer managed KMS key policy must authorize CloudTrail to perform cryptographic actions for log encryption.

Step-by-Step Solution

Configure the centralized S3 bucket in the Security account.

An S3 bucket is created with a bucket policy allowing 'cloudtrail.amazonaws.com' to call s3:PutObject and s3:GetBucketAcl, restricted to the organization ID.

This establishes a secure, cross-account log destination for all member accounts within the AWS Organization.

Set up encryption using a customer managed key.

A customer managed KMS key (CMK) is created with a key policy allowing 'cloudtrail.amazonaws.com' to generate data keys and decrypt.

AWS CloudTrail requires explicit KMS key policy permissions on customer managed keys to encrypt logs delivered to an S3 bucket in a different account.

Deploy the organization-wide CloudTrail configuration.

A multi-region organization trail is created from the management account.

An organization trail automatically applies to all member accounts, consolidates API logging centrally, and prevents member accounts from modifying the trail.

Key Concept

Centralized Monitoring, Logging, and Auditing Solutions

Estimated Time:3m 0s

Question 1749Question →

A healthcare provider stores $800\text{ TB}$ of patient medical imaging records in an Amazon S3 bucket in the `us-east-1` region. The records are accessed frequently during the first $30\text{ days}$ . After $30\text{ days}$ , access drops to less than $1\%$ of the records per month, but the records must be retained indefinitely. When an archived record is requested by a physician, it must be retrieved within $4\text{ hours}$ . The provider wants to minimize both storage and data retrieval costs. Which of the following lifecycle policies represents the most cost-effective and architecturally sound configuration?

Transition the objects to Amazon S3 Glacier Instant Retrieval after

30\text{ days}

. Use millisecond retrievals when records are requested.

Transition the objects to Amazon S3 Glacier Flexible Retrieval after

30\text{ days}

. Use Standard retrieval (3 to 5 hours) when records are requested.

Transition the objects to Amazon S3 Glacier Deep Archive after

30\text{ days}

. Use Standard retrieval (12 hours) when records are requested.

Transition the objects to Amazon S3 Glacier Flexible Retrieval after

30\text{ days}

. Use Expedited retrieval (1 to 5 minutes) when records are requested.

Show answer & explanation

Answer: Transition the objects to Amazon S3 Glacier Flexible Retrieval after $30\text{ days}$ . Use Standard retrieval (3 to 5 hours) when records are requested.

Answer

Transition the objects to Amazon S3 Glacier Flexible Retrieval after 30 days and use Standard retrieval (3 to 5 hours) when records are requested.

Transitioning to Amazon S3 Glacier Flexible Retrieval and using Standard retrieval is the most cost-effective option. S3 Glacier Flexible Retrieval has lower monthly storage costs than S3 Glacier Instant Retrieval. Standard retrieval (taking 3 to 5 hours) fits within the required 4-hour window, and unlike Expedited retrieval or Instant Retrieval, Standard retrieval carries no data retrieval charge per gigabyte.

Step-by-Step Solution

Analyze the retrieval time SLA requirement.

The physician requires access to archived records within 4 hours.

This requirement determines which Amazon S3 storage classes and retrieval tiers can be considered.

Evaluate S3 Glacier storage classes and their retrieval times against the 4-hour SLA.

S3 Glacier Deep Archive standard retrieval takes 12 hours (violating the SLA). S3 Glacier Flexible Retrieval standard retrieval takes 3-5 hours (meets the SLA). S3 Glacier Instant Retrieval takes milliseconds (meets the SLA).

Eliminating options that do not meet the recovery time objective prevents compliance failures.

Compare storage and retrieval costs of compliant options.

S3 Glacier Flexible Retrieval has lower monthly storage costs than S3 Glacier Instant Retrieval, and its Standard retrieval option has no data retrieval charge. Expedited retrieval on Glacier Flexible Retrieval carries a high cost per GB and is unnecessary.

Selecting the option with the lowest combined storage and retrieval costs satisfies the cost-optimization requirement.

Key Concept

S3 Lifecycle and retrieval cost optimization matching business SLAs

Estimated Time:2m 0s

Question 1750Question →

Quantex Analytics is modernizing its on-premises portfolio risk simulation engine by migrating to AWS. The current application runs on VMware virtual machines and suffers from scaling limitations during peak market hours. The modernized workload will be deployed as containerized tasks using Amazon ECS on Amazon EC2 instances across multiple Availability Zones to ensure high availability. The application consists of microservices that require low-latency communication and must be tuned with specific kernel parameters (such as net.core.somaxconn) at the container level. The container images must be securely pulled from a centralized Amazon ECR repository in a shared services AWS account. Security policies dictate that all image traffic must remain entirely within the private network without traversing the public internet, and the overall system design must maintain a Recovery Time Objective (RTO) of under 10 minutes and eliminate single points of network failure. Which combination of actions should the solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Configure the Amazon ECS task definition to use the awsvpc network mode, and specify the required sysctls parameters in the container definitions.

In the production VPC, create Interface VPC endpoints for Amazon ECR (com.amazonaws.region.ecr.api and com.amazonaws.region.ecr.dkr) and a Gateway VPC endpoint for Amazon S3. Configure the repository policy of the Amazon ECR registry in the shared services account to allow pull permissions for the ECS task execution role in the production account.

Configure the Amazon ECS task definition to use the host network mode, and specify the required sysctls parameters in the container definitions.

Configure the Amazon ECR repository in the shared services account to use the AWS-managed KMS key for ECR (aws/ecr) for encryption, and add the production account's ECS task execution role to the key policy of the AWS-managed key.

In the production VPC, deploy a single NAT Gateway in a public subnet, and configure the private subnet route tables to direct all outbound ECR traffic through the NAT Gateway using public Amazon ECR endpoints.

Show answer & explanation

Answer: Configure the Amazon ECS task definition to use the awsvpc network mode, and specify the required sysctls parameters in the container definitions.; In the production VPC, create Interface VPC endpoints for Amazon ECR (com.amazonaws.region.ecr.api and com.amazonaws.region.ecr.dkr) and a Gateway VPC endpoint for Amazon S3. Configure the repository policy of the Amazon ECR registry in the shared services account to allow pull permissions for the ECS task execution role in the production account.

Answer

Configure the task definition to use the awsvpc network mode with the specified sysctls parameters, and create ECR interface VPC endpoints along with an S3 gateway endpoint in the production VPC while updating the shared ECR repository policy.

Configuring the ECS task definition to use the awsvpc network mode allows specifying sysctls settings at the container definition level, which satisfies the kernel tuning requirement. Additionally, creating the ECR api, ECR dkr, and S3 gateway endpoints in the production VPC establishes a secure, private network path that keeps image traffic off the public internet, while updating the shared ECR repository policy grants the necessary cross-account pull permissions.

Step-by-Step Solution

Select the correct ECS network mode to support custom kernel tuning (sysctls).

The awsvpc network mode is chosen because it supports task-level network isolation and container-level sysctls configuration, whereas the host network mode does not support sysctls.

ECS tasks running on EC2 require bridge or awsvpc network modes to customize kernel parameters through sysctls without modifying the underlying host directly.

Establish secure, private connectivity from the production VPC to Amazon ECR in the shared services account.

Interface VPC endpoints for ECR (api and dkr) and a Gateway VPC endpoint for S3 are created inside the production VPC.

This configuration allows ECR traffic to route over the private AWS backbone without traversing the public internet, satisfying the network privacy requirement.

Configure cross-account permissions for container image retrieval.

The ECR repository policy in the shared services account is updated to grant pull permissions to the IAM task execution role in the production account.

The task execution role requires permissions to perform batch get and get download URL operations against the shared repository to instantiate the container.

Key Concept

Configuring Amazon ECS task networking and private cross-account image pulling using VPC endpoints and repository policies.

Question 1751Question →

An online multiplayer gaming studio is planning to migrate its hybrid game engine and account management system to AWS. The on-premises environment consists of:

* 150 virtual machines (VMs) hosted on VMware vSphere running standard CentOS and Windows Server.
* 10 bare-metal physical servers running FreeBSD for legacy matchmaking lobbies.
* 5 bare-metal physical servers running IBM AIX for legacy transaction processing.

The studio's security policy strictly prohibits installing third-party agents on any database virtual machines running on VMware. However, the studio requires deep network connection dependency mapping and process-level details for the non-database VMs on VMware to optimize the target cloud architecture. Additionally, they want to track the overall migration progress in a single dashboard, including servers migrated using a custom third-party migration tool.

Which combination of actions should the solutions architect recommend to discover this inventory and track the migration? (Select TWO.)

Select all that apply

Deploy the AWS Application Discovery Agent on the non-database VMware VMs to collect process-level and network connection details, and use the Application Discovery Service import process with a CSV template to import data for the bare-metal servers and database VMs.

Integrate the third-party migration tool with AWS Migration Hub by configuring the tool to call the Migration Hub APIs to publish migration status, and monitor the overall progress from the Migration Hub console.

Deploy the AWS Application Discovery Agentless Collector on the VMware vCenter Server to collect network dependency mappings for all VMs, and configure a single non-redundant NAT Gateway in one Availability Zone to route the discovery data back to AWS.

Install the AWS Systems Manager Agent (SSM Agent) and CloudWatch Agent on all VMware VMs and bare-metal servers, and use a custom CloudWatch log path pattern to scrape process dependencies and publish them to Migration Hub.

Install the AWS Application Migration Service (MGN) replication agent on the bare-metal FreeBSD and IBM AIX servers to discover their configurations, and ensure TCP port 1500 is open in the on-premises firewall for the discovery traffic.

Show answer & explanation

Answer: Deploy the AWS Application Discovery Agent on the non-database VMware VMs to collect process-level and network connection details, and use the Application Discovery Service import process with a CSV template to import data for the bare-metal servers and database VMs.; Integrate the third-party migration tool with AWS Migration Hub by configuring the tool to call the Migration Hub APIs to publish migration status, and monitor the overall progress from the Migration Hub console.

Answer

The correct actions are: deploying the AWS Application Discovery Agent on the non-database VMware VMs while importing bare-metal and database server details using a CSV template, and integrating the third-party migration tool with AWS Migration Hub via APIs to track progress.

Deploying the AWS Application Discovery Agent on the non-database VMware VMs satisfies the requirement for process-level and network dependency mapping. Because database VMs are prohibited from having agents and the bare-metal FreeBSD and IBM AIX servers run operating systems that are unsupported by the discovery agent and collector, importing their specifications via the Application Discovery Service CSV template is the only valid discovery method. Integrating the third-party tool with Migration Hub using API calls allows status updates to be published and monitored from the Migration Hub console, providing a single tracking dashboard.

Step-by-Step Solution

Analyze on-premises OS compatibility and security restrictions for discovery.

Identify that the database VMs cannot have agents, and that the FreeBSD and IBM AIX bare-metal servers run operating systems unsupported by standard AWS discovery tools.

This determines that these servers must be cataloged using the Application Discovery Service CSV import template.

Select the correct discovery mechanism for the remaining VMware VMs.

Recommend the AWS Application Discovery Agent (agent-based) for the non-database CentOS and Windows VMs.

The studio requires deep process-level details and network connection dependency mapping, which can only be gathered by the agent, not the Agentless Collector.

Establish migration tracking integration for the third-party tool.

Configure the third-party migration tool to publish status updates using the AWS Migration Hub APIs.

This allows all migrated servers to be visualized in the single Migration Hub dashboard alongside native migrations.

Key Concept

AWS Application Discovery Service supports agent-based discovery, agentless discovery, and CSV imports. The agent-based approach is required for process-level and network dependency mapping. Unsupported operating systems (such as FreeBSD and AIX) and systems with agent installation restrictions must be cataloged using CSV imports. AWS Migration Hub provides a central console to track migration progress using AWS tools and integrated third-party tools via API.

Question 1752Question →

A company is designing a hybrid network architecture to connect multiple spoke VPCs in the us-west-2 Region to their on-premises datacenter. The network design must satisfy the following requirements:
- Enable transitive VPC-to-VPC routing and hybrid VPC-to-premises routing.
- Resolve private DNS domains bidirectionally between the AWS environment and the on-premises datacenter.
- Maintain high availability and minimize single points of failure.

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

Select all that apply

Associate the AWS Transit Gateway with the Direct Connect Gateway, and establish a Transit Virtual Interface (Transit VIF) on the Direct Connect connection to connect to the Direct Connect Gateway.

Deploy Route 53 Resolver Inbound Endpoints in a shared services VPC to receive DNS queries from the on-premises datacenter, and configure Route 53 Resolver Outbound Endpoints to forward AWS internal DNS queries for on-premises domains to the on-premises DNS servers.

Connect the Direct Connect Gateway directly to the Virtual Private Gateway (VGW) of each spoke VPC using Private Virtual Interfaces (Private VIFs) to enable transitive routing between the VPCs.

Configure the on-premises DNS servers to forward queries for the AWS Private Hosted Zone (PHZ) directly to the AWS default resolver IP address (

169.254.169.253

) over the Direct Connect connection.

Deploy a single NAT Gateway in a shared services VPC, and route all hybrid DNS queries and private network traffic through it to the on-premises datacenter.

Show answer & explanation

Answer: Associate the AWS Transit Gateway with the Direct Connect Gateway, and establish a Transit Virtual Interface (Transit VIF) on the Direct Connect connection to connect to the Direct Connect Gateway.; Deploy Route 53 Resolver Inbound Endpoints in a shared services VPC to receive DNS queries from the on-premises datacenter, and configure Route 53 Resolver Outbound Endpoints to forward AWS internal DNS queries for on-premises domains to the on-premises DNS servers.

Answer

To satisfy the requirements, the Solutions Architect must associate the AWS Transit Gateway with the Direct Connect Gateway using a Transit VIF, and deploy Route 53 Resolver Inbound and Outbound Endpoints to facilitate private DNS resolution.

Associating the AWS Transit Gateway with the Direct Connect Gateway using a Transit VIF enables transitive routing between the on-premises datacenter and multiple VPCs. Configuring Route 53 Resolver Inbound and Outbound Endpoints enables private bidirectional DNS resolution between AWS and on-premises networks over the private connection.

Step-by-Step Solution

Analyze routing requirements

The architecture requires transitive VPC-to-VPC and VPC-to-premises routing.

An AWS Transit Gateway (TGW) associated with a Direct Connect Gateway (DXGW) via a Transit VIF is the standard architecture for multi-VPC transitive hybrid routing.

Analyze DNS resolution requirements

On-premises systems need to resolve AWS PHZs, and AWS resources need to resolve on-premises DNS.

Route 53 Resolver Inbound Endpoints receive queries from on-premises, and Outbound Endpoints forward queries to on-premises DNS servers over the private network connection.

Key Concept

Hybrid network routing and DNS resolution using Transit Gateway and Route 53 Resolvers.

Estimated Time:2m 0s

Question 1753Question →

An enterprise needs to migrate $800\text{ TB}$ of data from an on-premises NFS file system to an Amazon FSx for NetApp ONTAP file system in a target AWS account. The enterprise has a $300\text{ Mbps}$ dedicated network connection to AWS. The migration must be completed within $21\text{ days}$ . During this period, the on-premises file system will remain active, generating approximately $15\text{ TB}$ of incremental changes. The target file system must encrypt all data at rest using a customer managed key (CMK) in AWS KMS. Which of the following migration strategies is the most efficient and meets these requirements?

Order multiple AWS Snowball Edge Storage Optimized devices. Configure the Snowball jobs to use a destination Amazon S3 bucket and a KMS Customer Managed Key (CMK) for encryption. Copy the data from the on-premises NFS file system to the devices via their NFS interface. Once the data is imported to Amazon S3, use AWS DataSync to copy the data from the S3 bucket to the Amazon FSx for NetApp ONTAP file system. Deploy an on-premises AWS DataSync agent to perform a final incremental sync of the

15\text{ TB}

delta from the on-premises NFS file system directly to the FSx for NetApp ONTAP file system.

Order multiple AWS Snowball Edge Storage Optimized devices, specifying the Amazon FSx for NetApp ONTAP file system directly as the job's destination storage. Configure the Snowball jobs to encrypt the transferred data using the default AWS-managed KMS key (aws/s3). After the devices are processed, deploy an on-premises AWS DataSync agent to sync the remaining

15\text{ TB}

delta directly from the on-premises NFS file system to the FSx for NetApp ONTAP file system.

Deploy AWS DataSync agents on-premises. Set up an AWS Direct Connect connection with a Direct Connect gateway. Associate the Direct Connect gateway directly with both the VPC containing the DataSync agent and the VPC containing the Amazon FSx for NetApp ONTAP file system to establish transitive routing between them. Run an online DataSync task over this connection to copy the entire

800\text{ TB}

dataset and all subsequent changes directly to the FSx for NetApp ONTAP file system.

Order multiple AWS Snowball Edge Storage Optimized devices, specifying an Amazon S3 bucket as the destination and using a KMS Customer Managed Key (CMK). Copy the data to the devices. Once the data is imported to S3, set up an AWS Transfer Family SFTP server to pull the data from S3 and write it to the FSx for NetApp ONTAP file system. Use an on-premises SFTP client to transfer the

15\text{ TB}

delta over the

300\text{ Mbps}

link.

Show answer & explanation

Answer: Order multiple AWS Snowball Edge Storage Optimized devices. Configure the Snowball jobs to use a destination Amazon S3 bucket and a KMS Customer Managed Key (CMK) for encryption. Copy the data from the on-premises NFS file system to the devices via their NFS interface. Once the data is imported to Amazon S3, use AWS DataSync to copy the data from the S3 bucket to the Amazon FSx for NetApp ONTAP file system. Deploy an on-premises AWS DataSync agent to perform a final incremental sync of the $15\text{ TB}$ delta from the on-premises NFS file system directly to the FSx for NetApp ONTAP file system.

Answer

The most efficient strategy is to order multiple AWS Snowball Edge Storage Optimized devices to physically ship the

800\text{ TB}

of data encrypted with a Customer Managed Key (CMK) to Amazon S3, use AWS DataSync to copy that data from S3 to the target Amazon FSx for NetApp ONTAP file system, and use an on-premises AWS DataSync agent to sync the remaining

15\text{ TB}

delta over the dedicated network connection.

The correct strategy uses AWS Snowball Edge Storage Optimized devices to overcome the physical throughput limitations of the

300\text{ Mbps}

network link. Because Snowball Edge cannot directly target Amazon FSx, data must land in Amazon S3 first, encrypted using a KMS Customer Managed Key (CMK), which is required for Snowball Edge. AWS DataSync is then used to transfer the files from S3 to the FSx for NetApp ONTAP target. The final

15\text{ TB}

delta is copied online using an on-premises AWS DataSync agent, which can easily complete the incremental sync within the remaining time window.

Step-by-Step Solution

Calculate the network transfer time for the initial

800\text{ TB}

dataset over the

300\text{ Mbps}

connection.

300\text{ Mbps}

(assuming

80\%

network utilization), transferring

800\text{ TB}

takes approximately 308 days. This violates the 21-day migration timeline constraint, proving that offline transfer via the Snow Family is required.

To identify the necessity of offline data transfer based on physical time constraints.

Configure the AWS Snowball Edge job requirements, specifically the target service and encryption key types.

The target must be set to Amazon S3 (as Snowball does not support direct import to Amazon FSx). A KMS Customer Managed Key (CMK) must be selected because AWS Snowball Edge cannot modify policies on AWS-managed keys (like aws/s3) to grant permissions to the Snowball service.

To satisfy encryption compliance and Snowball service requirements.

Establish the internal AWS transfer path from the S3 staging bucket to the target FSx for NetApp ONTAP file system.

Configure AWS DataSync with the imported S3 bucket as the source and the FSx for NetApp ONTAP file system as the destination, running the sync task internally within AWS.

To move the bulk data to the final destination file system after the physical devices are ingested by AWS.

Plan the delta migration phase for the

15\text{ TB}

of changes.

Deploy an on-premises AWS DataSync agent to transfer the

15\text{ TB}

delta directly to the FSx for NetApp ONTAP file system over the network, which takes approximately 6 days and fits within the 21-day migration window.

To capture files modified during the Snowball shipping transit period without performing another full copy.

Key Concept

Selecting the optimal hybrid migration path using AWS Snowball Edge and AWS DataSync under tight time and bandwidth constraints.

Question 1754Question →

A pharmaceutical company operates a multi-account AWS environment with $60$ spoke VPCs distributed across the `us-east-1` and `us-west-2` Regions. The on-premises network is connected to AWS via a $10\text{ Gbps}$ AWS Direct Connect connection. The company requires a highly available network architecture that minimizes administrative overhead and meets the following criteria:
1. All outbound internet traffic from the spoke VPCs must be centralized and routed through a cluster of security appliances in a dedicated Transit VPC in each region.
2. Spoke VPCs must resolve DNS queries for on-premises domain names ending in `.corp` via the Direct Connect connection.
3. On-premises hosts must resolve resource records in an AWS Route 53 Private Hosted Zone (PHZ) named `aws.internal`.

Which hybrid and multi-account network architecture should a solutions architect design to satisfy these requirements?

Establish VPC peering connections between all

60

spoke VPCs and the central Transit VPC in each region to route outbound traffic. Create Route 53 Resolver Inbound and Outbound Endpoints in the Transit VPC. Associate the `aws.internal` PHZ with the Transit VPC only, and configure the spoke VPCs to forward all DNS queries to the Transit VPC's inbound resolver IP. Create a Route 53 Resolver forwarding rule for `.corp` pointing to the on-premises DNS servers and associate it with the Transit VPC.

Associate the AWS Direct Connect Gateway directly with the virtual private gateways (VGWs) of all

60

spoke VPCs. Configure a default route of

0.0.0.0/0

in each spoke VPC's route table pointing to its local VGW to route internet-bound traffic through the on-premises security appliances. Create Route 53 Resolver forwarding rules inside each spoke VPC's Route 53 configuration to resolve `.corp` domains, and configure on-premises DNS to target the default AWS DNS resolver IPs.

Deploy an AWS Transit Gateway (TGW) in each region and peer them. Attach the spoke VPCs and the regional Transit VPC to the local TGW. In the TGW route table for the spoke VPCs, configure a static route for

0.0.0.0/0

pointing to the Transit VPC attachment. Create Route 53 Resolver Inbound and Outbound Endpoints in a centralized network services VPC in each region. Share a Route 53 Resolver forwarding rule for `.corp` pointing to the on-premises DNS servers across the AWS Organization using AWS Resource Access Manager (RAM) and associate it with all VPCs. Associate the `aws.internal` PHZ with all VPCs in both regions, and configure on-premises DNS to forward queries for `aws.internal` to the Inbound Endpoint IP addresses.

Deploy a single AWS Transit Gateway in the `us-east-1` Region, and attach all spoke VPCs from both regions to it. Route all outbound internet traffic from all spoke VPCs to a single NAT Gateway located in the Transit VPC of `us-east-1`. Create a Route 53 Resolver Outbound Endpoint in `us-east-1` and configure it to forward all queries to the on-premises DNS. Associate the `aws.internal` PHZ directly with the Transit Gateway to share it with all attached VPCs.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway (TGW) in each region and peer them. Attach the spoke VPCs and the regional Transit VPC to the local TGW. In the TGW route table for the spoke VPCs, configure a static route for $0.0.0.0/0$ pointing to the Transit VPC attachment. Create Route 53 Resolver Inbound and Outbound Endpoints in a centralized network services VPC in each region. Share a Route 53 Resolver forwarding rule for `.corp` pointing to the on-premises DNS servers across the AWS Organization using AWS Resource Access Manager (RAM) and associate it with all VPCs. Associate the `aws.internal` PHZ with all VPCs in both regions, and configure on-premises DNS to forward queries for `aws.internal` to the Inbound Endpoint IP addresses.

Answer

The correct network design utilizes regional AWS Transit Gateways peered together, with outbound internet traffic directed via a static route for

0.0.0.0/0

to a local Transit VPC in each region. DNS resolution uses Route 53 Resolver Inbound and Outbound Endpoints in a centralized VPC, with the `.corp` forwarding rule shared via AWS Resource Access Manager to all VPCs, and the `aws.internal` Private Hosted Zone associated directly with all VPCs.

The correct architecture uses regional AWS Transit Gateways peered together to scale connectivity to

60

spoke VPCs. Internet egress is centralized locally within each region using a Transit VPC and a static route for

0.0.0.0/0

in the Transit Gateway route table. For DNS, Route 53 Resolver Outbound Endpoints allow forwarding queries for `.corp` to on-premises DNS, and sharing the forwarding rules via AWS Resource Access Manager reduces administrative overhead. Associating the Private Hosted Zone with all VPCs and deploying Inbound Endpoints allows on-premises clients to resolve `aws.internal` names.

Step-by-Step Solution

Evaluate scalability limits for connecting

60

spoke VPCs to the on-premises network.

Determine that VPC Peering is unmanageable at scale and Direct Connect Gateway has a limit of

10

Virtual Private Gateway associations. Regional AWS Transit Gateways peered across regions are required.

To support transitive routing and scale connectivity across multiple accounts and regions without hitting service limits.

Design the egress routing paths for outbound internet traffic.

Create a Transit VPC in each region containing security appliances, attach it to the local Transit Gateway, and configure a static route for

0.0.0.0/0

in the spoke VPC Transit Gateway route table pointing to the Transit VPC attachment.

To centralize and inspect all egress traffic locally in each region, minimizing inter-region data transfer costs.

Architect the DNS resolution path for resolving on-premises domains from AWS.

Create Route 53 Resolver Outbound Endpoints in a shared network services VPC. Configure a forwarding rule for `.corp` pointing to on-premises DNS servers, share the rule via AWS Resource Access Manager, and associate it with all

60

spoke VPCs.

To enable outbound DNS queries from all spoke VPCs to on-premises while minimizing the cost and management of duplicate endpoints.

Architect the DNS resolution path for resolving AWS Private Hosted Zones from on-premises.

Create Route 53 Resolver Inbound Endpoints in the shared network services VPC. Associate the `aws.internal` Private Hosted Zone with all VPCs in both regions, and configure on-premises DNS to forward queries for `aws.internal` to the Inbound Endpoint IPs.

To ensure that on-premises clients can resolve AWS resources in the Private Hosted Zone, and that the hosted zone is associated with all VPCs that require resolution.

Key Concept

Multi-region hybrid network design using peered Transit Gateways with centralized internet egress and Route 53 Resolver architecture.

Question 1755Question →

A company is designing a federated identity solution for its developers who authenticate via an external SAML 2.0 compliant Identity Provider (IdP). The developers require single sign-on (SSO) access to multiple member accounts within their AWS Organizations environment. The solution must support automated user provisioning, minimize administrative overhead, and avoid manual creation of IAM users in each account. Which configuration strategy should the solutions architect recommend to meet these requirements?

Configure AWS IAM Identity Center in the management account, integrated with the external SAML 2.0 IdP. Enable System for Cross-domain Identity Management (SCIM) in IAM Identity Center and configure the IdP to synchronize users and groups. Create permission sets in IAM Identity Center and assign them to the synchronized groups for target member accounts.

Configure the SAML 2.0 Identity Provider (IdP) in a central security account. In each target member account, create an IAM role with a trust policy that permits the sts:AssumeRoleWithSAML action and references the ARN of the SAML provider in the centralized security account. Attach a Service Control Policy (SCP) to the organization root that allows the federated users to assume these target roles.

Create a SAML 2.0 Identity Provider (IdP) object in each target member account. In the external IdP, configure individual SAML client integrations for each member account. Create an IAM role in each member account with a trust policy that allows the sts:AssumeRole action for the SAML provider, and write a script to provision IAM users in each member account.

Configure AWS IAM Identity Center in the management account and integrate it with the external SAML 2.0 IdP. Enable SCIM to synchronize users and groups. Attach a Service Control Policy (SCP) to target Organizational Units (OUs) that maps the external IdP groups to their allowed actions, thereby granting permissions without creating local roles or permission sets in the member accounts.

Show answer & explanation

Answer: Configure AWS IAM Identity Center in the management account, integrated with the external SAML 2.0 IdP. Enable System for Cross-domain Identity Management (SCIM) in IAM Identity Center and configure the IdP to synchronize users and groups. Create permission sets in IAM Identity Center and assign them to the synchronized groups for target member accounts.

Answer

Configure AWS IAM Identity Center in the management account, integrate it with the external SAML 2.0 IdP, enable System for Cross-domain Identity Management (SCIM), and assign permission sets to the synchronized groups for target member accounts.

The correct configuration uses AWS IAM Identity Center integrated with the external IdP via SAML 2.0 and SCIM. This enables centralized identity management, automates provisioning, and uses permission sets to govern cross-account access, which minimizes administrative overhead.

Step-by-Step Solution

Integrate the identity provider centrally

AWS IAM Identity Center is integrated with the external SAML 2.0 IdP in the management account (or delegated administrator account), enabling single sign-on across the organization.

Centralizing the configuration prevents the administrative burden of creating individual SAML providers in every member account.

Configure automatic user provisioning

Enable SCIM in AWS IAM Identity Center to synchronize user identities and group memberships from the external IdP.

This eliminates the need for manual provisioning or custom synchronization scripts.

Assign permissions to groups in target accounts

Create permission sets (which AWS automatically deploys as IAM roles in target accounts) and map them to the synchronized groups.

Mapping permission sets to groups ensures that when users change departments or roles in the IdP, their access to AWS resources is updated automatically.

Key Concept

AWS IAM Identity Center (formerly AWS SSO) provides a centralized way to manage single sign-on access to multiple AWS accounts and SAML 2.0 business applications. Integrating it with an external IdP via SAML 2.0 and enabling SCIM allows centralized administration, automatic user provisioning, and mapping of groups to permission sets without the overhead of per-account configuration.

Question 1756Question →

An organization is establishing federated identity access across its multi-account AWS environment using an on-premises PingFederate Identity Provider (IdP). The Solutions Architect needs to set up a configuration that allows external partners to authenticate via the IdP and assume a specific role called PartnerDeveloperRole in target AWS accounts. The configuration must support a maximum session duration of 12 hours for the federated sessions.

Which of the following actions must the Solutions Architect perform to successfully configure this federation? (Select TWO.)

Select all that apply

Create an Identity Provider (IdP) of type SAML in each target AWS account using the metadata document from PingFederate, and configure the PartnerDeveloperRole trust policy to allow the sts:AssumeRoleWithSAML action.

Set the Maximum Session Duration setting of the PartnerDeveloperRole in each target AWS account to 12 hours, and ensure the PingFederate IdP sends the https://aws.amazon.com/SAML/Attributes/SessionDuration attribute in the SAML assertion.

Configure the PartnerDeveloperRole trust policy in each target account to allow the sts:AssumeRole action for the PingFederate SAML provider ARN as the principal.

Attach a Service Control Policy (SCP) at the root level of AWS Organizations that allows sts:AssumeRoleWithSAML and automatically provisions the PartnerDeveloperRole in all target AWS accounts.

Show answer & explanation

Answer: Create an Identity Provider (IdP) of type SAML in each target AWS account using the metadata document from PingFederate, and configure the PartnerDeveloperRole trust policy to allow the sts:AssumeRoleWithSAML action.; Set the Maximum Session Duration setting of the PartnerDeveloperRole in each target AWS account to 12 hours, and ensure the PingFederate IdP sends the https://aws.amazon.com/SAML/Attributes/SessionDuration attribute in the SAML assertion.

Answer

To establish SAML-based federation, you must create a SAML Identity Provider in each target account, allow the sts:AssumeRoleWithSAML action in the role's trust policy, configure the role's Maximum Session Duration to 12 hours, and pass the SessionDuration attribute in the SAML assertion from PingFederate.

To successfully set up SAML federation, a SAML identity provider must exist in each AWS target account, and the target role's trust policy must allow the sts:AssumeRoleWithSAML action. To override the default 1-hour session duration limit up to 12 hours, both the Maximum Session Duration parameter on the IAM role must be updated, and the SessionDuration attribute must be supplied within the SAML assertion from PingFederate.

Step-by-Step Solution

Configure SAML Providers and Trust Policies

SAML IdP entities are registered in each target AWS account, and the PartnerDeveloperRole trust policy is set to allow sts:AssumeRoleWithSAML from these provider principals.

AWS STS requires sts:AssumeRoleWithSAML to exchange SAML tokens for temporary credentials.

Increase Maximum Session Duration

The Maximum Session Duration on the PartnerDeveloperRole in all target AWS accounts is configured to 12 hours.

The default session duration is 1 hour; this must be explicitly increased to support the 12-hour requirement.

Configure SAML Attributes in PingFederate

PingFederate is configured to release the SessionDuration attribute, Role, and RoleSessionName attributes in the SAML assertion.

AWS requires these attributes to map the federated user to the correct IAM role and determine the session duration.

Key Concept

Establishing multi-account SAML federation and session management

Question 1757Question →

A solutions architect is establishing a governed multi-account environment for an enterprise using AWS Control Tower. The architect needs to initialize the landing zone, enforce corporate compliance guardrails, and onboard the first set of application team accounts. Arrange the steps to design and implement this multi-account governance structure in the correct chronological sequence.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence starts with configuring the AWS Organizations management account, followed by deploying the AWS Control Tower Landing Zone to establish the Security OU and core accounts. Next, preventative guardrails must be applied to the target OUs. Then, operational member accounts can be provisioned via Account Factory. Finally, the Customizations for AWS Control Tower pipeline is triggered to bootstrap resources inside the enrolled accounts.

Establishing a secure multi-account environment requires building from the foundational organization structure up to the account level. The correct path starts with designating the management account and setting up AWS Organizations. Next, the AWS Control Tower Landing Zone is deployed to establish core security OUs and shared accounts (Log Archive and Audit). Guardrails and SCPs are then applied to OUs to ensure governance boundaries are active. Only after the OUs are secured are operational member accounts provisioned using Account Factory, followed by CfCT pipelines to deploy application-specific resources and configurations within those accounts.

Step-by-Step Solution

Set up the management account.

An AWS Organization is initialized with a designated management account.

AWS Control Tower orchestration requires a management account to launch the landing zone.

Deploy the Landing Zone.

Security OUs, Log Archive, and Audit accounts are provisioned and integrated.

This establishes the core administrative and security baseline of the landing zone.

Enable Service Control Policies (SCPs) on OUs.

The target OUs are configured with mandatory compliance restrictions.

Applying guardrails at the OU level first ensures that any account created under or moved to these OUs is instantly compliant.

Use AWS Control Tower Account Factory to provision member accounts.

New member accounts are created, registered with Control Tower, and placed under the governed OUs.

Member accounts should be created using the standardized Account Factory after the target OUs and guardrails are already defined.

Apply post-provisioning customizations via CfCT.

Resources such as IAM roles, KMS keys, and local VPC configurations are deployed to the new member accounts.

Customizations are applied to bootstrap accounts after they are successfully created and registered.

Key Concept

AWS Control Tower Landing Zone Setup and Account Lifecycle Management

Question 1758Question →

A global logistics enterprise is designing a new cloud-native supply chain tracking and routing platform. The platform handles an OLTP workload consisting of real-time package status transitions and route assignments. The system must support up to $80,000 \text{ reads/sec}$ and $15,000 \text{ writes/sec}$ during peak hours, with database read latency kept below $15 \text{ ms}$ . The disaster recovery requirements specify a Recovery Time Objective (RTO) of less than $10 \text{ minutes}$ and a Recovery Point Objective (RPO) of less than $1 \text{ minute}$ . Additionally, an analytics dashboard operating in a separate, dedicated AWS account must be able to securely read data from the database with minimal performance impact on the primary OLTP application. All data must be encrypted at rest. Which database and storage strategy meets these requirements with the lowest operational complexity?

Deploy an Amazon Aurora PostgreSQL Global Database with the primary cluster in the main Region and a secondary cluster in the recovery Region. Encrypt the global database using the default AWS-managed KMS key (aws/rds). Modify the default AWS-managed KMS key policy to grant decrypt permissions to the cross-account analytics role so it can query the secondary database.

Deploy an Amazon Aurora PostgreSQL Global Database with the primary cluster in the main Region and a secondary cluster in the recovery Region. Configure Aurora Auto Scaling for the Aurora Replicas in both regions to handle peak read traffic. Encrypt the database clusters using an AWS KMS customer managed key in each Region, and grant cross-account KMS decrypt and Aurora DB cluster read permissions to the dedicated analytics account.

Deploy a multi-Region Amazon RDS for PostgreSQL database with a Multi-AZ configuration in both the primary and recovery Regions. Scale read capacity to

80,000 \text{ reads/sec}

by directing the analytics dashboard and read queries to the Multi-AZ standby instances in each region. Encrypt the databases using customer managed KMS keys.

Deploy a single-Region Amazon Aurora PostgreSQL DB cluster. Configure hourly automated database snapshots and copy them to the recovery Region. Grant the analytics account access to read from the primary DB cluster via a cross-account IAM role. In the event of a regional outage, restore the database from the copied snapshots in the recovery Region.

Show answer & explanation

Answer: Deploy an Amazon Aurora PostgreSQL Global Database with the primary cluster in the main Region and a secondary cluster in the recovery Region. Configure Aurora Auto Scaling for the Aurora Replicas in both regions to handle peak read traffic. Encrypt the database clusters using an AWS KMS customer managed key in each Region, and grant cross-account KMS decrypt and Aurora DB cluster read permissions to the dedicated analytics account.

Answer

Deploy an Amazon Aurora PostgreSQL Global Database encrypted with a customer managed KMS key, utilizing Aurora Auto Scaling for read scaling, and granting cross-account permissions on the key and database resources.

The correct architecture uses Amazon Aurora Global Database to replicate write operations globally with sub-second latency, resolving the RPO requirements. Aurora Replicas handle read scaling to support high-throughput analytics, while Customer Managed Keys (CMKs) enable cross-account access delegation which is impossible using AWS-managed keys.

Step-by-Step Solution

Evaluate the database replication and disaster recovery requirement.

Amazon Aurora Global Database provides sub-second data replication lag, easily satisfying the RPO limit of 1 minute. Regional failover can be completed in less than 1 minute, matching the RTO limit of 10 minutes.

Choosing the correct disaster recovery architecture is required to satisfy strict SLA/RTO/RPO limits.

Address read scaling for peak OLTP traffic (

80,000 \text{ reads/sec}

Configure Aurora Auto Scaling to dynamically spin up Aurora Replicas to handle the read workload in the primary and secondary clusters.

Aurora Replicas handle read operations without affecting the write performance of the primary instance.

Configure encryption and cross-account access for the analytics dashboard.

Use customer managed KMS keys rather than AWS-managed keys to enable modifying the key policy for cross-account access.

AWS-managed keys cannot be shared with external AWS accounts, which is a hard constraint for the analytics workload.

Key Concept

Amazon Aurora Global Database architecture combined with customer managed KMS encryption keys for cross-account access and high performance global read scaling.

Question 1759Question →

A financial services company is planning to migrate $200$ VMware-based virtual machines (VMs) containing transactional databases and application servers from its on-premises data center to a VMware Cloud on AWS (VMC) SDDC. The migration has strict requirements: a near-zero recovery time objective (RTO), zero data loss during cutover, and the preservation of existing IP addresses due to hardcoded application configurations. The hybrid network architecture is managed across multiple AWS accounts: a central AWS Transit Gateway (TGW) in a Shared Services account is connected to on-premises via an AWS Direct Connect (DX) Gateway with a Transit VIF, and multiple application VPCs are attached to this central TGW. The VMC SDDC is connected via VMware Cloud on AWS Transit Connect (VTGW), which is peered with the central TGW. During initial configuration, replication traffic between the on-premises VMware HCX instance and the HCX Cloud destination in the VMC SDDC fails to establish connectivity. Which configuration change must the solutions architect implement to resolve the connectivity issues and enable zero-downtime migrations over the Direct Connect link?

Associate the existing Direct Connect Gateway directly with the VMware Cloud on AWS Transit Connect (VTGW) by accepting an association proposal in the AWS account. Configure HCX to use this direct path for replication, and deploy HCX Replication-Assisted vMotion (RAV) to migrate the VMs while extending the L2 network to preserve IP addresses.

Configure static routing on the central Transit Gateway to route traffic destined for the VMC SDDC CIDR block to the Transit Connect (VTGW) attachment, and advertise the on-premises IP ranges from the Direct Connect Gateway to the VTGW. Configure VMware HCX to route replication traffic through the central Transit Gateway peered connection.

Create a new AWS Direct Connect Private VIF on the same connection, associate it with a new virtual private gateway (VGW) in the VMC management VPC, and configure a Route 53 Private Hosted Zone associated with both the VMC VPC and the Shared Services VPC. Perform the migration using VMware HCX Bulk Migration to ensure zero data loss.

Deploy AWS Application Migration Service (MGN) replication agents on all on-premises VMs. Route the replication traffic over the peered Transit Connect link by configuring Transit Gateway Connect attachments to run BGP over GRE tunnels between the VMC SDDC and the central Transit Gateway.

Show answer & explanation

Answer: Associate the existing Direct Connect Gateway directly with the VMware Cloud on AWS Transit Connect (VTGW) by accepting an association proposal in the AWS account. Configure HCX to use this direct path for replication, and deploy HCX Replication-Assisted vMotion (RAV) to migrate the VMs while extending the L2 network to preserve IP addresses.

Answer

The correct option addresses the transit routing limitation by directly associating the Direct Connect Gateway with the VMware Transit Connect (VTGW). This allows routing traffic directly from the on-premises routers to the VMC SDDC over the Direct Connect Transit VIF. Furthermore, VMware HCX Replication-Assisted vMotion (RAV) ensures zero data loss and near-zero downtime by combining bulk background replication with a hot vMotion-based switchover, while the HCX L2 Network Extension preserves VM IP addresses.

Step-by-Step Solution

Analyze routing paths in Transit Gateway peered architectures.

Identify that AWS Transit Gateway peered connections are non-transitive for Direct Connect Gateway (DXGW) traffic.

Traffic from on-premises via DXGW cannot traverse the Central TGW over a peered connection to reach the VMware Transit Connect (VTGW).

Establish direct routing between on-premises and VMware Cloud on AWS.

Associate the DXGW directly with the VMware Transit Connect (VTGW).

Direct association allows direct BGP prefix exchange between on-premises routers and the SDDC via the DX connection.

Select the correct VMware migration mechanism to meet recovery objectives.

Choose VMware HCX Replication-Assisted vMotion (RAV).

RAV combines bulk parallel replication with a zero-downtime live vMotion switchover, satisfying the near-zero RTO and zero data loss requirements.

Select the technology to preserve VM IP configurations.

Utilize HCX L2 Network Extension.

Extending the L2 network allows VMs to run on VMC with their original on-premises IP addresses without requiring immediate IP changes.

Key Concept

Direct Connect Gateway association with VMware Cloud on AWS Transit Connect to bypass non-transitive routing limitations of Transit Gateway peering.

Estimated Time:3m 0s

Question 1760Question →

A financial services organization is modernizing its payment processing pipeline. The pipeline receives high-volume transaction notifications from an external payment gateway through Amazon API Gateway and routes them to AWS Lambda functions. The Lambda functions process the transactions and update a highly utilized Amazon RDS PostgreSQL database located in a private subnet. The processed transactions must also be archived to an Amazon S3 bucket in a separate, central security audit AWS account for long-term retention.

The architecture must satisfy the following constraints:
1. Prevent sudden transaction bursts from exhausting the concurrency limits of other critical workloads in the AWS account.
2. Avoid overwhelming the RDS PostgreSQL database connection pool.
3. Ensure high availability for the egress network path from the Lambda functions to external verification endpoints.
4. Encrypt the archived S3 objects and allow the central security audit account to decrypt them.
5. Provide a safe deployment mechanism for new Lambda function versions with automated rollback capabilities.

Which TWO strategies should the Solutions Architect implement to meet these requirements? (Select TWO.)

Select all that apply

Provision an Amazon RDS Proxy between the Lambda functions and the database, and configure a reserved concurrency limit on the transaction-processing Lambda function.

Deploy the Lambda functions in private subnets across multiple Availability Zones with a NAT Gateway in each Availability Zone, use AWS CodeDeploy with a canary deployment configuration for Lambda function updates, and encrypt S3 archives using a Customer Managed KMS Key with a policy that allows the security audit account to decrypt the data.

Deploy the Lambda functions in private subnets across multiple Availability Zones pointing to a single NAT Gateway in a single Availability Zone, and encrypt the archived objects using the default AWS-managed S3 KMS key (aws/s3).

Deploy the Lambda functions without reserved concurrency to allow maximum scalability during peak transaction bursts, and use a rolling deployment configuration (AllAtOnce) to update the Lambda functions as quickly as possible.

Provision an Amazon RDS Proxy between the Lambda functions and the database, and encrypt the archived objects using an AWS-managed KMS key while configuring a Service Control Policy (SCP) to grant cross-account access to the security audit account.

Show answer & explanation

Answer: Provision an Amazon RDS Proxy between the Lambda functions and the database, and configure a reserved concurrency limit on the transaction-processing Lambda function.; Deploy the Lambda functions in private subnets across multiple Availability Zones with a NAT Gateway in each Availability Zone, use AWS CodeDeploy with a canary deployment configuration for Lambda function updates, and encrypt S3 archives using a Customer Managed KMS Key with a policy that allows the security audit account to decrypt the data.

Answer

Implementing RDS Proxy and reserved concurrency, along with deploying redundant NAT Gateways, canary deployments via CodeDeploy, and a Customer Managed KMS Key for S3 encryption.

Implementing Amazon RDS Proxy manages database connections efficiently and prevents overloading the RDS instance. Configuring a reserved concurrency limit on the transaction-processing Lambda function protects other critical applications in the account from throttling during high-volume bursts. Redundant NAT Gateways across Availability Zones eliminate a single point of failure for outbound traffic. AWS CodeDeploy allows for safe, automated canary deployments with rollback mechanisms. Finally, encrypting S3 objects with a Customer Managed KMS Key enables cross-account decrypt permissions via key policies, which is not supported by AWS-managed KMS keys.

Step-by-Step Solution

Address connection pooling and concurrency scaling safety.

Amazon RDS Proxy is added to pool database connections, and a reserved concurrency limit is configured on the transaction-processing Lambda function.

RDS Proxy prevents database crash from exhaustion of connections under peak loads. Reserved concurrency protects the wider account from API bursts that would exhaust the regional pool.

Ensure egress network redundancy.

Deploy the Lambda functions in private subnets pointing to separate NAT Gateways in each Availability Zone.

A single NAT Gateway creates a single point of failure; multi-AZ NAT Gateways ensure high availability during AZ outages.

Configure cross-account S3 encryption keys.

Use a Customer Managed Key in AWS KMS, updating its key policy to grant decrypt permission to the central security audit account's role.

AWS-managed KMS keys (like aws/s3) cannot be shared with external AWS accounts.

Establish a safe release mechanism.

Utilize AWS CodeDeploy with a canary deployment configuration (e.g., Canary10Percent5Minutes) linked to CloudWatch Alarms.

This allows progressive traffic shifting and automated rollback if errors occur during updates, achieving zero downtime.

Key Concept

Modernizing legacy workloads using serverless architectures (Lambda and API Gateway) requires a multi-layered design integrating secure cross-account KMS access, highly available network topology, database connection pooling, account-level concurrency protections, and automated deployment strategies.

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