All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A company is designing a deployment pipeline for a serverless API that uses Amazon API Gateway and AWS Lambda. The new deployment strategy must meet the following requirements:
- Shifting traffic to the new Lambda version must be done gradually, routing $10\%$ of the traffic for a $15$ -minute verification period before routing the remaining $90\%$ of the traffic.
- A health-check suite must execute testing against the new Lambda version before any production traffic is routed to it.
- The deployment must automatically roll back if the Lambda function's error rate spikes or if the health-check suite fails.

Which combination of actions must the solutions architect take to implement this deployment strategy? (Select TWO.)

Select all that apply

Configure the AWS CodeDeploy deployment group to use the CodeDeployDefault.LambdaCanary10Percent15Minutes deployment configuration, and define a BeforeAllowTraffic lifecycle hook in the AppSpec file that points to a validation Lambda function.

Create a CloudWatch alarm that monitors the Errors metric of the Lambda function, and configure the CodeDeploy deployment group to automatically roll back when this alarm is triggered.

Configure the AWS CodeDeploy deployment group to use the CodeDeployDefault.LambdaLinear10PercentEvery15Minutes deployment configuration, and define an AfterAllowTraffic lifecycle hook in the AppSpec file to execute the health-check suite.

Create an AWS Lambda alias pointing to both the active and the new Lambda versions with a

10\%

routing weight, and configure a Route 53 weighted alias record to shift traffic after

15

minutes.

Create a CloudWatch alarm that monitors API Gateway IntegrationLatency and associate it with a CloudFormation stack rollback trigger to automatically revert the Lambda function version alias.

Show answer & explanation

Answer: Configure the AWS CodeDeploy deployment group to use the CodeDeployDefault.LambdaCanary10Percent15Minutes deployment configuration, and define a BeforeAllowTraffic lifecycle hook in the AppSpec file that points to a validation Lambda function.; Create a CloudWatch alarm that monitors the Errors metric of the Lambda function, and configure the CodeDeploy deployment group to automatically roll back when this alarm is triggered.

Answer

Configure the AWS CodeDeploy deployment group to use the canary deployment configuration with a BeforeAllowTraffic lifecycle hook, and configure a CloudWatch alarm on the Lambda Errors metric to trigger an automatic rollback.

To implement the gradual traffic shifting strategy, the canary deployment configuration routes

10\%

of traffic to the new Lambda version for

15

minutes, then shifts the remaining

90\%

of traffic instantly. The BeforeAllowTraffic hook runs before any production traffic is shifted to the new Lambda function version, making it the correct lifecycle phase to execute the health-check suite. To support automated rollbacks based on failures, CodeDeploy natively supports CloudWatch alarms. If the CloudWatch alarm monitoring the Lambda Errors metric triggers during the deployment, CodeDeploy immediately halts the deployment and rolls back the alias to the previous stable version.

Step-by-Step Solution

Select the CodeDeploy deployment configuration that routes

10\%

of the traffic for

15

minutes and then routes

90\%

immediately.

CodeDeployDefault.LambdaCanary10Percent15Minutes is selected.

This matches the traffic shifting requirements exactly.

Configure the validation hook in the AppSpec file to execute the health-check suite before traffic shifting starts.

BeforeAllowTraffic hook is defined, pointing to a test-execution Lambda function.

BeforeAllowTraffic runs validation scripts before production traffic is routed to the new Lambda version.

Configure CloudWatch Alarms to monitor Lambda Errors and link them to the CodeDeploy deployment group rollback options.

CodeDeploy automatically rolls back the deployment if the alarm transitions to the ALARM state during deployment.

This satisfies the requirements for automated rollback on function failure.

Key Concept

Canary deployment strategy with CodeDeploy lifecycle validation hooks and CloudWatch rollback alarms for serverless workloads

Question 1842Question →

An enterprise is migrating a stateful database application from an on-premises VMware vSphere cluster to a newly deployed VMware Cloud on AWS Software-Defined Data Center (SDDC). The application database is highly active and has a strict requirement of less than 10 minutes of cumulative downtime during the migration cutover window. The migration will occur over a dedicated 1 Gbps AWS Direct Connect connection. To prevent application disruption, the database virtual machines (VMs) must retain their existing on-premises IP addresses after migration.

Which of the following actions should the Solutions Architect take to meet these migration and network requirements? (Select TWO.)

Select all that apply

Configure VMware HCX Replication-Assisted vMotion (RAV) to replicate the database virtual machines to the target SDDC and perform a live switchover.

Establish a VMware HCX Layer 2 Network Extension to stretch the on-premises database subnet to the VMware Cloud on AWS SDDC.

Use VMware HCX Cold Migration to transfer the database virtual machines to the target SDDC datastore.

Attach the AWS Direct Connect Gateway directly to both the VMware Cloud on AWS SDDC and multiple customer-managed VPCs to enable transitive routing between the migrated VMs and other application tiers.

Create a Route 53 Private Hosted Zone in a shared services VPC for internal DNS resolution, assuming the SDDC's management VPC will automatically resolve these records without explicit hosted zone association.

Show answer & explanation

Answer: Configure VMware HCX Replication-Assisted vMotion (RAV) to replicate the database virtual machines to the target SDDC and perform a live switchover.; Establish a VMware HCX Layer 2 Network Extension to stretch the on-premises database subnet to the VMware Cloud on AWS SDDC.

Answer

Configure VMware HCX Replication-Assisted vMotion (RAV) to replicate the database virtual machines to the target SDDC and perform a live switchover, and establish a VMware HCX Layer 2 Network Extension to stretch the on-premises database subnet to the VMware Cloud on AWS SDDC.

The correct actions are configuring VMware HCX Replication-Assisted vMotion (RAV) and establishing an HCX Layer 2 Network Extension. HCX RAV allows live migration with near-zero downtime by combining bulk replication with vMotion switchover, meeting the 10-minute downtime limit. The L2 Network Extension enables IP retention by stretching the subnet across on-premises and AWS, preventing application reconfiguration.

Step-by-Step Solution

Analyze the migration downtime constraint.

Since the downtime constraint is less than 10 minutes, standard Cold Migration or Bulk Migration (which reboot the VM) are insufficient. A live migration method like HCX Replication-Assisted vMotion (RAV) is required.

HCX RAV replicates data in the background and uses vMotion for the final cutover, achieving near-zero downtime.

Determine the IP preservation requirement.

Identify that the database VMs must retain their IP addresses to prevent application reconfiguration.

Configuring a VMware HCX L2 Network Extension stretches the broadcast domain, allowing migrated VMs to run in the cloud with their original IP addresses.

Evaluate network and DNS connectivity constraints.

Verify that transitive routing is not supported directly through a Direct Connect Gateway and that Private Hosted Zones require explicit association.

Correctly identifying these architectural limits eliminates invalid network and DNS configurations.

Key Concept

Selecting the appropriate VMware HCX migration method and network extension strategy to satisfy strict downtime and IP retention constraints.

Alternative Method

As an alternative, if live migration is not supported due to vSphere version mismatches, HCX Bulk Migration can be scheduled, but it requires a VM reboot which might exceed the downtime limit depending on the operating system and database startup times. Thus, RAV remains the primary choice.

Estimated Time:2m 0s

Question 1843Question →

An enterprise with $120$ member accounts under a single organization in AWS Organizations is designing a centralized logging solution. The security team wants to aggregate application logs from Amazon CloudWatch Logs across all member accounts into a central Amazon Kinesis Data Firehose delivery stream in a dedicated Log Archive account. The logs must be delivered to an Amazon S3 bucket in the Log Archive account and encrypted at rest using a Customer Managed Key (CMK) in AWS KMS. The solution must minimize administrative overhead and enforce the principle of least privilege. Which of the following actions should the solutions architect perform to meet these requirements? (Select TWO.)

Select all that apply

In the Log Archive account, create a CloudWatch Logs destination pointing to the Kinesis Data Firehose delivery stream. Attach a destination policy to the destination that grants the logs:PutSubscriptionFilter permission to the wildcard principal * with a condition restricting access to the AWS Organization's ID (aws:PrincipalOrgID).

In the Log Archive account, create an IAM role that trusts the logs.amazonaws.com service principal, with a condition restricting the source account to the Log Archive account. Grant this role permissions to put records into the Kinesis Data Firehose delivery stream.

Configure the Kinesis Data Firehose delivery stream to write directly to the S3 bucket, and configure the S3 bucket policy in the Log Archive account to grant s3:PutObject permissions to the IAM roles of the

120

member accounts.

Configure the Kinesis Data Firehose delivery stream to use the default AWS-managed key for Amazon S3 (aws/s3) for encryption at rest, and modify the key policy of aws/s3 to allow Kinesis Data Firehose cross-account decryption permissions.

Attach a Service Control Policy (SCP) to the organization's root OU that grants the logs:PutSubscriptionFilter permission to all member accounts, which automatically authorizes them to stream logs to the Log Archive account without requiring local IAM permissions.

Show answer & explanation

Answer: In the Log Archive account, create a CloudWatch Logs destination pointing to the Kinesis Data Firehose delivery stream. Attach a destination policy to the destination that grants the logs:PutSubscriptionFilter permission to the wildcard principal * with a condition restricting access to the AWS Organization's ID (aws:PrincipalOrgID).; In the Log Archive account, create an IAM role that trusts the logs.amazonaws.com service principal, with a condition restricting the source account to the Log Archive account. Grant this role permissions to put records into the Kinesis Data Firehose delivery stream.

Answer

In the Log Archive account, create a CloudWatch Logs destination pointing to Kinesis Data Firehose with a destination policy that grants logs:PutSubscriptionFilter to the organization ID, and create an IAM role that trusts the logs.amazonaws.com service principal with a condition restricting the source account to the Log Archive account to put records into the Kinesis Data Firehose delivery stream.

The correct solution involves creating a CloudWatch Logs destination in the Log Archive account, which acts as the centralized log receiver. The destination policy must grant logs:PutSubscriptionFilter permissions to the member accounts, which is best achieved by specifying a wildcard principal and filtering by the organization's ID using the aws:PrincipalOrgID condition. Additionally, CloudWatch Logs needs permission to put logs into the Kinesis Data Firehose stream, which requires an IAM role in the Log Archive account that trusts the logs.amazonaws.com service principal and restricts it using the aws:SourceAccount condition to prevent cross-account confused deputy exploits.

Step-by-Step Solution

Create an IAM role in the Log Archive account that CloudWatch Logs can assume to write events to Kinesis Data Firehose.

An IAM role is created with a trust policy allowing logs.amazonaws.com to assume it, restricted by the aws:SourceAccount condition.

This establishes the secure trust boundary allowing the CloudWatch Logs service to write logs to Kinesis Data Firehose on behalf of the subscriber.

Create a CloudWatch Logs destination in the Log Archive account referencing the Kinesis Data Firehose stream and the IAM role.

The destination is registered in the Log Archive account.

This destination acts as the centralized endpoint that member accounts' subscription filters will target.

Apply a destination policy to the CloudWatch Logs destination to allow subscription filters from member accounts.

The policy allows logs:PutSubscriptionFilter for principal '*' under the condition that the caller is within the AWS Organization (aws:PrincipalOrgID).

This authorizes member accounts in the organization to create cross-account subscription filters without manually managing individual account numbers in the policy.

Key Concept

Cross-account CloudWatch Logs subscription filters using a centralized destination and destination policy.

Question 1844Question →

A company is modernizing a legacy, highly transactional mainframe service by migrating it to a serverless architecture on AWS. The modernized application will receive public API calls via Amazon API Gateway and invoke backend logic on AWS Lambda. The Lambda functions must query and update an Amazon Aurora PostgreSQL database that is hosted in a private subnet within a VPC. The database contains highly sensitive data, and credentials must be rotated automatically without code modifications or environment variables. The API must only accept requests containing a valid custom cryptographic signature header, which must be verified against public verification keys stored in a centralized security account. During peak traffic bursts, the Lambda functions must not exhaust the regional concurrency limits of the AWS account or overwhelm the database with connections. Which combination of actions should a Solutions Architect take to design a secure, performant, and resilient architecture? (Select TWO.)

Select all that apply

Configure an Amazon API Gateway Lambda authorizer to verify the cryptographic signature. Configure the authorizer to retrieve the verification key from AWS Secrets Manager in the Security account using a Customer Managed Key (CMK) with cross-account IAM role permissions, caching the authorization result in API Gateway. Establish an Amazon RDS Proxy in the private subnets across multiple Availability Zones, and configure the backend Lambda function to connect to the database via the proxy using IAM database authentication.

Enable a Reserved Concurrency limit on the backend Lambda function that corresponds to the maximum database connections allowed by the RDS Proxy. Configure the Lambda function's VPC settings to deploy in multiple subnets across all available Availability Zones, ensuring the subnets are routed via multiple NAT Gateways in each Availability Zone for any external API outbound calls.

To manage database connection limits, rely on the backend Lambda function's local initialization container memory to persist connections across invocations. Configure the database credentials to be retrieved directly from AWS Secrets Manager using the default AWS-managed KMS key (aws/secretsmanager) in the Security account to decrypt the credentials during each Lambda invocation.

Configure an API Gateway Lambda authorizer to verify the cryptographic signature. Deploy the backend Lambda function and RDS Proxy within a single private subnet in a single Availability Zone to ensure minimal network latency. Route all outbound internet traffic from this subnet through a single NAT Gateway located in the public subnet of the same Availability Zone.

To handle connection management during traffic bursts, configure API Gateway with a standard regional endpoint and route traffic to the backend Lambda function with unconstrained concurrency. Let the Lambda function scale dynamically to its maximum concurrency limits to maximize throughput, and enable Aurora Auto Scaling to dynamically add reader replicas to absorb the increased write and update queries on the database.

Show answer & explanation

Answer: Configure an Amazon API Gateway Lambda authorizer to verify the cryptographic signature. Configure the authorizer to retrieve the verification key from AWS Secrets Manager in the Security account using a Customer Managed Key (CMK) with cross-account IAM role permissions, caching the authorization result in API Gateway. Establish an Amazon RDS Proxy in the private subnets across multiple Availability Zones, and configure the backend Lambda function to connect to the database via the proxy using IAM database authentication.; Enable a Reserved Concurrency limit on the backend Lambda function that corresponds to the maximum database connections allowed by the RDS Proxy. Configure the Lambda function's VPC settings to deploy in multiple subnets across all available Availability Zones, ensuring the subnets are routed via multiple NAT Gateways in each Availability Zone for any external API outbound calls.

Answer

The correct actions are: 1) Configure an Amazon API Gateway Lambda authorizer that retrieves verification keys from AWS Secrets Manager in the Security account using a Customer Managed Key (CMK) and cross-account IAM permissions, and establish an Amazon RDS Proxy with IAM database authentication. 2) Enable a Reserved Concurrency limit on the backend Lambda function and deploy the function in multiple subnets across all Availability Zones routed through redundant NAT Gateways.

The correct architecture leverages an API Gateway Lambda authorizer that retrieves verification keys from a centralized Security account. This requires using a Customer Managed Key (CMK) because AWS-managed keys cannot have their key policies modified to allow cross-account decrypt operations. By caching the authorization result in API Gateway, cross-account calls are minimized. For database connectivity and security, using Amazon RDS Proxy with IAM database authentication ensures connection pooling and eliminates the need to manage database passwords or rotate credentials within the Lambda function. Additionally, setting a Reserved Concurrency limit on the Lambda function prevents it from overwhelming the RDS Proxy and database while protecting the regional unreserved concurrency pool from exhaustion. Deploying the Lambda function across multiple Availability Zones with redundant NAT Gateways ensures high availability and eliminates single points of failure for outbound traffic.

Step-by-Step Solution

Analyze the cross-account encryption and access control requirements for the cryptographic verification key store.

Determine that a Customer Managed Key (CMK) must be used in the Security account's key policy to allow cross-account decryption, as AWS-managed keys cannot be shared across accounts.

AWS-managed KMS keys do not support policy modifications to grant access to other accounts.

Analyze database connection management, credentials storage, and security.

Identify that Amazon RDS Proxy should be deployed in a multi-AZ private VPC configuration with IAM database authentication enabled for Lambda.

RDS Proxy manages connection pooling, and IAM auth removes the administrative overhead of password rotation and storage in Lambda code.

Evaluate the impact of high-volume burst traffic on Lambda concurrency and database capacity.

Define a Reserved Concurrency limit on the backend Lambda function to match database/proxy capacity limits.

Reserved Concurrency prevents the function from scaling past the database connection capacity and protects the regional account-wide concurrency pool from starvation.

Assess the high availability and resiliency design of the network and compute resources.

Configure the Lambda function to deploy in multiple subnets across different Availability Zones, and route internet-bound traffic through separate NAT Gateways in each Availability Zone.

Ensures no single point of failure exists in the outbound networking or compute path, matching AWS reliability best practices.

Key Concept

Modernizing transactional workloads with serverless architecture using API Gateway, Lambda, RDS Proxy, and cross-account KMS/Secrets Manager integrations.

Question 1845Question →

An enterprise is migrating 150 VMware-based workloads from an on-premises data center to VMware Cloud (VMC) on AWS. The destination architecture requires deploying these workloads across two separate Software-Defined Data Centers (SDDCs), SDDC 1 and SDDC 2, located in different AWS accounts for resource isolation. The migration and network architecture must meet the following technical requirements:

- Workloads must be migrated with zero application downtime to satisfy a strict recovery time objective (RTO) of zero.
- Workloads in SDDC 1 must communicate directly with workloads in SDDC 2 over the private network.
- Both SDDCs must connect back to the on-premises data center using an existing $10\text{ Gbps}$ AWS Direct Connect connection.
- All migrated workloads must resolve private domain names hosted in a central Route 53 Private Hosted Zone (PHZ) in a shared services VPC.

Which combination of migration method, network connectivity, and DNS configuration meets these requirements with the lowest operational complexity?

Use VMware HCX Replication-Assisted vMotion (RAV) for the migrations. Attach SDDC 1, SDDC 2, and the shared services VPC to a VMware Cloud Transit Connect (VTGW), and associate the VTGW with the Direct Connect Gateway. Associate the central Route 53 PHZ with the connected VPCs of both SDDCs, and configure the SDDC Compute Gateway (CGW) DNS to forward queries to the AmazonProvidedDNS IP address of their respective connected VPCs.

Use VMware HCX Bulk Migration for the migrations. Connect both SDDCs and the shared services VPC directly to a Direct Connect Gateway using private virtual interfaces (VIFs) to establish hybrid and inter-SDDC routing. Associate the central Route 53 PHZ with the shared services VPC, and configure the SDDC Compute Gateway (CGW) DNS to forward queries to the shared services VPC DNS resolver.

Use VMware HCX Replication-Assisted vMotion (RAV) for the migrations. Attach SDDC 1, SDDC 2, and the shared services VPC to a VMware Cloud Transit Connect (VTGW), and associate the VTGW with the Direct Connect Gateway. Configure the SDDC Compute Gateway (CGW) DNS to forward queries directly to the AmazonProvidedDNS IP address of their respective connected VPCs, without creating any cross-account associations for the central Route 53 PHZ.

Use VMware HCX Cold Migration for the migrations. Establish an IPsec VPN mesh between the on-premises environment and both SDDCs over a Direct Connect public virtual interface (VIF) to enable routing. Associate the central Route 53 PHZ with the connected VPCs, and configure a Route 53 Resolver Inbound Endpoint in each connected VPC to handle DNS queries from the SDDCs.

Show answer & explanation

Answer: Use VMware HCX Replication-Assisted vMotion (RAV) for the migrations. Attach SDDC 1, SDDC 2, and the shared services VPC to a VMware Cloud Transit Connect (VTGW), and associate the VTGW with the Direct Connect Gateway. Associate the central Route 53 PHZ with the connected VPCs of both SDDCs, and configure the SDDC Compute Gateway (CGW) DNS to forward queries to the AmazonProvidedDNS IP address of their respective connected VPCs.

Answer

The correct option satisfies all constraints. VMware HCX Replication-Assisted vMotion (RAV) allows zero-downtime, bulk hot migrations of VMs. VMware Cloud Transit Connect (VTGW) provides high-bandwidth, transitive routing between SDDCs and VPCs, and connects to the Direct Connect Gateway for hybrid pathing. Associating the Route 53 Private Hosted Zone (PHZ) with the connected VPCs ensures that queries forwarded to the AmazonProvidedDNS IP address resolve the private records correctly.

Step-by-Step Solution

Determine the migration method that guarantees zero downtime.

Identify VMware HCX Replication-Assisted vMotion (RAV) as the correct choice since it combines the parallel operations of Bulk Migration with the zero-downtime hot-migration properties of HCX vMotion. Reject Bulk Migration (requires a reboot) and Cold Migration (requires VM power-off).

Satisfies the strict RTO of zero.

Design the hybrid and inter-SDDC routing architecture.

Use VMware Cloud Transit Connect (VTGW) to interconnect SDDC 1 and SDDC 2, and connect the VTGW to the Direct Connect Gateway (DXGW) for the on-premises connection.

Direct Connect Gateway alone does not support transitive routing (SDDC-to-SDDC or VPC-to-VPC), making Transit Connect necessary to allow direct communication between the two SDDCs and the on-premises data center over the same Direct Connect connection.

Establish the private DNS resolution flow.

Associate the Route 53 Private Hosted Zone (PHZ) in the shared services account with the connected VPCs of SDDC 1 and SDDC 2, and point the SDDC CGW DNS to the AmazonProvidedDNS IP address (base + 2) of their respective connected VPCs.

Allows VMs inside the SDDCs to query the connected VPC resolver, which can only resolve names in the PHZ if it is associated with that VPC.

Key Concept

VMware Cloud on AWS hybrid migration planning and routing topology using HCX RAV, VMware Cloud Transit Connect, and cross-account Route 53 PHZ associations.

Question 1846Question →

A financial data processing firm runs its core transaction settlement application on Amazon EC2 instances in an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The instances reside in private subnets across three Availability Zones (AZ-a, AZ-b, and AZ-c) in a VPC. Outbound traffic to external financial clearinghouses is routed through a single NAT Gateway located in AZ-a. During a recent physical fiber cut that impacted AZ-a, instances in AZ-b and AZ-c lost all outbound connectivity, halting transaction settlements.

Additionally, the application experiences brief, massive bursts of transactions at the start of each business hour. Each EC2 instance requires approximately $8$ minutes to boot, retrieve encryption keys, and complete application initialization. During the hourly bursts, the ALB throws $503$ Service Unavailable errors for several minutes because the ASG's step scaling policy, which has a $300$ -second cooldown, cannot add healthy instances fast enough.

Which two actions should a solutions architect take to resolve these issues and improve the fault tolerance of the application? (Select TWO.)

Select all that apply

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

Configure an Auto Scaling group warm pool with instances in the Stopped state to maintain pre-initialized EC2 instances, and configure the scaling policy to launch instances from the warm pool during scale-out events.

Configure the Application Load Balancer to route outbound API requests directly through an AWS Transit Gateway that is peered with a central egress VPC containing redundant NAT Gateways.

Reduce the Auto Scaling group cooldown period to

120

seconds to allow the step scaling policy to trigger additional scale-out actions more rapidly during the hourly transaction spikes.

Submit a request to AWS Support to pre-warm the Application Load Balancer to ensure it has sufficient capacity to handle the sudden burst of incoming connections at the start of each hour.

Show answer & explanation

Answer: Deploy a NAT Gateway in each Availability Zone, and update the route tables of the private subnets in each Availability Zone to route outbound traffic through the NAT Gateway in their respective Availability Zone.; Configure an Auto Scaling group warm pool with instances in the Stopped state to maintain pre-initialized EC2 instances, and configure the scaling policy to launch instances from the warm pool during scale-out events.

Answer

Deploy a NAT Gateway in each Availability Zone and configure the route tables of the private subnets to route outbound traffic through their local NAT Gateway. In addition, configure an Auto Scaling group warm pool with instances in the Stopped state to maintain pre-initialized EC2 instances.

The correct solution involves deploying a NAT Gateway in each Availability Zone and configuring the private subnets to route outbound traffic through their respective local gateways to eliminate the single point of failure. Additionally, establishing an Auto Scaling group warm pool with pre-initialized instances in the Stopped state addresses the

8

-minute bootstrapping delay, enabling the system to scale out within seconds when the hourly burst of transactions begins.

Step-by-Step Solution

Address the outbound connectivity single point of failure by deploying redundant NAT Gateways.

A NAT Gateway is deployed in the public subnet of each Availability Zone (AZ-a, AZ-b, and AZ-c).

This ensures that an outage in one AZ (such as AZ-a) only affects the resources in that specific AZ. Outbound traffic from the remaining AZs continues to flow through their respective local NAT Gateways, eliminating cross-AZ dependencies for internet access.

Configure local routing for private subnets to route outbound traffic through the corresponding local NAT Gateway.

Route tables for private subnets in AZ-b and AZ-c are updated to route internet-bound traffic to their local NAT Gateways.

This establishes fault-tolerant, high-availability outbound paths for all private instances across the three Availability Zones.

Solve the

8

-minute instance initialization delay during sudden traffic spikes using an ASG warm pool.

An ASG warm pool is enabled with instances kept in a Stopped state.

Warm pools allow instances to boot, run their initialization scripts, download keys, and then stop. When the hourly transaction spike occurs, these pre-initialized instances can be started within seconds rather than minutes, allowing the ASG to scale out rapidly and prevent Application Load Balancer

503

errors.

Key Concept

Implementing Multi-AZ redundancy for outbound gateways and reducing EC2 scale-out provisioning latency using ASG warm pools.

Question 1847Question →

A logistics corporation is consolidating its IT operations across multiple acquired subsidiaries by deploying a multi-account landing zone using AWS Organizations. The security team is setting up direct SAML 2.0-based identity federation to target accounts, bypassing AWS IAM Identity Center due to custom legacy attribute mapping requirements from an on-premises Shibboleth Identity Provider (IdP). During pilot testing, users receive access denied errors immediately after selecting their role on the AWS federation portal. Analysis reveals that the federated roles are configured with session tags for Attribute-Based Access Control (ABAC), but the tags are not being evaluated, and user sessions are expiring too quickly for long-running database maintenance tasks.

Which of the following configuration steps must the solutions architect perform to successfully resolve these federation and session lifecycle issues? (Select TWO.)

Select all that apply

In the target IAM roles, update the trust policy to allow both 'sts:AssumeRoleWithSAML' and 'sts:TagSession' actions for the federated SAML provider principal, and configure the Shibboleth IdP to release SAML attributes mapped to the 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:' namespace.

Increase the 'Maximum CLI/API session duration' setting on the target IAM roles up to 12 hours, and configure the Shibboleth IdP to include the 'https://aws.amazon.com/SAML/Attributes/SessionDuration' attribute in the SAML assertion.

Attach a Service Control Policy (SCP) at the root of the AWS Organization that explicitly allows the 'sts:AssumeRoleWithSAML' and 'sts:TagSession' actions, ensuring the policy overrides local IAM role trust policy limitations.

Update the target IAM roles' trust policies to trust the AWS Organizations management account root principal, and delegate the SAML provider configuration and 'sts:AssumeRoleWithSAML' actions entirely to the centralized identity account.

Show answer & explanation

Answer: In the target IAM roles, update the trust policy to allow both 'sts:AssumeRoleWithSAML' and 'sts:TagSession' actions for the federated SAML provider principal, and configure the Shibboleth IdP to release SAML attributes mapped to the 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:' namespace.; Increase the 'Maximum CLI/API session duration' setting on the target IAM roles up to 12 hours, and configure the Shibboleth IdP to include the 'https://aws.amazon.com/SAML/Attributes/SessionDuration' attribute in the SAML assertion.

Answer

To resolve the issues, the trust policies of the target IAM roles must be updated to permit both the 'sts:AssumeRoleWithSAML' and 'sts:TagSession' actions, and the Shibboleth Identity Provider must be configured to map attributes to the 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:' namespace. Additionally, to resolve the session expiration issue, the solutions architect must increase the maximum session duration setting on the target IAM roles and configure the Identity Provider to send the 'https://aws.amazon.com/SAML/Attributes/SessionDuration' attribute in the SAML assertion.

The correct configurations involve setting up the IAM role trust policy to permit both role assumption and session tagging. For ABAC, the trust policy must explicitly allow the 'sts:TagSession' action alongside 'sts:AssumeRoleWithSAML'. The IdP must also be configured to pass the tags under the correct 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:' prefix. To handle long-running tasks, the 'SessionDuration' attribute must be passed by the IdP in the SAML assertion, and the target IAM role's maximum session duration setting must be increased accordingly, as the default session duration for federated access is 1 hour.

Step-by-Step Solution

Enable session tagging on the federated roles by modifying their trust policies.

The target IAM roles will accept principal tags passed from the identity provider when the 'sts:TagSession' action is explicitly permitted alongside 'sts:AssumeRoleWithSAML'.

Without 'sts:TagSession' in the trust policy, attempts to pass session tags during federation will fail with an access denied error.

Configure attribute mappings in the Shibboleth IdP to release principal tags.

Attributes will be passed in the SAML assertion with the prefix 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:'.

AWS requires this specific namespace to automatically convert SAML attributes into session tags available for ABAC evaluation.

Adjust maximum session duration settings in both AWS IAM and the Shibboleth IdP.

The target roles' 'Maximum CLI/API session duration' is increased, and the IdP is set to send the 'https://aws.amazon.com/SAML/Attributes/SessionDuration' attribute.

By default, federated sessions expire in 1 hour. Increasing the duration requires both the role to allow a longer limit and the IdP assertion to request it.

Key Concept

Direct SAML 2.0 federation trust policies, principal tagging for ABAC, and session duration attributes in AWS multi-account landing zones.

Question 1848Question →

A financial services firm is designing a new real-time fraud detection and transaction ledger system that spans two AWS regions under different AWS accounts. The system must support an OLTP write ingest rate of $50{}000$ transactions per second. The real-time fraud detection engine requires sub-millisecond read latency. The system must meet a Disaster Recovery (DR) objective of a Recovery Time Objective ( $\text{RTO}$ ) of less than $10$ minutes and a Recovery Point Objective ( $\text{RPO}$ ) of less than $1$ minute. Transaction logs must be archived in a centralized security account for $7$ years, where cross-account auditing roles require access to decrypt the data. Which two configurations should the solutions architect choose to meet these requirements?

Select all that apply

Configure Amazon DynamoDB global tables across both regions with DynamoDB Accelerator (DAX) to ingest transactions and serve the fraud checking engine with sub-millisecond latency.

Enable DynamoDB Streams to trigger an AWS Lambda function that archives transaction logs to an Amazon S3 bucket in the centralized account, encrypting the data with a Customer Managed Key (CMK) configured with a cross-account key policy.

Deploy Amazon RDS for PostgreSQL in a Multi-AZ deployment, and configure the fraud checking engine to query the passive standby instance in the secondary Availability Zone to achieve read scaling.

Schedule an AWS Backup rule to perform automated database snapshots every 6 hours and copy them to the disaster recovery region, utilizing this snapshot replication to achieve the target RPO.

Encrypt the database and target S3 buckets using AWS-managed KMS keys, modifying the default key policies to grant the cross-account auditing role permission to decrypt the data.

Show answer & explanation

Answer: Configure Amazon DynamoDB global tables across both regions with DynamoDB Accelerator (DAX) to ingest transactions and serve the fraud checking engine with sub-millisecond latency.; Enable DynamoDB Streams to trigger an AWS Lambda function that archives transaction logs to an Amazon S3 bucket in the centralized account, encrypting the data with a Customer Managed Key (CMK) configured with a cross-account key policy.

Answer

The correct configurations are to use Amazon DynamoDB global tables with DynamoDB Accelerator (DAX) for transactional ingest and real-time reads, and to use DynamoDB Streams with AWS Lambda to archive transaction logs to Amazon S3 using a Customer Managed Key (CMK) with a cross-account key policy.

Utilizing Amazon DynamoDB global tables with DynamoDB Accelerator (DAX) provides the required multi-region replication for RTO/RPO objectives and sub-millisecond read caching. Leveraging DynamoDB Streams with AWS Lambda to archive to Amazon S3 using a Customer Managed Key (CMK) permits cross-account decryption permissions through policy modification.

Step-by-Step Solution

Analyze the read latency and throughput needs for fraud detection.

Using DynamoDB global tables with DAX satisfies the

50{}000

transactions per second write throughput and provides sub-millisecond read latency.

Standard database reads or RDS Multi-AZ deployments cannot guarantee sub-millisecond latency under high write contention without memory-based caching.

Evaluate the RTO and RPO requirements against the database replication strategy.

DynamoDB global tables offer active-active replication with an RPO of less than 1 second, fully satisfying the requirement of an RPO of less than 1 minute and RTO of less than 10 minutes.

Periodic snapshot-based backups are unable to meet near-zero data loss requirements.

Assess the encryption and access policy configuration for cross-account log access.

Deploy S3 storage integrated with a Customer Managed Key (CMK) configured to allow cross-account decrypt operations.

AWS-managed KMS keys are restricted and cannot be shared cross-account or customized with custom trust policies.

Key Concept

Designing cross-account storage and database replication strategies while satisfying strict recovery point objectives (RPO), read latency requirements, and key management permissions.

Estimated Time:3m 0s

Question 1849Question →

A logistics company utilizes AWS Organizations to manage a multi-account environment. The identity team has configured SAML 2.0 federation with an external Identity Provider (IdP) to allow engineers to access resources in a shared development account. During testing, users are successfully redirected from the IdP dashboard to the AWS sign-in portal, but they encounter an access denied error before they can select their role. The trust policy of the target IAM role in the development account is configured with the SAML provider as the Federated principal, the Action set to `sts:AssumeRole`, and the condition `SAML:aud` set to `https://signin.aws.amazon.com/saml`.

Which modification must the Solutions Architect make to the target IAM role's trust policy to resolve this issue?

Modify the Action in the trust policy to `sts:AssumeRoleWithWebIdentity` to support federated authentication.

Change the Federated principal in the trust policy to point to the AWS STS service endpoint instead of the SAML provider ARN.

Change the Action in the trust policy from `sts:AssumeRole` to `sts:AssumeRoleWithSAML`.

Ensure that a Service Control Policy (SCP) is attached to the development account's Organizational Unit (OU) that explicitly grants the `sts:AssumeRole` permission to the federated users.

Show answer & explanation

Answer: Change the Action in the trust policy from `sts:AssumeRole` to `sts:AssumeRoleWithSAML`.

Answer

Change the Action in the trust policy from `sts:AssumeRole` to `sts:AssumeRoleWithSAML`.

SAML 2.0 identity federation requires the trust policy of the target IAM role to specify the `sts:AssumeRoleWithSAML` action. When the Identity Provider redirects the user, the browser calls the AWS STS service using this action. Using `sts:AssumeRole` fails because it is meant for cross-account IAM role assumption or local service assumption, not federated authentication.

Step-by-Step Solution

Analyze the configuration of the SAML provider trust policy in the target AWS account.

Identify that the Action is currently set to `sts:AssumeRole`.

SAML 2.0 federation requires the specific AWS STS API call `sts:AssumeRoleWithSAML` to exchange the SAML assertion for credentials.

Update the Action element within the trust policy statement.

The Action matches the required `sts:AssumeRoleWithSAML` endpoint.

This allows the STS service to evaluate the SAML assertion and authenticate the user.

Validate the principal and condition keys.

The principal correctly points to the SAML provider ARN and the condition evaluates the correct audience.

Ensures the trust relationship is secure and points to the correct local SAML configuration.

Key Concept

IAM SAML Trust Policies and STS Actions

Question 1850Question →

Helios Energy Services is modernizing an on-premises containerized telemetry application by migrating it to Amazon EKS on AWS Fargate. The application must run in a secure VPC within private subnets that have no direct route to the internet. The EKS pods must pull container images from an Amazon ECR repository located in a separate shared services AWS account. The container images in ECR are encrypted using a Customer Managed Key (CMK) in AWS KMS. Additionally, the application pods must be exposed to external clients through an Application Load Balancer (ALB) managed by the AWS Load Balancer Controller. Which TWO configurations are required to establish the network routing, image retrieval, and load balancing for this architecture? (Select TWO.)

Select all that apply

Configure the AWS Load Balancer Controller to target the pods using target type `ip` within the Kubernetes Service or TargetGroupBinding configuration.

Configure the Application Load Balancer to route traffic to the EKS Fargate worker nodes using target type `instance` to allow node-level port mapping.

Attach an IAM policy to the EKS Fargate Pod Execution Role that allows `kms:Decrypt` and `kms:DescribeKey` actions on the Customer Managed Key, and update the key policy in the shared services account to trust the Pod Execution Role.

Create Route 53 Private Hosted Zones for the ECR interface VPC endpoints in the shared services account VPC, without associating them with the EKS VPC, and rely on Kubernetes CoreDNS for cross-account host resolution.

Deploy a single NAT Gateway in one Availability Zone within the EKS VPC and update the route tables of all private subnets across all Availability Zones to route outbound internet traffic through this NAT Gateway.

Show answer & explanation

Answer: Configure the AWS Load Balancer Controller to target the pods using target type `ip` within the Kubernetes Service or TargetGroupBinding configuration.; Attach an IAM policy to the EKS Fargate Pod Execution Role that allows `kms:Decrypt` and `kms:DescribeKey` actions on the Customer Managed Key, and update the key policy in the shared services account to trust the Pod Execution Role.

Answer

The correct configurations are to configure the AWS Load Balancer Controller to target pods using target type 'ip' in the Kubernetes Service or TargetGroupBinding configuration, and to attach an IAM policy to the EKS Fargate Pod Execution Role allowing decryption using the Customer Managed Key while updating the key policy to trust this role.

Because EKS Fargate pods run in the awsvpc network mode with their own ENIs, the AWS Load Balancer Controller must target them directly using target type 'ip'. Additionally, the EKS Fargate Pod Execution Role (not the Kubernetes Service Account) is used by the Fargate infrastructure to pull images from ECR. If the ECR repository is encrypted with a Customer Managed Key, this execution role must have explicit decrypt permissions on the key, and the key policy must trust the role.

Step-by-Step Solution

Analyze EKS Fargate networking requirements for load balancing.

Since pods run in awsvpc mode on Fargate, they receive unique IP addresses inside the VPC. The AWS Load Balancer Controller must target pods using target type 'ip'.

Targeting by instance ID is invalid since there are no accessible EC2 instances managed by the user.

Determine the IAM role responsible for image pulling on EKS Fargate and configure KMS permissions.

The Fargate infrastructure uses the EKS Fargate Pod Execution Role to pull images from ECR. The execution role must be granted 'kms:Decrypt' and 'kms:DescribeKey' permissions on the Customer Managed Key, and the key policy must trust this role.

Without these permissions, the Fargate agent cannot pull the encrypted container images from ECR, leading to pod launch failures.

Key Concept

EKS Fargate requires target type 'ip' for ALB integration because pods are allocated dedicated ENIs. Image decryption during container startup is handled by the Pod Execution Role, which requires explicit KMS and ECR permissions.

Question 1851Question →

An enterprise is designing a hybrid network connectivity and DNS resolution solution for its multi-account AWS environment. The environment consists of 12 spoke VPCs in the us-east-1 Region, each containing workloads that need to communicate with an on-premises datacenter.

The network design must meet the following requirements:
- The primary connection to the datacenter must use a 10 Gbps AWS Direct Connect connection.
- A backup connection must be established using an AWS Site-to-Site VPN over the internet.
- Failover from the Direct Connect connection to the VPN connection must happen automatically.
- On-premises servers must be able to resolve domain names for resources hosted in a Route 53 Private Hosted Zone (PHZ) associated with the AWS VPCs.
- Administrative overhead for routing and DNS configuration must be minimized.

Which of the following architectures meets these requirements?

Attach the spoke VPCs to an AWS Transit Gateway. Create a Direct Connect Gateway, and connect it to the datacenter using a Private Virtual Interface (Private VIF). Associate the Direct Connect Gateway with the Transit Gateway. Establish a Site-to-Site VPN connection and attach it to the Transit Gateway. Configure BGP routing to manage path preference. Create a Route 53 Resolver inbound endpoint in a shared services VPC, associate the PHZ with all spoke VPCs, and configure the on-premises DNS servers to forward queries to the inbound endpoint.

Attach the spoke VPCs to an AWS Transit Gateway. Create a Direct Connect Gateway, and connect it to the datacenter using a Transit Virtual Interface (Transit VIF). Associate the Direct Connect Gateway with the Transit Gateway. Establish a Site-to-Site VPN connection and attach it to the Transit Gateway. Configure BGP routing to manage path preference. Create a Route 53 Resolver inbound endpoint in a shared services VPC, associate the PHZ only with the shared services VPC, and configure the on-premises DNS servers to forward queries to the inbound endpoint.

Attach the spoke VPCs to an AWS Transit Gateway. Create a Direct Connect Gateway, and connect it to the datacenter using a Transit Virtual Interface (Transit VIF). Associate the Direct Connect Gateway with the Transit Gateway. Establish a Site-to-Site VPN connection and attach it to the Transit Gateway. Configure Border Gateway Protocol (BGP) to advertise the VPC CIDRs and manage path preference. Create a Route 53 Resolver inbound endpoint in a shared services VPC, associate the PHZ with the shared services VPC and all spoke VPCs, and configure the on-premises DNS servers to forward queries to the inbound endpoint.

Attach the spoke VPCs to an AWS Transit Gateway. Create a Direct Connect Gateway, and connect it to the datacenter using a Transit Virtual Interface (Transit VIF). Associate the Direct Connect Gateway with the Transit Gateway. Establish a Site-to-Site VPN connection and attach it to the Transit Gateway. Route all internet-bound traffic from the spoke VPCs through a single NAT Gateway located in a single Availability Zone in a shared services VPC to minimize costs. Create a Route 53 Resolver inbound endpoint in the shared services VPC, associate the PHZ with all VPCs, and configure the on-premises DNS servers to forward queries to the inbound endpoint.

Show answer & explanation

Answer: Attach the spoke VPCs to an AWS Transit Gateway. Create a Direct Connect Gateway, and connect it to the datacenter using a Transit Virtual Interface (Transit VIF). Associate the Direct Connect Gateway with the Transit Gateway. Establish a Site-to-Site VPN connection and attach it to the Transit Gateway. Configure Border Gateway Protocol (BGP) to advertise the VPC CIDRs and manage path preference. Create a Route 53 Resolver inbound endpoint in a shared services VPC, associate the PHZ with the shared services VPC and all spoke VPCs, and configure the on-premises DNS servers to forward queries to the inbound endpoint.

Answer

Attach the spoke VPCs to an AWS Transit Gateway. Create a Direct Connect Gateway, and connect it to the datacenter using a Transit Virtual Interface (Transit VIF). Associate the Direct Connect Gateway with the Transit Gateway. Establish a Site-to-Site VPN connection and attach it to the Transit Gateway. Configure Border Gateway Protocol (BGP) to advertise the VPC CIDRs and manage path preference. Create a Route 53 Resolver inbound endpoint in a shared services VPC, associate the PHZ with the shared services VPC and all spoke VPCs, and configure the on-premises DNS servers to forward queries to the inbound endpoint.

The correct architecture uses AWS Transit Gateway to scale connectivity across 12 spoke VPCs, exceeding the 10 VPC limit of Direct Connect Gateway direct associations. It utilizes a Transit Virtual Interface (Transit VIF) which is required for connecting Direct Connect to a Transit Gateway via a Direct Connect Gateway. Dynamic BGP routing naturally supports failover between Direct Connect and Site-to-Site VPN. For DNS resolution, a centralized Route 53 Resolver inbound endpoint is established in a shared services VPC. The Private Hosted Zone (PHZ) is associated with both the shared services VPC (allowing the inbound endpoint to resolve it) and all spoke VPCs (allowing resources in those VPCs to resolve the private domains), minimizing DNS overhead.

Step-by-Step Solution

Deploy AWS Transit Gateway and attach the 12 spoke VPCs.

Provides a centralized hub-and-spoke transit network that allows communication between the VPCs and on-premises, minimizing administrative overhead.

AWS Transit Gateway simplifies multi-account networking and scales beyond the limit of 10 direct VPC associations allowed by a Direct Connect Gateway.

Establish hybrid connectivity using a Transit VIF with AWS Direct Connect and a Site-to-Site VPN.

Creates a high-speed primary network path via Direct Connect and an encrypted backup path via VPN, both terminating at the Transit Gateway.

Transit VIF is mandatory for connecting a Direct Connect Gateway to a Transit Gateway, while VPN provides cost-effective failover capacity.

Configure dynamic BGP routing on the Transit Gateway and on-premises router.

Automates failover by advertising the same prefixes over both paths, with the Direct Connect path preferred over the VPN path.

BGP dynamic routing ensures automatic path failover and routing symmetry between AWS and the on-premises datacenter.

Establish Route 53 Resolver inbound endpoints and associate the Private Hosted Zone (PHZ) with all VPCs.

Allows on-premises DNS servers to forward queries to the inbound endpoint IPs, while ensuring resources in all spoke VPCs can also resolve private domain names.

Route 53 Resolver inbound endpoints bridge on-premises and AWS DNS resolution, and the PHZ must be associated with any VPC requiring resolution of its domain names.

Key Concept

Hybrid and Multi-Account Network Connectivity Design

Alternative Method

Instead of using a Transit Gateway for VPN, you could establish a VPN connection directly to each VPC's Virtual Private Gateway (VGW), but this would significantly increase administrative overhead and scale poorly compared to a centralized Transit Gateway solution.

Estimated Time:3m 0s

Question 1852Question →

A manufacturing company is migrating its legacy shop-floor execution system consisting of four physical servers from an on-premises factory network to AWS. The migration team has established a hybrid network path using an AWS Direct Connect connection terminated at an AWS Transit Gateway. They have successfully installed the AWS Application Migration Service (MGN) replication agent on the source servers. However, the migration console shows that data replication is stalled and the agents cannot establish communication with the replication servers in the staging area VPC. Which of the following actions should the solutions architect take to resolve this replication communication issue?

Allow inbound traffic on TCP port 1500 in the staging area security group, and ensure the on-premises firewalls permit outbound traffic over TCP port 1500 to the staging area subnet.

Allow inbound traffic on TCP port 443 in the staging area security group, and configure a public NAT Gateway in the staging area subnet to route replication traffic.

Reconfigure the Direct Connect connection to bypass the Transit Gateway by attaching a Direct Connect gateway directly to the staging area VPC, as Transit Gateway routing does not support transitive replication traffic.

Create a Route 53 Private Hosted Zone for the replication service endpoint and associate it with the staging area VPC and the on-premises DNS resolvers.

Show answer & explanation

Answer: Allow inbound traffic on TCP port 1500 in the staging area security group, and ensure the on-premises firewalls permit outbound traffic over TCP port 1500 to the staging area subnet.

Answer

Allow inbound traffic on TCP port 1500 in the staging area security group, and ensure the on-premises firewalls permit outbound traffic over TCP port 1500 to the staging area subnet.

The correct option correctly identifies that AWS MGN relies on TCP port 1500 for sending replication data from the agent on the source server to the replication servers in the staging area VPC. Ensuring both the on-premises firewall allows outbound traffic and the staging area security group allows inbound traffic on TCP port 1500 resolves the replication timeout.

Step-by-Step Solution

Analyze the replication architecture of AWS MGN.

Identify that the control plane uses HTTPS (TCP port 443) to communicate with the MGN service APIs, while the actual replication stream uses TCP port 1500 to send data directly to the replication servers (EC2 instances) launched in the staging area VPC.

This helps distinguish between control plane access and data plane replication paths.

Evaluate the current failure symptom in the scenario.

Since the agent installation was successful, control plane connectivity (TCP port 443) is working. The issue lies within the data plane stream between the on-premises source servers and the staging area replication servers.

Correctly identifying the stalled data replication point points directly to TCP port 1500.

Configure the network security rules.

Permit outbound TCP 1500 from the on-premises firewall and inbound TCP 1500 in the security group associated with the replication servers in the AWS staging area.

This establishes the necessary connection path for block-level replication traffic.

Key Concept

AWS Application Migration Service (MGN) network port requirements for data replication

Question 1853Question →

A maritime shipping enterprise is modernizing its legacy vessel telemetry tracking system to a serverless architecture. The legacy system currently processes bursty ingestion traffic from global cargo ships and writes updates to an Amazon Aurora PostgreSQL DB cluster hosted in a private subnet of a central Virtual Private Cloud (VPC). The new architecture must ingest telemetry data via Amazon API Gateway and process it using AWS Lambda before writing to the database.

The solution must meet the following requirements:
- Protect the Aurora PostgreSQL database from connection exhaustion during sudden traffic spikes of up to $15{}000$ concurrent writes.
- Ensure the Lambda functions can access the database securely and privately within the VPC without traversing the public internet.
- Allow only specific client VPCs within the company's AWS Organization to call the API Gateway privately.
- Implement a deployment strategy that gradually routes traffic to new Lambda function versions with automated rollbacks upon error detection.

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

Select all that apply

Deploy an Amazon RDS Proxy for the Aurora PostgreSQL DB cluster, configure the Lambda functions to connect to the database via the proxy, and set a reserved concurrency limit on the Lambda functions to align with the database connection pool.

Deploy an Amazon API Gateway private API associated with interface VPC endpoints in the central VPC, apply an API Gateway resource policy that grants access only to the interface VPC endpoint IDs of the client VPCs, and use AWS CodeDeploy with AWS CloudFormation to perform a canary deployment of the Lambda functions.

Configure provisioned concurrency on the Lambda functions to scale up to

15{}000

concurrent executions during spikes, and establish direct connections from the Lambda functions to the Aurora DB cluster to minimize latency.

Configure the Lambda functions with a rolling update deployment strategy in AWS CloudFormation, and deploy a single NAT Gateway in one Availability Zone to route outbound Lambda traffic to a regional public API Gateway endpoint.

Deploy a regional public API Gateway endpoint, configure cross-account IAM roles to allow the client VPCs to invoke the API, and encrypt the telemetry payload using the AWS-managed KMS key `aws/lambda` in the central account.

Show answer & explanation

Answer: Deploy an Amazon RDS Proxy for the Aurora PostgreSQL DB cluster, configure the Lambda functions to connect to the database via the proxy, and set a reserved concurrency limit on the Lambda functions to align with the database connection pool.; Deploy an Amazon API Gateway private API associated with interface VPC endpoints in the central VPC, apply an API Gateway resource policy that grants access only to the interface VPC endpoint IDs of the client VPCs, and use AWS CodeDeploy with AWS CloudFormation to perform a canary deployment of the Lambda functions.

Answer

Deploy an Amazon RDS Proxy for the Aurora DB cluster combined with Lambda reserved concurrency to protect the database from connection exhaustion, and implement an API Gateway private API with interface VPC endpoints and resource policies to secure access, while using AWS CodeDeploy for canary deployments.

The correct solution involves deploying Amazon RDS Proxy to pool database connections, preventing exhaustion during traffic spikes, and setting a reserved concurrency limit on the Lambda functions to protect the database cluster. Private API Gateway access is achieved using interface VPC endpoints combined with an API Gateway resource policy that filters by VPC endpoint ID, ensuring only the specified client VPCs have access. AWS CodeDeploy provides the canary deployment configuration necessary to route traffic gradually with automatic rollback capabilities.

Step-by-Step Solution

Address database connection exhaustion and scaling constraints.

Amazon RDS Proxy is positioned between Lambda and the Aurora DB cluster to reuse and pool connections, while Reserved Concurrency is configured on the Lambda functions to limit maximum concurrent executions and avoid overwhelming the database.

Lambda functions scale rapidly and can exhaust database connections; RDS Proxy mitigates this by pooling connections, and reserved concurrency provides a hard limit to protect database performance.

Configure private API Gateway access from client VPCs.

A private API Gateway endpoint is deployed. Interface VPC endpoints (PrivateLink) are configured, and a resource policy is attached to the API Gateway to restrict traffic only to requests originating from the specific client VPC endpoint IDs.

This keeps traffic completely off the public internet and isolates the endpoint to authorized VPCs within the organization.

Implement safe deployment and rollback mechanisms.

AWS CodeDeploy is integrated with the CloudFormation deployment of Lambda to execute a Canary or Linear deployment, dynamically routing a fraction of traffic to the new version and automatically rolling back if CloudWatch Alarms trigger.

This guarantees zero-downtime updates and maintains application availability in case of deployment errors.

Key Concept

Modernizing legacy workloads using serverless architectures with strict security, scaling, and deployment controls.

Estimated Time:2m 30s

Question 1854Question →

An enterprise is planning to migrate its on-premises data center to AWS. The migration involves two distinct datasets:

* A $1.2\text{ PB}$ dataset of historical logs stored on an on-premises Hadoop Distributed File System (HDFS). This data needs to be migrated to Amazon S3 Standard and then transitioned to Amazon S3 Glacier Flexible Retrieval after $30\text{ days}$ .
* A $120\text{ TB}$ dataset of active user documents stored on an on-premises SMB file share. This data must be migrated to an Amazon FSx for Windows File Server file system. The documents are actively modified, and the migration must minimize cutover downtime by replicating changes up to the final cutover window.

The enterprise has a dedicated $1\text{ Gbps}$ Direct Connect connection. A maximum of $300\text{ Mbps}$ can be dedicated to the migration to avoid disrupting production traffic. The migration must be completed within a strict $40\text{ day}$ window. Security policy mandates that all data must be encrypted at rest using customer-managed keys (CMKs) in AWS KMS, and the migration process must maintain files' metadata (such as permissions and timestamps).

Which combination of actions will meet these requirements? (Select TWO.)

Select all that apply

For the HDFS dataset, order multiple AWS Snowball Edge Storage Optimized devices. Configure the Snowball jobs to use a customer-managed KMS key (CMK) for encryption. Copy the HDFS data to the devices, ship them to AWS to import the data into an Amazon S3 Standard bucket, and configure an S3 Lifecycle policy on the bucket to transition the objects to Amazon S3 Glacier Flexible Retrieval after

30\text{ days}

For the SMB dataset, order AWS Snowball Edge Storage Optimized devices to seed the data. Copy the SMB files to the devices and import them into an intermediate Amazon S3 bucket. Deploy AWS DataSync agents on-premises, and configure a DataSync task to copy the seeded data from the S3 bucket to the FSx for Windows File Server file system. Configure a second DataSync task to sync incremental changes directly from the on-premises SMB share to the FSx for Windows File Server file system before cutover.

Deploy AWS DataSync agents on-premises, and configure a DataSync task to copy the HDFS dataset directly from the on-premises HDFS cluster to Amazon S3 Standard over the Direct Connect connection using a customer-managed KMS key (CMK). Configure a target S3 Lifecycle policy to transition the data to S3 Glacier Flexible Retrieval.

For the HDFS dataset, order multiple AWS Snowball Edge Storage Optimized devices. Configure the Snowball jobs to encrypt the data at rest using the default AWS-managed KMS key for Amazon S3 (aws/s3). Copy the HDFS data to the devices, ship them to AWS to import the data into an Amazon S3 Standard bucket, and configure an S3 Lifecycle policy to transition the objects to S3 Glacier Flexible Retrieval.

Deploy AWS DataSync agents on-premises to migrate the SMB dataset. Configure a Direct Connect Gateway connected directly to a Virtual Private Gateway (VGW) in a central hub VPC, and route replication traffic transitively through the hub VPC to FSx for Windows File Server file systems residing in multiple spoke VPCs without utilizing AWS Transit Gateway.

Show answer & explanation

Answer: For the HDFS dataset, order multiple AWS Snowball Edge Storage Optimized devices. Configure the Snowball jobs to use a customer-managed KMS key (CMK) for encryption. Copy the HDFS data to the devices, ship them to AWS to import the data into an Amazon S3 Standard bucket, and configure an S3 Lifecycle policy on the bucket to transition the objects to Amazon S3 Glacier Flexible Retrieval after $30\text{ days}$ .; For the SMB dataset, order AWS Snowball Edge Storage Optimized devices to seed the data. Copy the SMB files to the devices and import them into an intermediate Amazon S3 bucket. Deploy AWS DataSync agents on-premises, and configure a DataSync task to copy the seeded data from the S3 bucket to the FSx for Windows File Server file system. Configure a second DataSync task to sync incremental changes directly from the on-premises SMB share to the FSx for Windows File Server file system before cutover.

Answer

Ordering multiple AWS Snowball Edge Storage Optimized devices utilizing customer-managed KMS keys (CMKs) to migrate the HDFS data to Amazon S3 Standard with an S3 Lifecycle transition policy, combined with ordering AWS Snowball Edge devices to seed the SMB dataset to an intermediate Amazon S3 bucket, followed by using AWS DataSync to copy that seeded data to FSx for Windows File Server and sync subsequent incremental changes.

To migrate

1.2\text{ PB}

of data within a

40\text{ day}

window over a

300\text{ Mbps}

bandwidth limit, an offline migration using AWS Snowball Edge is required since an online transfer would take over a year. The Snowball jobs must use a Customer Managed Key (CMK) because default AWS-managed keys cannot be configured for Snowball Edge imports. An S3 Lifecycle policy will automate the transition to Glacier Flexible Retrieval. For the

120\text{ TB}

SMB dataset, an online transfer would take over

46\text{ days}

, exceeding the

40\text{ day}

limit. Seeding the initial dataset using Snowball Edge to an intermediate S3 bucket, using AWS DataSync to copy that seed to FSx for Windows File Server, and then running incremental DataSync tasks directly from the on-premises SMB share to FSx for Windows File Server enables a successful migration within the timeline.

Step-by-Step Solution

Calculate the transfer capabilities for the network path.

At a maximum allocated bandwidth of

300\text{ Mbps}

with a standard

80\%

network efficiency, the maximum transfer rate is approximately

2.59\text{ TB/day}

This calculation determines if either of the datasets can be transferred entirely online within the

40\text{ day}

window.

Evaluate the migration timeline for the

1.2\text{ PB}

HDFS dataset.

1.2\text{ PB}

dataset requires approximately

463\text{ days}

of continuous online transmission, which exceeds the

40\text{ day}

timeline. Therefore, the HDFS dataset must be migrated offline using multiple AWS Snowball Edge Storage Optimized devices.

This rules out online-only tools like AWS DataSync for the bulk HDFS migration.

Evaluate the migration timeline for the

120\text{ TB}

SMB dataset.

120\text{ TB}

dataset requires approximately

46.3\text{ days}

of online transmission, which also exceeds the

40\text{ day}

window. The initial

120\text{ TB}

must be seeded offline using Snowball Edge, after which a DataSync task can sync incremental updates directly over the network.

Seeding the bulk SMB dataset offline reduces the remaining online transfer volume to only daily deltas, which easily fit within the timeline.

Select the appropriate encryption and routing configurations.

The Snowball Edge jobs must use a Customer Managed Key (CMK) because default AWS-managed KMS keys like `aws/s3` are not supported. Transitive routing of replication traffic via a Direct Connect Gateway directly to a Virtual Private Gateway (VGW) is unsupported, meaning that AWS Transit Gateway is required for multi-VPC spoke routing.

This satisfies the security compliance (CMKs) and networking topology constraints.

Key Concept

Large-Scale Data Transfer using Snow Family, DataSync, and Transfer Family

Estimated Time:3m 0s

Question 1855Question →

A financial services company is designing a multi-account structure using AWS Organizations. The architecture consists of several Organizational Units (OUs), including a Security OU, a Workloads OU (which contains production and development accounts), and a Sandbox OU for developer experimentation. The Solutions Architect must implement the following governance requirements:

1. Prevent any development and production accounts in the Workloads OU from disabling AWS Config.
2. Ensure that accounts in the Sandbox OU cannot create virtual private cloud (VPC) peering connections or Transit Gateway attachments, preventing them from connecting to corporate networks.

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

Select all that apply

Create a Service Control Policy (SCP) that denies the config:DeleteConfigurationRecorder, config:DeleteDeliveryChannel, and config:StopConfigurationRecorder actions. Attach this SCP to the Workloads OU.

Create a Service Control Policy (SCP) that denies the ec2:CreateVpcPeeringConnection and ec2:CreateTransitGatewayAttachment actions. Attach this SCP to the Sandbox OU.

Create an IAM group in the management account with policies that deny AWS Config modifications and EC2 network attachments, and associate this group with the OUs.

Modify the Transit Gateway route tables in the shared services account to block all traffic originating from the Sandbox accounts, and delete all local route table entries in the member accounts.

Configure a SAML 2.0 identity provider (IdP) in the management account and map user groups to trust policies that explicitly deny network creation actions in the Sandbox accounts.

Show answer & explanation

Answer: Create a Service Control Policy (SCP) that denies the config:DeleteConfigurationRecorder, config:DeleteDeliveryChannel, and config:StopConfigurationRecorder actions. Attach this SCP to the Workloads OU.; Create a Service Control Policy (SCP) that denies the ec2:CreateVpcPeeringConnection and ec2:CreateTransitGatewayAttachment actions. Attach this SCP to the Sandbox OU.

Answer

Create a Service Control Policy (SCP) to deny AWS Config deletion/stop actions and attach it to the Workloads OU, and create a second SCP to deny VPC peering and Transit Gateway attachment creation and attach it to the Sandbox OU.

To enforce governance controls across multiple accounts within specific OUs, Service Control Policies (SCPs) are the primary mechanism. Attaching an SCP to the Workloads OU that denies AWS Config deletion/stop operations prevents administrators in those member accounts from turning off compliance auditing. Similarly, attaching an SCP to the Sandbox OU that denies the creation of VPC peering connections and Transit Gateway attachments prevents resource linkage at the API level, ensuring absolute network isolation of the sandbox environment.

Step-by-Step Solution

Define a Service Control Policy (SCP) to restrict AWS Config modifications.

An SCP is drafted with Deny statements for config:DeleteConfigurationRecorder, config:DeleteDeliveryChannel, and config:StopConfigurationRecorder.

To prevent local administrators in the Workloads OU from disabling compliance auditing.

Attach the AWS Config restriction SCP to the Workloads OU.

The SCP is linked to the Workloads OU, applying the restriction to all production and development accounts nested under it.

To enforce the configuration policy at the OU boundary.

Define an SCP to restrict VPC Peering and Transit Gateway attachment creation.

An SCP is drafted with Deny statements for ec2:CreateVpcPeeringConnection and ec2:CreateTransitGatewayAttachment.

To prevent sandbox environments from connecting to other network segments.

Attach the network restriction SCP to the Sandbox OU.

The SCP is linked to the Sandbox OU, restricting network creation capability for all sandbox accounts.

To ensure isolation requirements are strictly enforced.

Key Concept

Service Control Policies (SCPs) are security policies that you can use to manage permissions in your organization, offering central control over the maximum available permissions for all accounts in your organization or specific OUs.

Question 1856Question →

A media streaming company is implementing a federated authentication solution for its engineering team to access resources across multiple AWS accounts within an AWS organization. The company uses Okta as its external identity provider (IdP). To satisfy legacy integration requirements, the solutions architect must configure direct SAML 2.0 federation to target IAM roles in the member accounts, bypassing AWS IAM Identity Center. The engineers must be able to federate into a role named DeveloperDeploymentRole in the target member accounts. Which two configuration steps are required to establish this federated access?

Select all that apply

Configure a trust policy on the DeveloperDeploymentRole in the target accounts that lists the SAML provider as the federated principal and allows the sts:AssumeRoleWithSAML action.

Configure the SAML application in Okta to include a SAML attribute named https://aws.amazon.com/SAML/Attributes/Role that contains the comma-separated Amazon Resource Names (ARNs) of the target IAM role and the SAML provider.

Configure an IAM policy in the target accounts allowing the sts:AssumeRoleWithWebIdentity action and attach it to the developers' local IAM users.

Create a Service Control Policy (SCP) at the Root OU level that allows the sts:AssumeRoleWithSAML action for Okta users to grant access to the target member accounts.

Create a SAML identity provider in each target account and attach an IAM policy to the provider object that explicitly grants sts:AssumeRole permissions to Okta groups.

Show answer & explanation

Answer: Configure a trust policy on the DeveloperDeploymentRole in the target accounts that lists the SAML provider as the federated principal and allows the sts:AssumeRoleWithSAML action.; Configure the SAML application in Okta to include a SAML attribute named https://aws.amazon.com/SAML/Attributes/Role that contains the comma-separated Amazon Resource Names (ARNs) of the target IAM role and the SAML provider.

Answer

Configure a trust policy on the DeveloperDeploymentRole in the target accounts that lists the SAML provider as the federated principal and allows the sts:AssumeRoleWithSAML action, and configure the SAML application in Okta to include a SAML attribute named https://aws.amazon.com/SAML/Attributes/Role that contains the comma-separated Amazon Resource Names (ARNs) of the target IAM role and the SAML provider.

The correct configurations involve creating a trust relationship using the sts:AssumeRoleWithSAML action on the target role in the member accounts, referencing the SAML provider. Additionally, the IdP must send the specific role attribute containing the comma-separated role and provider ARNs to complete the authentication handshake.

Step-by-Step Solution

Set up the IAM trust policy on the target role.

The DeveloperDeploymentRole in the target member accounts is configured to trust the SAML identity provider ARN.

This is necessary so that AWS knows which external identity provider is authorized to assume the role via SAML.

Configure SAML assertion attributes in the Okta portal.

The Okta SAML assertion is configured to send the role and provider ARNs in the https://aws.amazon.com/SAML/Attributes/Role attribute.

This attribute is mandatory for AWS to successfully map the federating identity to the target role during the sts:AssumeRoleWithSAML operation.

Key Concept

Direct SAML 2.0 federation and IAM role trust relationships in multi-account environments

Estimated Time:2m 0s

Question 1857Question →

A logistics company is designing a new global supply chain tracking system that requires a highly available relational database for an OLTP workload. The application handles write-heavy transactions for package tracking statuses and must support a read-heavy dashboard showing real-time delivery performance metrics. The architecture requires that database read operations scale dynamically during peak shipping seasons without impacting write performance. Additionally, the system must achieve a Recovery Time Objective ( $RTO$ ) of less than $5\text{ minutes}$ and a Recovery Point Objective ( $RPO$ ) of less than $1\text{ minute}$ in the event of an Availability Zone outage. Which database and storage strategy meets these requirements while minimizing management overhead?

Deploy an Amazon RDS for PostgreSQL DB instance with a Multi-AZ standby deployment. Route dashboard read queries directly to the Multi-AZ standby instance, and configure RDS Auto Scaling to scale the standby instance's compute resources during peak hours.

Deploy an Amazon Aurora PostgreSQL DB cluster across multiple Availability Zones. Configure Aurora Replicas to handle the read-heavy dashboard queries, and set up Aurora Auto Scaling to dynamically adjust the number of replicas based on CPU utilization.

Deploy an Amazon RDS for PostgreSQL DB instance with a Multi-AZ deployment. Create cross-region read replicas in a secondary AWS Region to handle read queries, and configure a Pilot Light disaster recovery strategy with daily snapshots to achieve the RTO and RPO requirements.

Deploy an Amazon Aurora PostgreSQL DB cluster. Configure a centralized Amazon S3 bucket in a separate management account to store database backups, and secure the bucket using the default AWS-managed KMS key (aws/s3) with cross-account access granted via bucket policies.

Show answer & explanation

Answer: Deploy an Amazon Aurora PostgreSQL DB cluster across multiple Availability Zones. Configure Aurora Replicas to handle the read-heavy dashboard queries, and set up Aurora Auto Scaling to dynamically adjust the number of replicas based on CPU utilization.

Answer

Deploying an Amazon Aurora PostgreSQL DB cluster across multiple Availability Zones with Aurora Replicas and Aurora Auto Scaling.

Deploying an Amazon Aurora PostgreSQL DB cluster across multiple Availability Zones natively provides high availability with synchronous replication to a shared storage volume, easily meeting the strict

RTO < 5\text{ minutes}

and

RPO < 1\text{ minute}

requirements during an Availability Zone outage. Aurora Replicas share the same underlying storage volume, reducing replication lag to milliseconds. Setting up Aurora Auto Scaling allows the cluster to dynamically scale the number of read replicas in response to CPU utilization spikes on the read-heavy dashboard, minimizing administrative overhead.

Step-by-Step Solution

Analyze database workload and Availability Zone high availability requirements.

The system requires an OLTP database that handles write-heavy transactions and scales reads. An Availability Zone outage must meet

RTO < 5\text{ minutes}

and

RPO < 1\text{ minute}

This establishes the baseline requirements, eliminating single-instance configurations and low-frequency replication options.

Evaluate read-scaling mechanisms and read capability of high availability replicas.

Amazon Aurora Replicas share the cluster's underlying storage volume and can serve read traffic. Standby instances in Amazon RDS Multi-AZ deployments are passive and cannot serve read traffic.

This eliminates options that propose routing queries to standard RDS Multi-AZ standby instances.

Validate scalability and security constraints for the final configuration.

Aurora Auto Scaling dynamically adjusts replica counts based on target metrics (such as CPU utilization) to handle read-heavy dashboard spikes, meeting all RTO/RPO metrics with minimum operational overhead.

This confirms Aurora PostgreSQL with replicas and Auto Scaling is the optimal, low-overhead design.

Key Concept

Relational database high availability and scale-out read architectures

Estimated Time:1m 30s

Question 1858Question →

A healthcare company is designing a new multi-region telehealth application on AWS. The application runs on Amazon EC2 instances inside private subnets in both the us-east-1 (primary) and us-west-2 (secondary) regions. The architecture requires a Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 1 minute. The EC2 instances must be able to securely download software updates from the internet. Additionally, internal microservices in both regions need to resolve private service endpoints using a shared Route 53 Private Hosted Zone (PHZ). Which combination of actions should the solutions architect take to meet these high availability and disaster recovery requirements? (Select TWO.)

Select all that apply

Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2 to meet RPO and RTO targets, and use Route 53 Application Recovery Controller (Route 53 ARC) to manage routing failover.

Configure NAT Gateways in each Availability Zone where private EC2 instances are deployed, and associate the shared Route 53 Private Hosted Zone with the VPCs in both the us-east-1 and us-west-2 regions.

Deploy a single NAT Gateway in the primary Availability Zone of each region to centralize outbound traffic, and route all private subnet traffic in both regions through this single gateway.

Create a Route 53 Private Hosted Zone in us-east-1, and configure a cross-Region VPC peering connection to route internal DNS resolution requests without associating the zone with the us-west-2 VPC.

Implement a Pilot Light disaster recovery strategy by backing up the database to Amazon S3 hourly, copying the snapshots to us-west-2, and restoring them during a disaster event.

Deploy an Amazon RDS DB instance in a Multi-AZ configuration, and configure the secondary standby instance to scale out and process read operations during peak traffic loads.

Show answer & explanation

Answer: Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2 to meet RPO and RTO targets, and use Route 53 Application Recovery Controller (Route 53 ARC) to manage routing failover.; Configure NAT Gateways in each Availability Zone where private EC2 instances are deployed, and associate the shared Route 53 Private Hosted Zone with the VPCs in both the us-east-1 and us-west-2 regions.

Answer

Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2 using Route 53 ARC, and configure redundant NAT Gateways in each Availability Zone of both regions while associating the shared Private Hosted Zone with the VPCs in both regions.

Deploying Amazon Aurora Global Database provides sub-second cross-region replication lag, easily satisfying the 1-minute RPO target, while Route 53 Application Recovery Controller (Route 53 ARC) routing controls manage regional failovers within the 15-minute RTO. Additionally, placing a NAT Gateway in each Availability Zone ensures that an outage in one zone does not block internet access for other zones. Finally, associating the shared Route 53 Private Hosted Zone with both regional VPCs allows secure, cross-Region resolution of internal service endpoints.

Step-by-Step Solution

Address database replication and regional failover limits.

Amazon Aurora Global Database provides sub-second replication (RPO < 1 minute) and Route 53 ARC enables rapid recovery controls (RTO < 15 minutes).

Meets the critical RTO/RPO limits for disaster recovery.

Address private DNS resolution across regions.

Associate the shared Route 53 Private Hosted Zone with the VPCs in both us-east-1 and us-west-2.

Allows instances in both regions to query and resolve internal endpoints within the same domain space.

Ensure highly available outbound internet connectivity.

Deploy NAT Gateways in each Availability Zone across the subnets of both regions.

Eliminates a single point of failure in outbound traffic path during an Availability Zone outage.

Key Concept

Designing multi-region HA/DR systems with Aurora Global Database, redundant NAT Gateways per AZ, and cross-Region Route 53 Private Hosted Zone associations.

Question 1859Question →

AeroParts Global is modernizing its on-premises inventory lookup application by migrating it to AWS. The architecture must run on Amazon ECS using the AWS Fargate launch type to reduce management overhead. The ECS tasks will be deployed in a new VPC (VPC A) and must securely access an internal database hosted in a separate VPC (VPC B) that is connected using an AWS Transit Gateway. The database hostnames are managed via an Amazon Route 53 Private Hosted Zone (PHZ) in the AWS account containing VPC B. Which of the following should a solutions architect configure to ensure that the ECS tasks can resolve the database hostname and establish network connectivity?

Deploy the ECS tasks using the bridge network mode to simplify container port mapping. Associate the Route 53 Private Hosted Zone in the database account with VPC A, and configure Transit Gateway routing to direct database traffic.

Deploy the ECS tasks using the awsvpc network mode. Rely on the Transit Gateway network transit path to automatically route DNS queries to the DNS servers of VPC B without associating the Private Hosted Zone with VPC A, and configure Transit Gateway routing.

Deploy the ECS tasks using the awsvpc network mode. Associate the Route 53 Private Hosted Zone in the database account with VPC A, and update the route tables in VPC A to direct database traffic to the Transit Gateway.

Deploy the ECS tasks using the awsvpc network mode. Provision a Direct Connect Gateway to establish transitive routing between VPC A and VPC B for database traffic, and associate the Route 53 Private Hosted Zone with VPC A.

Show answer & explanation

Answer: Deploy the ECS tasks using the awsvpc network mode. Associate the Route 53 Private Hosted Zone in the database account with VPC A, and update the route tables in VPC A to direct database traffic to the Transit Gateway.

Answer

Deploy the ECS tasks using the awsvpc network mode, associate the Route 53 Private Hosted Zone in the database account with VPC A, and update the route tables in VPC A to direct database traffic to the Transit Gateway.

To run containers on AWS Fargate, the tasks must be configured with the awsvpc network mode because Fargate does not support other modes. To enable DNS resolution of the private hosted zone in VPC A, the zone must be explicitly associated with VPC A. Finally, routing database-destined traffic through the Transit Gateway is required to establish network connectivity between VPC A and VPC B.

Step-by-Step Solution

Determine the required ECS network mode for Fargate tasks.

Identify that ECS tasks on Fargate must use the awsvpc network mode.

AWS Fargate does not support bridge or host networking modes; awsvpc is mandatory.

Determine the DNS resolution requirement for the Private Hosted Zone.

Identify that the Route 53 Private Hosted Zone from the database account must be associated with the application VPC (VPC A).

Private Hosted Zones cannot resolve across Transit Gateway peerings without direct association to the resolving VPC.

Configure network routing between the VPCs.

Add routes in the VPC A route tables pointing database-bound traffic to the Transit Gateway attachment.

The Transit Gateway acts as the router to pass traffic securely between VPC A and VPC B.

Key Concept

ECS Fargate Network Modes and Route 53 PHZ VPC Associations

Estimated Time:2m 0s

Question 1860Question →

A financial services company is implementing a multi-account AWS environment managed by AWS Organizations. The company utilizes a central Identity account to federate corporate identities from an on-premises Active Directory Federation Services (AD FS) server using SAML 2.0. Users first federate into a baseline IAM role in the Identity account. From there, they assume target IAM roles in various Member accounts using the AWS Security Token Service (AWS STS) cross-account role assumption pattern.

The security team requires Attribute-Based Access Control (ABAC) to restrict access to resources. When users federate into the Identity account, the SAML assertion includes the user's department as a session tag. However, when users attempt to assume the target IAM roles in the Member accounts while passing this session tag, the `sts:AssumeRole` API call fails with an Access Denied error.

Which of the following configuration changes is required to resolve this issue and enable session tag propagation for cross-account access?

Configure the on-premises AD FS server as a SAML Identity Provider (IdP) in each Member account, and update the target IAM roles' trust policies to allow the `sts:AssumeRoleWithSAML` action instead of `sts:AssumeRole`.

Modify the trust relationship policy of the IAM role in the central Identity account to allow the `sts:AssumeRole` action for the target IAM roles in the Member accounts, and specify the department tag in the `sts:TransitiveTagKeys` parameter.

Modify the trust relationship policy of the target IAM roles in the Member accounts to allow the `sts:AssumeRole` and `sts:TagSession` actions for the IAM role principal from the central Identity account.

Attach a Service Control Policy (SCP) to the organization's root that allows the `sts:TagSession` action for all resources, as this will inherit down to the target roles in the Member accounts and grant the required tag propagation permission.

Show answer & explanation

Answer: Modify the trust relationship policy of the target IAM roles in the Member accounts to allow the `sts:AssumeRole` and `sts:TagSession` actions for the IAM role principal from the central Identity account.

Answer

The correct answer is to modify the trust relationship policy of the target IAM roles in the Member accounts to allow the `sts:AssumeRole` and `sts:TagSession` actions for the centralized IAM role. When assuming a role and passing session tags, the target role's trust policy must explicitly allow the caller to assume the role and perform the `sts:TagSession` action. Without this action allowed in the trust policy, AWS Security Token Service (STS) will return an Access Denied error when tags are included in the `AssumeRole` call.

Step-by-Step Solution

Analyze the IAM configuration and identify that the user is trying to pass session tags across account boundaries during role chaining.

Determine that the IAM role in the central Identity account acts as the calling principal, and the IAM roles in the Member accounts act as the target roles.

Because the user first federated into the central Identity account, downstream target roles in the Member accounts are assumed via role-to-role chaining (sts:AssumeRole) rather than direct SAML federation.

Evaluate the AWS Security Token Service (STS) requirements for session tags during role-to-role assumption.

Identify that the calling principal must be authorized to tag the session in the target role's trust policy.

By default, sts:AssumeRole does not allow passing session tags unless the target role's trust policy explicitly authorizes both sts:AssumeRole and sts:TagSession for the assuming principal.

Review the proposed solutions to isolate the correct trust policy modification.

Confirm that adding sts:TagSession to the target roles' trust relationship solves the Access Denied issue.

This updates the Member accounts' target roles to allow both role assumption and tag propagation from the central Identity account role.

Key Concept

To pass session tags during cross-account role chaining, the target role's trust policy must explicitly grant both `sts:AssumeRole` and `sts:TagSession` permissions to the calling principal.

Estimated Time:2m 0s

PreviousPage 93 / 99Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Alternative Method

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

Alternative Method

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