All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A logistics enterprise is designing a new high-throughput supply chain tracking application (OLTP and Object storage workloads). The application database must handle unpredictable surges in read queries, and must maintain a recovery time objective (RTO) of less than 5 minutes and a recovery point objective (RPO) of less than 1 minute across two AWS Regions. Additionally, application transaction logs and database backups must be continuously archived to a centralized, encrypted Amazon S3 bucket located in a separate dedicated security AWS account. Which database and storage architecture meets these requirements while ensuring secure cross-account data access?

Deploy Amazon RDS for PostgreSQL in a Multi-AZ configuration in the primary Region and rely on the standby instance to handle read query surges. Configure an RDS Read Replica in the secondary Region to meet the disaster recovery objectives. Store the backups and logs in the security account's S3 bucket, encrypted with a Customer Managed Key (CMK) in the security account, and update the CMK key policy and the S3 bucket policy to allow access from the database account.

Deploy Amazon Aurora PostgreSQL with Aurora Replicas and configure Aurora Auto Scaling. Implement Aurora Global Database to replicate data to the secondary Region. Store the backups and logs in the security account's S3 bucket, encrypted with a Customer Managed Key (CMK) in the security account, and update the CMK key policy and the S3 bucket policy to allow access from the database account.

Deploy Amazon Aurora PostgreSQL with Aurora Replicas and configure Aurora Auto Scaling. Implement Aurora Global Database to replicate data to the secondary Region. Store the backups and logs in the security account's S3 bucket, encrypted with the default AWS-managed KMS key for Amazon S3 (aws/s3) in the security account, and update the S3 bucket policy to allow access from the database account.

Deploy Amazon Aurora PostgreSQL with Aurora Replicas and configure Aurora Auto Scaling. Set up a pilot light disaster recovery strategy by copying automated database snapshots hourly to the secondary Region. Store the backups and logs in the security account's S3 bucket, encrypted with a Customer Managed Key (CMK) in the security account, and update the CMK key policy and the S3 bucket policy to allow access from the database account.

Show answer & explanation

Answer: Deploy Amazon Aurora PostgreSQL with Aurora Replicas and configure Aurora Auto Scaling. Implement Aurora Global Database to replicate data to the secondary Region. Store the backups and logs in the security account's S3 bucket, encrypted with a Customer Managed Key (CMK) in the security account, and update the CMK key policy and the S3 bucket policy to allow access from the database account.

Answer

The architecture that combines Amazon Aurora Global Database for multi-Region replication, Aurora Auto Scaling for read capacity, and cross-account S3 backup storage encrypted with a Customer Managed Key (CMK) from the security account.

Amazon Aurora PostgreSQL with Aurora Replicas and Aurora Auto Scaling handles read surges effectively because Aurora Replicas share the same storage volume and scale out horizontally. Aurora Global Database uses storage-based, asynchronous replication that achieves an RPO of less than 1 minute and an RTO of less than 5 minutes. For cross-account S3 access with KMS encryption, using a Customer Managed Key (CMK) in the destination (security) account is required because its key policy can be modified to grant the source (database/app) account permissions (kms:GenerateDataKey and kms:Decrypt), which allows successful write and read operations across accounts.

Step-by-Step Solution

Analyze the database replication and read scaling requirements.

Determine that Amazon Aurora Global Database satisfies the cross-Region RTO (< 5 minutes) and RPO (< 1 minute) objectives, and Aurora Replicas with Auto Scaling can handle read traffic surges.

RDS Multi-AZ standby instances are passive and cannot serve read queries, and pilot-light backups via hourly snapshots fail the RPO constraint.

Evaluate the cross-account encryption and access control requirements for backups stored in the centralized Amazon S3 bucket.

Identify that a Customer Managed Key (CMK) in the target security account is required to allow cross-account access.

AWS-managed KMS keys (like aws/s3) do not support policy modifications and cannot be shared across accounts.

Configure access policies for the cross-account S3 bucket and KMS CMK.

Grant the database account permissions in the S3 bucket policy and the KMS CMK key policy.

Both policies must allow cross-account write permissions for database backups and application logs to be successfully stored and encrypted.

Key Concept

Designing highly available, scalable databases with low-RTO/RPO multi-Region disaster recovery, combined with secure, cross-account encrypted storage configurations using Customer Managed Keys (CMKs).

Estimated Time:3m 0s

Question 1562Question →

A media streaming platform hosts its content delivery, transcoding, and recommendation engine on AWS. The environment is organized under an AWS Organizations structure with consolidated billing. The transcoding tasks run on Amazon ECS using AWS Fargate, the recommendation engine is built on AWS Lambda, and the main web platform runs on an Auto Scaling group of Amazon EC2 instances. A Solutions Architect is tasked with optimizing the compute costs for these workloads without impacting application availability or introducing management overhead.

Which of the following actions should the Solutions Architect recommend to optimize resource costs? (Select TWO.)

Select all that apply

Commit to Compute Savings Plans at the organization's management account level, which applies cost reductions to the EC2, Fargate, and Lambda compute workloads across the member accounts.

Activate AWS Compute Optimizer in the organization management account to analyze utilization metrics for EC2 and Fargate, allowing right-sizing of resources prior to purchasing any savings commitments.

Commit to EC2 Instance Savings Plans at the management account level to cover the combined compute usage of the EC2 instances, Fargate tasks, and Lambda functions across the organization.

Utilize AWS Resource Access Manager (RAM) to share the savings commitments from the management account to the member accounts, ensuring that target workloads receive the discounts first.

Route all egress traffic from member VPCs through a single NAT Gateway located in a shared transit VPC to eliminate hourly fees for multiple NAT Gateways.

Show answer & explanation

Answer: Commit to Compute Savings Plans at the organization's management account level, which applies cost reductions to the EC2, Fargate, and Lambda compute workloads across the member accounts.; Activate AWS Compute Optimizer in the organization management account to analyze utilization metrics for EC2 and Fargate, allowing right-sizing of resources prior to purchasing any savings commitments.

Answer

Commit to Compute Savings Plans at the organization's management account level, and activate AWS Compute Optimizer in the organization management account to analyze utilization metrics for EC2 and Fargate to right-size resources before purchasing savings commitments.

Committing to Compute Savings Plans at the organization's management account level is correct because Compute Savings Plans automatically apply to EC2 instances, ECS Fargate tasks, and Lambda functions across all member accounts in the organization. Activating AWS Compute Optimizer allows the organization to right-size these resources before committing to a Savings Plan, which ensures that the savings plan is sized to actual needs, avoiding waste.

Step-by-Step Solution

Enable resource analysis and optimization recommendations.

AWS Compute Optimizer is activated at the AWS Organizations level, providing recommendations to right-size the EC2 instances and ECS Fargate tasks based on historical performance metrics.

Right-sizing resources first prevents purchasing excess savings commitments for over-provisioned infrastructure.

Assess the requirements of the mixed compute environment.

Identify that the workloads run across different compute services: EC2 instances, ECS Fargate tasks, and Lambda functions.

The choice of Savings Plan must cover all three compute types to maximize cost efficiency.

Select and purchase the appropriate Savings Plan type at the management account level.

Compute Savings Plans are purchased in the management account, which automatically applies discount rates to EC2, Fargate, and Lambda across all member accounts within the consolidated billing structure.

Compute Savings Plans offer the highest flexibility and are the only type that applies to EC2, Fargate, and Lambda simultaneously.

Key Concept

Compute cost optimization requires a combination of resource right-sizing to eliminate waste and selecting flexible Savings Plans (Compute Savings Plans) to cover heterogeneous compute resources (EC2, Fargate, Lambda) across an AWS Organization.

Question 1563Question →

A company is modernizing its application by migrating a background processing workload to AWS Lambda. One specific Lambda function receives a high volume of bursty, unpredictable traffic. The solutions architect needs to ensure that this function does not consume the entire account-level concurrent execution pool, which would throttle other critical production functions in the same AWS region.

Which of the following actions should the solutions architect take to resolve this issue?

Configure the Lambda function to use an AWS-managed KMS key to encrypt environment variables in order to isolate execution environments and throttle concurrent requests.

Configure reserved concurrency on the high-volume Lambda function to limit its maximum concurrent executions and guarantee capacity for other functions.

Deploy the Lambda function in a single private subnet using a single NAT Gateway to restrict outbound traffic and manage the invocation rate.

Apply a rolling update deployment strategy with AWS CodeDeploy to restrict traffic during updates and automatically handle concurrency issues.

Show answer & explanation

Answer: Configure reserved concurrency on the high-volume Lambda function to limit its maximum concurrent executions and guarantee capacity for other functions.

Answer

Configure reserved concurrency on the high-volume Lambda function to limit its maximum concurrent executions and guarantee capacity for other functions.

Configuring reserved concurrency on the high-volume function restricts its maximum concurrency to a set value, preventing it from exhausting the regional account-level concurrency pool. It also reserves that capacity for the function, protecting both the bursty function and other critical functions from mutual throttling.

Step-by-Step Solution

Analyze the impact of bursty Lambda function traffic on the AWS account's regional concurrency pool.

Uncapped bursty functions can consume the entire shared regional concurrency pool, causing other functions in the account to be throttled.

By default, all Lambda functions in an AWS account share the regional concurrency limit (usually

1{}000

Determine the mechanism to limit the maximum executions of a specific function and isolate its concurrency impact.

Reserved concurrency limits the maximum executions for a specific function and reserves a portion of the pool specifically for it.

Setting reserved concurrency prevents the function from scaling past the designated limit and ensures other functions always have execution capacity.

Key Concept

AWS Lambda Concurrency Management

Estimated Time:1m 0s

Question 1564Question →

A financial services company is migrating its legacy core ledger system, consisting of $25$ physical on-premises servers, to AWS using AWS Application Migration Service (MGN). Due to strict security and compliance regulations, all migration and replication traffic must remain private and be routed over an existing AWS Direct Connect (DX) connection linked to an AWS Transit Gateway. The solutions architect has established AWS PrivateLink interface VPC endpoints for MGN in the Staging Area VPC and enabled the 'Use private IP' option in the MGN replication template. After installing the MGN agent on all on-premises source servers, the replication status is reported as stalled.

Which of the following actions should the solutions architect take to resolve this issue and enable replication?

Reconfigure the Direct Connect connection to use a Direct Connect Gateway directly attached to the Staging Area VPC to route replication traffic, bypassing the Transit Gateway under the assumption that Direct Connect Gateway supports transitive routing between the source and multiple target VPCs.

Allow outbound traffic on TCP port 1500 from the on-premises servers, update the Staging Area VPC security group to allow inbound traffic on TCP port 1500 from the on-premises IP ranges, and verify that AWS Transit Gateway routing tables are configured to route traffic correctly between the on-premises network and the Staging Area VPC.

Configure Route 53 Resolver Inbound Endpoints in the Staging Area VPC, associate the Route 53 Private Hosted Zone (PHZ) containing the MGN endpoint names with the on-premises DNS servers directly instead of associating the PHZ with the VPC, and open TCP port 443 on the on-premises firewalls.

Deploy a single NAT Gateway in a public subnet of the Staging Area VPC to route replication traffic through public endpoints, configure the on-premises firewalls to allow outbound TCP port 443, and configure Transit Gateway routing tables to direct replication traffic through this NAT Gateway.

Show answer & explanation

Answer: Allow outbound traffic on TCP port 1500 from the on-premises servers, update the Staging Area VPC security group to allow inbound traffic on TCP port 1500 from the on-premises IP ranges, and verify that AWS Transit Gateway routing tables are configured to route traffic correctly between the on-premises network and the Staging Area VPC.

Answer

The correct answer resolves the stalled replication status by ensuring that TCP port 1500 (the data replication port for AWS Application Migration Service) is permitted outbound from the on-premises source servers, inbound to the Staging Area VPC security groups, and that the AWS Transit Gateway routing tables are correctly configured to forward this private traffic between the environments.

Step-by-Step Solution

Analyze the components of MGN communication pathways.

Identify that control plane communication uses HTTPS (TCP port 443) via PrivateLink VPC endpoints, while data replication uses TCP port 1500.

Since the agent is successfully installed but data replication is stalled, the control plane (port 443) is working, indicating the block-level data replication path (port 1500) is obstructed.

Identify network firewall and security group requirements for data replication.

Determine that outbound TCP port 1500 must be open on the on-premises firewall, and inbound TCP port 1500 must be open in the Staging Area VPC security groups.

Replication agents send data blocks directly to replication servers in the staging area over TCP port 1500.

Verify hybrid network routing.

Ensure Transit Gateway route tables contain appropriate routes to direct traffic between the on-premises subnet range and the Staging Area VPC subnets.

Data replication traffic must find a path over the Direct Connect and Transit Gateway link in both directions.

Key Concept

Data replication over private channels in AWS Application Migration Service (MGN)

Question 1565Question →

A municipal government operates a smart-city environmental telemetry platform that monitors sensor networks across the metropolitan area. The ingestion application is hosted on Amazon EC2 instances in an Auto Scaling Group (ASG) behind an Application Load Balancer (ALB) distributed across three Availability Zones. The EC2 instances run a telemetry processing application that requires approximately $8\text{ minutes}$ to bootstrap, initialize configuration caches, and pass health checks.

The platform experiences a highly predictable daily traffic surge at 7:00 AM local time when thousands of environmental sensors activate simultaneously to transmit night-time logs. During this surge, incoming traffic rises from $10,000\text{ requests per second}$ to $350,000\text{ requests per second}$ in a $5\text{-minute}$ window, resulting in frequent HTTP 502 (Bad Gateway) and HTTP 504 (Gateway Timeout) errors. Furthermore, the platform's outbound transmissions to external environmental monitoring agencies fail completely if Availability Zone A experiences an outage, as the subnet route tables in all Availability Zones point to a single NAT Gateway located in Availability Zone A.

The solutions architect must redesign the architecture to prevent request drops during the daily surge, ensure high availability for outbound traffic, and minimize administrative and operational overhead.

Which combination of actions should the solutions architect implement to meet these requirements?

Configure a target tracking scaling policy based on average CPU utilization with the instance warm-up time set to

120\text{ seconds}

to scale out quickly during spikes. Request AWS Support to pre-warm the ALB to handle the daily traffic peaks. Keep the single NAT Gateway in Availability Zone A and configure an AWS Lambda function to update the route tables to redirect outbound traffic to a fallback NAT Gateway in Availability Zone B during an outage.

Configure scheduled scaling to scale out the ASG at 6:45 AM daily. Deploy a NAT Gateway in each of the three public subnets, and update the private route tables accordingly. Rely on the ALB's default automatic scaling capacity to handle the traffic surge as new instances are launched, and adjust the target tracking policy warm-up time to

480\text{ seconds}

Configure scheduled scaling to scale out the ASG at 6:45 AM daily using an ASG Warm Pool with pre-warmed instances to bypass the bootstrapping delay. Request AWS Support to pre-warm the ALB to handle the target traffic volume by 7:00 AM daily. Deploy a NAT Gateway in the public subnet of each Availability Zone, and update the route tables of the private subnets to use the local NAT Gateway in their respective Availability Zone.

Configure scheduled scaling to scale out the ASG at 6:45 AM daily using an ASG Warm Pool with pre-warmed instances. Request AWS Support to pre-warm the ALB to handle the target traffic volume. Retain the single NAT Gateway in Availability Zone A and configure the route tables of private subnets in the other Availability Zones to route outbound traffic through Availability Zone A.

Show answer & explanation

Answer: Configure scheduled scaling to scale out the ASG at 6:45 AM daily using an ASG Warm Pool with pre-warmed instances to bypass the bootstrapping delay. Request AWS Support to pre-warm the ALB to handle the target traffic volume by 7:00 AM daily. Deploy a NAT Gateway in the public subnet of each Availability Zone, and update the route tables of the private subnets to use the local NAT Gateway in their respective Availability Zone.

Answer

The correct solution is to configure scheduled scaling to scale out the ASG using an ASG Warm Pool to eliminate the

8\text{-minute}

bootstrapping lag, request AWS Support to pre-warm the ALB to handle the sudden

35\text{x}

traffic spike, and deploy independent NAT Gateways in each Availability Zone to ensure high availability and eliminate the single point of failure.

The correct response implements scheduled scaling 15 minutes before the daily surge (

6:45\text{ AM}

) using an ASG Warm Pool, which ensures instances are bootstrapped and ready to transition to the in-service state immediately. Furthermore, pre-warming the ALB ensures the load balancer can handle the

350,000\text{ requests per second}

peak without dropping connections, and deploying a NAT Gateway in each Availability Zone removes the single point of failure for outbound API tracking updates.

Step-by-Step Solution

Address the application bootstrapping lag.

By using scheduled scaling combined with an ASG Warm Pool containing stopped or running pre-warmed instances, the bootstrapping time is reduced to seconds, allowing capacity to be ready before the 7:00 AM surge.

Since standard bootstrapping takes

8\text{ minutes}

and the surge completes in

5\text{ minutes}

, reactive or dynamic scaling will always scale out too late, causing capacity deficits.

Address the load balancer scaling delay.

Requesting AWS Support to pre-warm the ALB to scale the underlying load balancer capacity to handle the

350,000\text{ requests per second}

target volume by 7:00 AM.

ALBs scale automatically but cannot absorb a sudden

35\text{x}

spike in 5 minutes without dropping requests. Pre-warming configures the target capacity in advance.

Ensure fault tolerance for outbound traffic.

Deploy a NAT Gateway in the public subnet of each of the three Availability Zones and update route tables to use local NAT Gateways.

Consolidating routing to a single NAT Gateway in Availability Zone A introduces a single point of failure, violating the fault tolerance and high availability requirements.

Key Concept

Mitigating rapid flash traffic surges and single-point-of-failure routing in multi-AZ VPC architectures.

Question 1566Question →

A digital publishing company hosting peer-reviewed journals uses a Multi-AZ Amazon RDS for PostgreSQL DB instance to store journal articles and metadata. The platform experiences a massive increase in read requests when new volumes are published. The search engine queries are complex, and the database CPU utilization regularly exceeds $85\%$ , causing latency spikes for authors submitting new articles. The metadata does not change after publication, but high availability of the cached data is critical to ensure uninterrupted access. Which solution should a solutions architect implement to resolve the performance bottleneck while ensuring database efficiency?

Deploy an Amazon ElastiCache for Redis replication group with Multi-AZ enabled, and configure the application to utilize a cache-aside strategy for metadata queries.

Deploy an Amazon ElastiCache for Memcached cluster, and configure the application to utilize a cache-aside strategy for metadata queries to handle the read volume.

Modify the existing Amazon RDS for PostgreSQL DB instance to enable a Multi-AZ deployment, and redirect read queries for journal metadata to the standby DB instance.

Deploy an Amazon ElastiCache for Memcached cluster, configure replication across multiple Availability Zones using read replicas, and use a write-through strategy for metadata.

Show answer & explanation

Answer: Deploy an Amazon ElastiCache for Redis replication group with Multi-AZ enabled, and configure the application to utilize a cache-aside strategy for metadata queries.

Answer

Deploy an Amazon ElastiCache for Redis replication group with Multi-AZ enabled, and configure the application to utilize a cache-aside strategy for metadata queries.

The correct option proposes deploying an Amazon ElastiCache for Redis replication group with Multi-AZ enabled. Redis supports replication and automatic failover across multiple Availability Zones, ensuring high availability. Applying a cache-aside pattern allows the application to serve the read-heavy, static journal metadata from the cache first, successfully reducing the database CPU utilization below the

85\%

bottleneck.

Step-by-Step Solution

Analyze the workload requirements and database bottleneck.

Identify that the database CPU is overloaded due to complex read-heavy queries for static metadata, and high availability of the cache is a hard requirement.

This helps determine that a caching layer is needed to offload reads from RDS, and the cache must support replication and failover.

Compare caching engines (Redis vs. Memcached) against the high-availability requirement.

Select Amazon ElastiCache for Redis because it supports multi-AZ replication groups with auto-failover, whereas Memcached does not support replication.

This satisfies the high-availability constraint for the cached metadata.

Choose the cache integration strategy.

Implement a cache-aside (lazy loading) strategy where the application queries Redis first, and falls back to RDS only on a cache miss, populating the cache afterwards.

This pattern is optimal for read-heavy databases with relatively static metadata, preventing unnecessary load on RDS.

Key Concept

Selecting the appropriate caching engine and architecture based on high-availability and replication requirements.

Estimated Time:2m 0s

Question 1567Question →

RetailPulse is modernizing its inventory tracking application by migrating it from an on-premises Kubernetes cluster to Amazon EKS. The Solutions Architect has decided to use EKS with AWS Fargate profiles to run the application pods. The pods must run in private subnets without direct internet access and cannot use a NAT gateway due to strict corporate security policies. The pods must securely connect to an Amazon RDS for PostgreSQL database located in a database VPC within the same region. The database uses IAM database authentication, and static credentials must not be stored within the containers. Additionally, the pods need to pull container images from an Amazon ECR private repository in the same region. Which TWO configurations must the Solutions Architect implement to meet these requirements?

Select all that apply

Configure an IAM OpenID Connect (OIDC) identity provider for the EKS cluster. Create an IAM role with the rds-db:connect permission and a trust policy that permits the OIDC provider to assume the role. Create a Kubernetes service account annotated with the IAM role ARN, and configure the application pods to use this service account.

Set the EKS cluster endpoint access to private. Create interface VPC endpoints in the application VPC for ECR API and ECR Docker registry, and create a gateway VPC endpoint for Amazon S3. Establish a VPC peering connection or Transit Gateway between the application VPC and the database VPC, and update the VPC route tables and security groups accordingly.

Attach the rds-db:connect policy to the Amazon EKS Fargate execution role, and specify the database endpoints and execution parameters inside the Kubernetes ConfigMap associated with the Fargate profile.

Configure the EKS cluster endpoint access to public. Deploy a single NAT Gateway in a public subnet of the application VPC to allow the pods to pull images from the ECR registry and connect to the database VPC over the internet.

Deploy the Amazon EKS Pod Identity Agent on the Fargate nodes, and create an EKS Pod Identity association that maps the Kubernetes service account directly to an IAM role containing the rds-db:connect permissions.

Show answer & explanation

Answer: Configure an IAM OpenID Connect (OIDC) identity provider for the EKS cluster. Create an IAM role with the rds-db:connect permission and a trust policy that permits the OIDC provider to assume the role. Create a Kubernetes service account annotated with the IAM role ARN, and configure the application pods to use this service account.; Set the EKS cluster endpoint access to private. Create interface VPC endpoints in the application VPC for ECR API and ECR Docker registry, and create a gateway VPC endpoint for Amazon S3. Establish a VPC peering connection or Transit Gateway between the application VPC and the database VPC, and update the VPC route tables and security groups accordingly.

Answer

The correct configurations are to configure an IAM OpenID Connect (OIDC) identity provider for the EKS cluster to assign the database connection role via IRSA to the Kubernetes service account, and to set the EKS cluster endpoint to private while creating VPC endpoints for ECR and S3 along with VPC peering or Transit Gateway to reach the database VPC.

To authenticate with the RDS database using IAM database credentials without storing secrets, pods must assume an IAM role. Since EKS Pod Identities are not supported on EKS Fargate, the cluster must use IAM Roles for Service Accounts (IRSA) by configuring an IAM OIDC provider, creating an IAM role, and annotating the Kubernetes service account. Furthermore, to run pods in private subnets without a NAT gateway, the EKS cluster endpoint must be set to private so that pods can communicate with the control plane inside the VPC. Interface endpoints for ECR and a gateway endpoint for S3 are required to pull container images privately. A VPC peering or Transit Gateway connection allows private routing to the database VPC.

Step-by-Step Solution

Configure the identity delegation mechanism for EKS Fargate workloads.

Since AWS Fargate does not support EKS Pod Identities, configure an IAM OIDC provider for the EKS cluster to enable IAM Roles for Service Accounts (IRSA). Create an IAM role with the necessary rds-db:connect permissions, modify its trust policy to trust the OIDC provider, annotate the Kubernetes service account, and specify it in the Pod definition.

This enables pods to assume IAM roles dynamically and authenticate with Amazon RDS using IAM database authentication without storing static credentials.

Establish private networking for container image downloads and control plane traffic.

Set the EKS cluster endpoint access configuration to private so control plane traffic stays within the VPC. Deploy Interface VPC Endpoints for ECR API and ECR Docker, and a Gateway VPC Endpoint for S3.

This allows EKS Fargate nodes to pull container images from ECR private registries and communicate with the EKS control plane without needing route access through a NAT Gateway.

Configure secure cross-VPC routing to the database VPC.

Establish a VPC peering connection or Transit Gateway between the application VPC and the database VPC, and configure the target route tables and security groups.

This ensures the application pods in the private subnets can connect to the database endpoint privately without traversing the public internet.

Key Concept

Configuring private container workloads on Amazon EKS with AWS Fargate, utilizing Interface VPC Endpoints for private ECR image downloads, private cluster endpoints, and setting up IAM Roles for Service Accounts (IRSA) for pod-level IAM authentication.

Question 1568Question →

AeroWing Engineering is migrating its telemetry parsing system to AWS. The system consists of multiple microservices that need to run on Amazon ECS using AWS Fargate. The microservices must run in private subnets with no internet access. The services need to resolve the internal domain names of other services hosted in a separate VPC inside the same AWS organization. A Route 53 private hosted zone has been created for these internal domains in the shared services VPC. The ECS tasks must also pull container images from Amazon ECR and fetch application secrets from AWS Secrets Manager.

Which configurations must the Solutions Architect implement to meet these requirements? (Select TWO.)

Select all that apply

Associate the Route 53 private hosted zone in the shared services VPC with the ECS VPC, and enable DNS resolution and DNS hostnames in the ECS VPC.

Configure the ECS task definition to use the awsvpc network mode, and deploy interface VPC endpoints for Amazon ECR and AWS Secrets Manager, along with a gateway VPC endpoint for Amazon S3, within the ECS VPC.

Configure the ECS task definition to use the bridge network mode to map container ports to host ports, and route the tasks' external traffic through a Transit Gateway to pull ECR images.

Create a Route 53 resolver rule in the ECS VPC to forward queries for the internal domain to the inbound resolver endpoint in the shared services VPC, without associating the private hosted zone.

Deploy a single NAT Gateway in a public subnet of the ECS VPC and configure the ECS task definition to use host network mode to enable direct routing of task traffic to the NAT Gateway.

Show answer & explanation

Answer: Associate the Route 53 private hosted zone in the shared services VPC with the ECS VPC, and enable DNS resolution and DNS hostnames in the ECS VPC.; Configure the ECS task definition to use the awsvpc network mode, and deploy interface VPC endpoints for Amazon ECR and AWS Secrets Manager, along with a gateway VPC endpoint for Amazon S3, within the ECS VPC.

Answer

The correct configurations are: (1) Associate the Route 53 private hosted zone in the shared services VPC with the ECS VPC, and enable DNS resolution and DNS hostnames in the ECS VPC; and (2) Configure the ECS task definition to use the awsvpc network mode, and deploy interface VPC endpoints for Amazon ECR and AWS Secrets Manager, along with a gateway VPC endpoint for Amazon S3, within the ECS VPC.

To support containerized microservices running on AWS Fargate in a fully isolated VPC with no internet access, interface VPC endpoints (PrivateLink) must be deployed for Amazon ECR and AWS Secrets Manager, and a gateway VPC endpoint is required for Amazon S3. Fargate tasks must use the awsvpc network mode because Fargate does not support other modes. To resolve the internal domains hosted in the shared services VPC, the private hosted zone must be associated with the ECS VPC, and DNS hostnames and DNS resolution must be enabled within that VPC.

Step-by-Step Solution

Determine the network mode and endpoint configuration for ECS tasks on AWS Fargate.

Identify that AWS Fargate tasks require the awsvpc network mode. Since the subnets are private without internet access, PrivateLink interface endpoints must be set up for Amazon ECR (api and dkr) and AWS Secrets Manager, alongside a gateway endpoint for Amazon S3 to fetch container image layers.

Tasks on Fargate cannot use bridge or host network modes. Because they run in private subnets with no internet routes, they must connect to AWS services privately via VPC endpoints.

Determine how to resolve internal domain names managed by Route 53 in a shared services VPC.

Establish a cross-VPC association between the Route 53 private hosted zone and the ECS VPC. Ensure that DNS resolution and DNS hostnames are enabled on the ECS VPC.

Route 53 private hosted zones cannot be resolved by default across VPC boundaries without an explicit association, even if the VPCs are peered or belong to the same AWS Organization.

Key Concept

Modernizing legacy workloads using ECS Fargate requires configuring tasks with the awsvpc network mode and establishing private service connectivity via VPC endpoints in isolated network environments, alongside proper cross-VPC Route 53 private hosted zone associations.

Alternative Method

Instead of using interface VPC endpoints for ECR and Secrets Manager directly in the ECS VPC, a private transit VPC or a shared VPC architecture could be implemented. In this model, interface endpoints are hosted centrally, and traffic is routed via AWS Transit Gateway, reducing endpoint cost across multiple VPCs while maintaining strict isolation from the public internet.

Estimated Time:2m 30s

Question 1569Question →

A financial institution has a hybrid architecture with a $10\text{ Gbps}$ AWS Direct Connect connection using a Private Virtual Interface (VIF) to a Direct Connect Gateway. The gateway is associated with an AWS Transit Gateway that connects $5$ VPCs in the `us-east-1` Region. Currently, application servers in these VPCs transfer $300\text{ TB}$ of transactional logs monthly to an Amazon S3 bucket in the same Region via NAT Gateways in each Availability Zone. Concurrently, an on-premises backup system synchronizes $150\text{ TB}$ of data monthly to another S3 bucket in `us-east-1` over the internet using public S3 endpoints. Which of the following solutions reduces data transfer and processing costs most effectively while maintaining high availability?

Create an Amazon S3 Gateway Endpoint in each VPC, update the VPC route tables to direct S3 traffic to the gateway endpoints, and establish a Public VIF on the existing Direct Connect connection to route the on-premises S3 synchronization traffic.

Consolidate the NAT Gateways in each VPC to a single Availability Zone to eliminate hourly NAT Gateway charges, create an S3 Gateway Endpoint in each VPC, and deploy an S3 Interface Endpoint in a shared VPC to route on-premises traffic through the Direct Connect Private VIF and Transit Gateway.

Deploy an Amazon S3 Interface Endpoint in each VPC for all VPC-to-S3 traffic, and establish a Transit VIF on the Direct Connect connection to route the on-premises S3 backup traffic through the Transit Gateway to the S3 Interface Endpoints.

Create an Amazon S3 Gateway Endpoint in each VPC to optimize VPC S3 traffic, and request a new AWS Snowball Edge Storage Optimized device monthly to physically copy and ship the

150\text{ TB}

of backup data to AWS.

Show answer & explanation

Answer: Create an Amazon S3 Gateway Endpoint in each VPC, update the VPC route tables to direct S3 traffic to the gateway endpoints, and establish a Public VIF on the existing Direct Connect connection to route the on-premises S3 synchronization traffic.

Answer

The correct solution uses Amazon S3 Gateway Endpoints in each VPC, which are free and eliminate the NAT Gateway data processing fees of $0.045 per gigabyte for the 300 TB of VPC-to-S3 traffic. For the on-premises backup synchronization traffic of 150 TB, creating a Public Virtual Interface (VIF) on the existing Direct Connect connection allows the traffic to route directly to S3 public endpoints. Because data transfer in to AWS is free, this avoids both the Transit Gateway processing fees of 0.02 per gigabyte and S3 Interface Endpoint data processing fees of 0.01 per gigabyte, resulting in a zero-cost solution for the hybrid data synchronization.

Step-by-Step Solution

Analyze the current VPC S3 traffic cost.

The VPC-to-S3 traffic is

300\text{ TB}

monthly. Routing this through NAT Gateways incurs data processing fees of

300,000\text{ GB} \times \$0.045\text{/GB} = \$13,500

per month.

To identify the largest source of data processing charges in the current architecture.

Select the optimal VPC-to-S3 routing method.

S3 Gateway Endpoints are free and support high availability natively. Transitioning the

300\text{ TB}

of logs to S3 Gateway Endpoints reduces the VPC data processing costs from

\$13,500

\$0

To eliminate NAT Gateway processing fees for Amazon S3 traffic while maintaining high availability.

Evaluate hybrid connectivity and data transfer paths for the on-premises backups.

Creating a Public VIF on the existing Direct Connect link allows the on-premises backup agent to write to S3 public IP addresses over Direct Connect. Since data transfer into AWS is free, and the path bypasses Transit Gateway and VPC interface endpoints, the

150\text{ TB}

backup synchronization incurs

\$0

in data transfer and processing fees.

To secure and optimize the on-premises to S3 synchronization without incurring Transit Gateway (

0.02 per GB) or Interface Endpoint (

0.01 per GB) processing fees.

Key Concept

Minimizing data transfer and processing costs for high-throughput AWS and hybrid architectures using Gateway VPC Endpoints and Direct Connect Public VIFs.

Question 1570Question →

A Solutions Architect is migrating a self-managed, on-premises MySQL 8.0 database to an Amazon Aurora PostgreSQL-Compatible Edition DB cluster. The migration strategy uses the AWS Schema Conversion Tool (SCT) to convert the schema and AWS Database Migration Service (DMS) for ongoing replication (Change Data Capture - CDC) to minimize downtime. After converting the schema and creating the target tables, the architect configures a DMS task with a migration type of 'Full load, ongoing replication'. The task successfully completes the full load phase, but fails shortly after starting the CDC phase. Investigation reveals that binary logging is enabled on the source MySQL server with the format set to ROW, but the replication task cannot process UPDATE operations. Which configuration action on the source MySQL database will resolve this issue?

Set the parameter binlog_row_image to FULL in the MySQL configuration file and restart the MySQL service.

Execute ALTER TABLE statements on the source database to enable supplemental logging for primary keys on all tables.

Set the binlog_format parameter to MIXED in the MySQL configuration file and restart the MySQL service.

Install the AWS DMS Binary Reader agent on the source database host and configure it to read the transaction logs directly.

Show answer & explanation

Answer: Set the parameter binlog_row_image to FULL in the MySQL configuration file and restart the MySQL service.

Answer

Set the parameter binlog_row_image to FULL in the MySQL configuration file and restart the MySQL service.

The correct answer is to configure the source MySQL parameter binlog_row_image to FULL. In heterogeneous migrations (such as MySQL to Aurora PostgreSQL), AWS DMS requires the full database row before and after the modification to apply updates and deletes on the target. If binlog_row_image is set to MINIMAL or NOBLOB, the binlog will only record the changed columns, which causes DMS replication tasks to fail during the change data capture (CDC) phase.

Step-by-Step Solution

Analyze the error state of the AWS DMS CDC task.

The task succeeds in the full load phase but fails during CDC when attempting to process UPDATE statements.

The full load reads directly from the tables, whereas CDC reads from the binary logs to reconstruct database transactions.

Verify the binary logging configuration on the source MySQL database.

The binlog_format is set to ROW, but the database lacks the full row image configuration.

By default or due to performance tuning, MySQL might log only modified columns (MINIMAL) which is insufficient for heterogeneous target engines like PostgreSQL that need full row details to execute UPDATE commands.

Apply the required configuration change to the MySQL parameter file.

Configuring binlog_row_image to FULL ensures the complete row context is written to the binlog for every change.

This allows the DMS task to correctly parse and translate the source updates to target updates on Aurora PostgreSQL.

Key Concept

Configuring source database binary logging requirements (binlog_row_image) for heterogeneous AWS DMS CDC tasks.

Estimated Time:2m 30s

Question 1571Question →

A company is planning to migrate its on-premises VMware vSphere virtual machines (VMs) to VMware Cloud on AWS. The migration strategy requires that workloads be moved with minimal downtime and that the VMs retain their existing IP addresses during and after the migration. Which TWO steps must the solutions architect take to meet these requirements?

Select all that apply

Deploy the VMware HCX Connector in the on-premises environment and establish a site pairing with the VMware HCX Cloud Manager in the VMware Cloud on AWS Software-Defined Data Center (SDDC).

Configure an HCX Network Extension to stretch the on-premises Layer 2 networks to the VMware Cloud on AWS SDDC.

Configure AWS Transit Gateway to natively route Layer 2 broadcast traffic between the on-premises vSphere cluster and the VMware Cloud on AWS SDDC.

Install the AWS Application Migration Service (MGN) replication agent on all virtual machines and configure them to replicate data over a public connection with TCP port 1500 blocked for security.

Configure a Pilot Light disaster recovery pattern using AWS Backup to replicate VM storage snapshots every 24 hours to meet a near-zero RTO migration objective.

Show answer & explanation

Answer: Deploy the VMware HCX Connector in the on-premises environment and establish a site pairing with the VMware HCX Cloud Manager in the VMware Cloud on AWS Software-Defined Data Center (SDDC).; Configure an HCX Network Extension to stretch the on-premises Layer 2 networks to the VMware Cloud on AWS SDDC.

Answer

To meet the requirements, the solutions architect must deploy the VMware HCX Connector on-premises to pair with the VMware HCX Cloud Manager in the VMware Cloud on AWS SDDC, and configure an HCX Network Extension to stretch the Layer 2 network.

To migrate VMs to VMware Cloud on AWS with minimal downtime while retaining their IP configurations, the solutions architect must set up site pairing between the on-premises VMware HCX Connector and the VMware HCX Cloud Manager. Stretching the Layer 2 network via HCX Network Extension ensures that VMs do not need to be reconfigured with new IP addresses upon cutover.

Step-by-Step Solution

Deploy the VMware HCX Connector in the on-premises vSphere environment and pair it with the VMware HCX Cloud Manager.

A secure site pairing is established between the on-premises data center and the VMware Cloud on AWS SDDC.

This establishes the control plane required to coordinate migrations and network stretch services.

Configure an HCX Network Extension on the active site pairing.

The on-premises Layer 2 networks are extended into the VMware Cloud on AWS SDDC overlay networks.

This allows virtual machines to migrate without requiring IP address changes, maintaining connectivity continuity.

Key Concept

Establishing VMware HCX site pairing and extending Layer 2 networks to allow low-downtime migrations without IP changes.

Estimated Time:2m 0s

Question 1572Question →

An enterprise runs a microservice application hosted on Amazon ECS tasks in Account A. The microservice processes messages from an Amazon SQS queue in Account B. Currently, the SQS queue is encrypted using the default AWS-managed KMS key (aws/sqs), and network traffic travels over the public internet. The company's security policy requires that all network traffic between the ECS tasks and the SQS queue remains private within the AWS network, and access to the queue must be restricted to only the ECS tasks via a specific network path. Which combination of actions will meet these security requirements?

Configure an interface VPC endpoint for SQS in Account A's VPC. Retain the AWS-managed KMS key on the SQS queue in Account B, and update the KMS key policy to grant the ECS task role in Account A permissions to decrypt and generate data keys. Update the SQS queue policy in Account B to allow access from the ECS task role in Account A, and add a condition that restricts requests to the SQS VPC endpoint ID using the aws:sourceVpce condition key.

Configure an interface VPC endpoint for SQS in Account A's VPC. Replace the AWS-managed KMS key on the SQS queue in Account B with a Customer Managed Key, and update its key policy to grant the ECS task role in Account A permissions to decrypt and generate data keys. Update the SQS queue policy in Account B to allow access from the ECS task role in Account A, and add a condition that restricts requests to the SQS VPC endpoint ID using the aws:sourceVpce condition key.

Configure an interface VPC endpoint for SQS in Account A's VPC. Replace the AWS-managed KMS key on the SQS queue in Account B with a Customer Managed Key. Apply a Service Control Policy at the Organization root that allows cross-account SQS and KMS access between Account A and Account B, relying on the Service Control Policy to grant the ECS task role the necessary permissions to access the queue and the Customer Managed Key.

Configure an interface VPC endpoint for SQS in a central transit VPC connected to Account A's VPC via AWS Transit Gateway. Enable Private DNS on the SQS interface VPC endpoint, but do not associate the resulting Route 53 Private Hosted Zone with Account A's VPC. Update the SQS queue policy in Account B to allow access from the ECS task role in Account A, and add a condition that restricts requests to the SQS VPC endpoint ID using the aws:sourceVpce condition key.

Show answer & explanation

Answer: Configure an interface VPC endpoint for SQS in Account A's VPC. Replace the AWS-managed KMS key on the SQS queue in Account B with a Customer Managed Key, and update its key policy to grant the ECS task role in Account A permissions to decrypt and generate data keys. Update the SQS queue policy in Account B to allow access from the ECS task role in Account A, and add a condition that restricts requests to the SQS VPC endpoint ID using the aws:sourceVpce condition key.

Answer

Configure an interface VPC endpoint in the application's VPC, use a Customer Managed Key for queue encryption with cross-account access granted in the key policy, and update the SQS queue policy to permit the application's ECS task role while restricting access to the VPC endpoint ID.

The correct solution involves creating an interface VPC endpoint in Account A to route the traffic privately, using a Customer Managed Key in Account B (since AWS-managed keys cannot be shared cross-account), and updating the SQS queue policy to authorize the ECS task role with a condition specifying the VPC endpoint ID.

Step-by-Step Solution

Set up a private path to the SQS service.

Create an interface VPC endpoint for SQS in Account A's VPC so traffic does not traverse the public internet.

This establishes a private network connection to SQS using AWS PrivateLink.

Configure cross-account key encryption permissions.

Replace the AWS-managed KMS key (aws/sqs) on the SQS queue in Account B with a Customer Managed Key, and configure its key policy to allow the ECS task role in Account A key access.

AWS-managed KMS keys cannot be shared across accounts, necessitating a Customer Managed Key for cross-account access.

Configure the SQS queue resource policy to authorize the role and restrict the network path.

Update the SQS queue policy in Account B to grant access to the ECS task role in Account A, using a condition block with aws:sourceVpce set to the VPC endpoint ID.

This allows identity-based cross-account access while restricting traffic to the specific network interface endpoint.

Key Concept

Cross-account access to encrypted SQS queues using VPC endpoints requires a Customer Managed KMS Key (since AWS-managed keys cannot be shared across accounts) and an SQS resource policy that explicitly trusts the external principal while conditionally restricting network access to the VPC endpoint ID.

Question 1573Question →

An enterprise is designing a new AWS networking architecture in the us-west-2 region consisting of three spoke VPCs (vpc-prod-app, vpc-prod-web, and vpc-prod-data) and one centralized services VPC (vpc-shared-services). The shared services VPC hosts a Route 53 Private Hosted Zone (PHZ) named corp.aws. The architecture requires that the spoke VPCs can resolve DNS queries for corp.aws and route all outbound internet traffic through a centralized egress VPC (vpc-central-egress) using NAT Gateways. The solution must ensure high availability for outbound traffic across two Availability Zones and minimize administrative overhead. Which of the following designs best satisfies these requirements?

Deploy an AWS Transit Gateway named tgw-core and attach all four VPCs to it. Create two NAT Gateways in vpc-central-egress, with one located in public-subnet-1a (Availability Zone AZ-A) and the other in public-subnet-1b (Availability Zone AZ-B). Configure private route tables in vpc-central-egress to direct internet traffic (

0.0.0.0/0

) to the NAT Gateway in the same Availability Zone. Update the Transit Gateway route tables to route all outbound internet traffic from the spokes to vpc-central-egress. Associate the corp.aws Route 53 Private Hosted Zone with the shared services VPC and all three spoke VPCs.

Deploy an AWS Transit Gateway named tgw-core and attach all four VPCs to it. Create a single NAT Gateway in vpc-central-egress, located in public-subnet-1a (Availability Zone AZ-A). Configure all private route tables in vpc-central-egress to direct all internet traffic (

0.0.0.0/0

) to this single NAT Gateway. Update the Transit Gateway route tables to route all outbound internet traffic from the spokes to vpc-central-egress. Associate the corp.aws Route 53 Private Hosted Zone with the shared services VPC and all three spoke VPCs.

0.0.0.0/0

) to the NAT Gateway in the same Availability Zone. Update the Transit Gateway route tables to route all outbound internet traffic from the spokes to vpc-central-egress. Associate the corp.aws Route 53 Private Hosted Zone only with vpc-shared-services, relying on the Transit Gateway attachments to transitively resolve DNS queries from the spoke VPCs.

Deploy an AWS Direct Connect Gateway named dxgw-core and establish private virtual interfaces to connect all four VPCs. Create two NAT Gateways in vpc-central-egress, with one located in public-subnet-1a (Availability Zone AZ-A) and the other in public-subnet-1b (Availability Zone AZ-B). Route spoke-to-spoke and internet-bound traffic (

0.0.0.0/0

) through the Direct Connect Gateway. Associate the corp.aws Route 53 Private Hosted Zone with the shared services VPC and all three spoke VPCs.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway named tgw-core and attach all four VPCs to it. Create two NAT Gateways in vpc-central-egress, with one located in public-subnet-1a (Availability Zone AZ-A) and the other in public-subnet-1b (Availability Zone AZ-B). Configure private route tables in vpc-central-egress to direct internet traffic ( $0.0.0.0/0$ ) to the NAT Gateway in the same Availability Zone. Update the Transit Gateway route tables to route all outbound internet traffic from the spokes to vpc-central-egress. Associate the corp.aws Route 53 Private Hosted Zone with the shared services VPC and all three spoke VPCs.

Answer

Deploy AWS Transit Gateway, configure dual NAT Gateways in the egress VPC across different Availability Zones, route spoke egress traffic through the egress VPC, and associate the Route 53 Private Hosted Zone with all spoke VPCs.

The correct architecture uses AWS Transit Gateway to centralize transit routing, deploys redundant NAT Gateways across two Availability Zones to prevent a single point of failure, and explicitly associates the Private Hosted Zone with all spoke VPCs to allow DNS resolution across the accounts.

Step-by-Step Solution

Configure centralized routing for outbound internet traffic using AWS Transit Gateway.

All spoke VPCs route

0.0.0.0/0

traffic to the Transit Gateway, which forwards it to the centralized egress VPC.

Transit Gateway provides a hub-and-spoke model to centralize egress traffic, reducing management overhead and enabling centralized security control.

Deploy highly available NAT Gateways in the egress VPC.

Two NAT Gateways are deployed in separate public subnets in different Availability Zones (AZ-A and AZ-B), with private subnets routing outbound traffic to their local NAT Gateway.

Deploying a NAT Gateway in each Availability Zone avoids a single point of failure and ensures high availability for outbound traffic.

Associate the Route 53 Private Hosted Zone with the target VPCs.

The corp.aws private hosted zone is explicitly associated with all spoke VPCs and the shared services VPC.

Route 53 Private Hosted Zones cannot be transitively resolved across VPCs via Transit Gateway without direct association or configuring a Route 53 Resolver.

Key Concept

Centralized, resilient egress networking using AWS Transit Gateway and multi-AZ NAT Gateways combined with Route 53 Private Hosted Zone cross-VPC association.

Question 1574Question →

A financial services firm is planning to migrate its core transactional systems to AWS. The on-premises environment consists of 150 physical bare-metal servers running supported versions of Red Hat Enterprise Linux and Windows Server, and 300 virtual machines hosted on Nutanix AHV. The compliance team requires process-level network dependency mapping for all servers to group them into applications before migration. The network security policy prohibits direct outbound internet access from individual database and application servers, but allows traffic to pass through a centralized administrative proxy server. Which strategy should a Solutions Architect recommend to discover the environment and track the migration in AWS Migration Hub?

Install the AWS Application Discovery Agent on all physical and virtual servers. Configure the agents to route outbound discovery metadata through the centralized administrative proxy server. Use the collected dependency data in AWS Migration Hub to group the servers into applications.

Deploy the AWS Application Discovery Agentless Collector in the Nutanix AHV environment and configure it to query the hypervisor APIs. For the physical servers, configure a central log collector to forward system syslog and event logs to AWS Migration Hub for dependency analysis.

Install the AWS Application Discovery Agent on all physical and virtual servers. Configure the local server firewalls to bypass the security policy and allow outbound HTTPS traffic directly over TCP port 443 to the public AWS Application Discovery Service endpoints.

Deploy AWS Database Migration Service (DMS) agents on the database servers to capture schema and dependency data. For the application servers, deploy the AWS Application Discovery Agentless Collector on a dedicated management server configured to scan the subnet ranges.

Show answer & explanation

Answer: Install the AWS Application Discovery Agent on all physical and virtual servers. Configure the agents to route outbound discovery metadata through the centralized administrative proxy server. Use the collected dependency data in AWS Migration Hub to group the servers into applications.

Answer

Install the AWS Application Discovery Agent on all physical and virtual servers, configure them to route discovery metadata through the centralized administrative proxy server, and use AWS Migration Hub to group the servers into applications.

The correct strategy is to deploy the AWS Application Discovery Agent on all physical and virtual servers. The agent-based approach is necessary because the environment includes physical bare-metal servers and Nutanix AHV VMs, which are not supported by the VMware-only Agentless Collector. Furthermore, the agent is required to capture the process-level network dependency mapping demanded by the compliance team. To respect the network security policy that bans direct internet access, the agents can be configured to forward metadata through the central administrative proxy server.

Step-by-Step Solution

Determine the appropriate discovery mechanism based on virtualization and OS requirements.

Since the environment has bare-metal servers and Nutanix AHV (non-VMware), and requires process-level network dependency mapping, the agentless collector cannot be used. The AWS Application Discovery Agent must be selected.

The Agentless Collector only supports VMware vCenter and does not gather OS process-level dependency detail, which is needed to map applications for compliance.

Configure the agent networking to comply with security guidelines.

Configure the AWS Application Discovery Agents to route their HTTPS outbound traffic (port 443) through the centralized administrative proxy server.

This complies with the network security policy prohibiting direct outbound internet access while still allowing metadata to reach the AWS Application Discovery Service.

Group the discovered servers into applications within AWS Migration Hub.

Visualize and analyze the dependency mapping in Migration Hub to organize the servers into logical application groups for migration tracking.

Grouping servers helps in planning migration waves and tracking migration status in a centralized dashboard.

Key Concept

AWS Application Discovery Service deployment choices and networking configurations

Question 1575Question →

A company is planning to migrate a collection of 50 non-production virtual machines (VMs) from their on-premises VMware vSphere environment to VMware Cloud on AWS. The company has scheduled a 4-hour maintenance window for the final cutover, which allows for a brief service reboot. The total data volume is 10 TB, and the migration must be completed with minimal manual intervention. Which VMware HCX migration method should the solutions architect select to meet these requirements?

VMware HCX Bulk Migration

VMware HCX Cold Migration

VMware HCX vMotion

AWS Application Migration Service (MGN)

Show answer & explanation

Answer: VMware HCX Bulk Migration

Answer

VMware HCX Bulk Migration is the correct method because it replicates VM data in the background and schedules a switchover with a brief reboot, which meets the downtime tolerance and handles bulk migrations efficiently.

The correct migration method is VMware HCX Bulk Migration because it performs low-downtime replication of virtual machines in the background while they are running. It then schedules a cutover that initiates a brief VM reboot on the destination site, which perfectly aligns with the requirement to migrate 50 VMs with a tolerated brief service reboot during the maintenance window.

Step-by-Step Solution

Determine the target platform, number of VMs, data volume, and downtime allowance.

The target is VMware Cloud on AWS, with 50 VMs, 10 TB total data, and a brief reboot is allowed during a 4-hour maintenance window.

Establishes the core requirements to eliminate incompatible migration methods.

Compare the VMware HCX migration options against the requirements.

HCX Bulk Migration allows background replication, avoiding long offline times for 10 TB, and supports a reboot-based switchover. Cold migration requires VMs to be offline during the entire transfer (which would exceed the window), and vMotion is for sequential live migrations.

Identifies the option that meets the RTO/RPO requirements and bulk migration capability.

Verify if a native VMware tool or an AWS migration service is required.

Since the target is VMware Cloud on AWS, native VMware HCX integration is standard, whereas AWS Application Migration Service targets native Amazon EC2.

Ensures the chosen tool aligns with the target environment architecture.

Key Concept

VMware HCX Migration Types and Use Cases

Question 1576Question →

A manufacturing company is migrating its legacy ERP inventory management servers from an on-premises data center to AWS using AWS Application Migration Service (MGN). The replication traffic must travel privately over an existing AWS Direct Connect connection terminated at an AWS Transit Gateway. The target architecture spans multiple Availability Zones in the staging area VPC and target production VPC. The Solutions Architect must design a highly available replication architecture that ensures private data transfer and proper DNS resolution for the MGN endpoints. Which of the following designs represents the correct setup to allow private replication and meet high availability requirements?

Configure the MGN replication template to use private IP routing. Open TCP port 443 in the staging area security groups to allow agent-to-service communication over SSL/TLS, but block TCP port 1500 to restrict unencrypted replication data from traversing the network, relying on the replication agent to tunnel all data blocks over HTTPS.

Configure the MGN replication template to use private IP routing. Set up the Route 53 Private Hosted Zone for the MGN interface endpoints in a central shared services VPC, and rely on Transit Gateway route tables to resolve the DNS queries without associating the hosted zone with the staging area or target VPCs.

Configure the MGN replication template to route data replication traffic privately over the Direct Connect connection using the Transit Gateway. Associate the Route 53 Private Hosted Zone containing the MGN endpoints with both the staging area VPC and target VPC. Provision independent NAT Gateways in each Availability Zone of the staging area VPC to handle outbound public traffic, and permit inbound traffic from the on-premises network to the replication servers on TCP port 1500 at the staging VPC level.

Configure the MGN replication template to route replication traffic privately over the Direct Connect connection. To optimize resource utilization and costs within the multi-AZ staging area VPC, configure the route tables of all private subnets to point to a single NAT Gateway deployed in a single public subnet.

Show answer & explanation

Answer: Configure the MGN replication template to route data replication traffic privately over the Direct Connect connection using the Transit Gateway. Associate the Route 53 Private Hosted Zone containing the MGN endpoints with both the staging area VPC and target VPC. Provision independent NAT Gateways in each Availability Zone of the staging area VPC to handle outbound public traffic, and permit inbound traffic from the on-premises network to the replication servers on TCP port 1500 at the staging VPC level.

Answer

The correct architecture requires configuring MGN to route traffic privately over Direct Connect via the Transit Gateway, ensuring TCP port 1500 is open in the security groups, associating the Private Hosted Zone with all VPCs to resolve the service endpoints, and deploying redundant NAT Gateways across multiple Availability Zones to ensure high availability.

Step-by-Step Solution

Analyze network requirements for MGN replication

Determine that TCP port 1500 must be open for data replication traffic, and TCP port 443 is required for agent-to-service control plane communication.

MGN uses a separate control plane and data replication plane, which must both be accessible by the Replication Agent.

Evaluate DNS resolution requirements for private endpoints

Recognize that Route 53 Private Hosted Zones must be explicitly associated with each VPC (Staging and Target) to allow proper resolution of MGN endpoints within the AWS environment.

Without explicit association, DNS queries for the service endpoints from these VPCs will fail to resolve to the private interface endpoints.

Assess high availability configurations for the staging environment

Deploy redundant NAT Gateways across multiple Availability Zones in the staging VPC to ensure outbound connectivity does not have a single point of failure.

Using a single NAT Gateway in a multi-AZ setup introduces a single point of failure for outbound internet traffic if that specific AZ becomes unavailable.

Key Concept

Establishing secure, private, and highly available hybrid replication pathways for AWS Application Migration Service (MGN) using Transit Gateway, interface endpoints, and Route 53 Private Hosted Zones.

Question 1577Question →

A platform team is automating the deployment of a microservice on Amazon ECS (Fargate) across multiple AWS accounts. The CI/CD pipeline is hosted in a centralized tooling account using AWS CodePipeline. The pipeline must deploy the microservice to a production account using AWS CodeDeploy with a canary strategy that shifts 10% of traffic immediately, waits for 15 minutes, and then shifts the remaining 90% of traffic if no alarms are triggered. The deployment must automatically roll back if any Amazon CloudWatch alarms are triggered in the production account during the deployment. The pipeline artifact S3 bucket in the tooling account is encrypted. Which configuration should the platform team implement to meet these requirements securely and automatically?

Configure the AWS CodeDeploy deployment group in the production account with the CodeDeployDefault.ECSCanary10Percent15Minutes deployment configuration and specify the production CloudWatch alarms for rollback. Encrypt the S3 artifact bucket in the tooling account using a customer managed AWS KMS key, and configure the KMS key policy to allow the cross-account CodeDeploy execution role to decrypt the artifacts.

Configure the AWS CodeDeploy deployment group in the production account with the CodeDeployDefault.ECSLinear10PercentEvery15Minutes deployment configuration and configure an AWS Lambda function to monitor production CloudWatch alarms and manually call the StopDeployment API. Encrypt the S3 artifact bucket in the tooling account using a customer managed AWS KMS key, and configure the KMS key policy to allow the cross-account CodeDeploy execution role to decrypt the artifacts.

Configure the AWS CodeDeploy deployment group in the production account with the CodeDeployDefault.ECSCanary10Percent15Minutes deployment configuration and specify the production CloudWatch alarms for rollback. Encrypt the S3 artifact bucket in the tooling account using the default AWS-managed S3 key (aws/s3), and configure an IAM policy on the production account's CodeDeploy execution role to decrypt the artifacts.

Configure AWS CloudFormation StackSets to deploy the task definition and service directly to the production account. Use a rolling deployment strategy by updating the stack, and configure an administrator to manually revert the task definition to the previous version in the Amazon ECS console if production CloudWatch alarms are triggered. Encrypt the S3 artifact bucket in the tooling account using a customer managed AWS KMS key.

Show answer & explanation

Answer: Configure the AWS CodeDeploy deployment group in the production account with the CodeDeployDefault.ECSCanary10Percent15Minutes deployment configuration and specify the production CloudWatch alarms for rollback. Encrypt the S3 artifact bucket in the tooling account using a customer managed AWS KMS key, and configure the KMS key policy to allow the cross-account CodeDeploy execution role to decrypt the artifacts.

Answer

The correct configuration uses the CodeDeployDefault.ECSCanary10Percent15Minutes deployment configuration, which shifts 10% of traffic immediately and the remaining 90% after 15 minutes, fulfilling the canary deployment requirements. It also uses a customer managed KMS key to encrypt S3 artifacts because default AWS-managed KMS keys do not support policy modification and cannot be used for cross-account decryption by the production account's role.

Step-by-Step Solution

Select the deployment configuration in CodeDeploy.

CodeDeployDefault.ECSCanary10Percent15Minutes is selected to shift 10% of traffic immediately and the remaining 90% after 15 minutes.

This matches the target traffic shifting pattern for the canary deployment strategy.

Configure cross-account S3 artifact decryption using a customer managed KMS key.

The S3 bucket in the tooling account is encrypted with a customer managed KMS key, and the key policy grants decrypt permissions to the production account role.

AWS-managed KMS keys do not support key policy modifications and cannot be shared across accounts, necessitating a customer managed key.

Associate CloudWatch alarms with the CodeDeploy deployment group.

Native automatic rollback triggers are configured when production CloudWatch alarms enter the ALARM state.

This automates rollback handling without custom Lambda scripting or manual console intervention.

Key Concept

Cross-account deployment automation and KMS key delegation in AWS CodePipeline and AWS CodeDeploy.

Estimated Time:2m 0s

Question 1578Question →

An enterprise has a multi-account AWS Organization. An application in VPC-Prod under Account A uses a Route 53 Private Hosted Zone (PHZ) named internal.corp for service discovery. During a security and operations review, the Solutions Architect identifies two issues:

1. Administrators operating from VPC-Shared in Account B cannot resolve the DNS records within internal.corp.
2. A containerized reporting service running on Amazon ECS tasks in Account B must retrieve data from an S3 bucket in Account A. The S3 bucket is currently encrypted using an AWS KMS key. Even though the S3 bucket policy allows access to Account B's root principal, the ECS tasks in Account B receive access denied errors when attempting to read the objects.

Which two configuration steps should the Solutions Architect implement to resolve these security and access issues? (Select two.)

Select all that apply

Authorize the VPC association for VPC-Shared from Account A using the AWS CLI, and then associate VPC-Shared with the internal.corp Private Hosted Zone from Account B.

Configure the S3 bucket in Account A to use a Customer Managed Key (CMK) for encryption, and update the CMK's key policy in Account A to grant the ECS task IAM role in Account B the required KMS decrypt permissions.

Configure the S3 bucket in Account A to use the default AWS-managed KMS key (aws/s3), and modify its key policy to grant the ECS task IAM role in Account B cross-account decrypt permissions.

Apply a Service Control Policy (SCP) to the Organizational Unit containing Account B that explicitly allows the 'route53:AssociateVPCWithHostedZone' action for the resources in Account A.

Deploy an outbound Route 53 Resolver endpoint in VPC-Shared and configure a resolver rule pointing to a Direct Connect Gateway to enable transitive DNS routing to the Private Hosted Zone.

Show answer & explanation

Answer: Authorize the VPC association for VPC-Shared from Account A using the AWS CLI, and then associate VPC-Shared with the internal.corp Private Hosted Zone from Account B.; Configure the S3 bucket in Account A to use a Customer Managed Key (CMK) for encryption, and update the CMK's key policy in Account A to grant the ECS task IAM role in Account B the required KMS decrypt permissions.

Answer

To resolve the DNS and cross-account access issues, the Solutions Architect must authorize the VPC association for VPC-Shared from Account A and associate it from Account B, and configure the S3 bucket to use a Customer Managed Key (CMK) with a key policy that grants decrypt permissions to the ECS task IAM role in Account B.

The correct options are to authorize the VPC association for VPC-Shared from Account A and then associate it from Account B, and to use a Customer Managed Key with a policy that allows the ECS task IAM role in Account B decrypt permissions. Authorizing and associating the PHZ directly enables DNS resolution across the accounts. Using a Customer Managed Key allows the key policy to be customized, which is required because AWS-managed keys cannot be shared across accounts.

Step-by-Step Solution

Authorize the VPC association from the account owning the Private Hosted Zone (Account A) to the VPC in the consumer account (Account B).

VPC-Shared becomes authorized to associate with the internal.corp Private Hosted Zone.

Route 53 Private Hosted Zones cannot be directly associated with VPCs in other accounts without explicit cross-account authorization.

Associate VPC-Shared with the Private Hosted Zone from Account B.

Administrators in VPC-Shared can successfully resolve internal.corp DNS records.

This establishes the logical association, allowing DNS queries in VPC-Shared to resolve using the records in the PHZ.

Change the S3 bucket encryption from the default AWS-managed KMS key to a Customer Managed Key (CMK) in Account A.

The bucket is encrypted using a key whose policy can be modified.

AWS-managed KMS keys do not support policy edits, which prevents granting the necessary cross-account KMS permissions to Account B.

Update the Customer Managed Key's policy in Account A to grant kms:Decrypt permissions to the ECS task IAM role in Account B.

The ECS task in Account B receives permission to decrypt objects retrieved from the S3 bucket.

Cross-account access to KMS-encrypted S3 objects requires permissions in both the S3 bucket policy (or IAM policy) and the KMS key policy.

Key Concept

Cross-account resource access using Customer Managed Keys and cross-account Route 53 Private Hosted Zone association.

Estimated Time:2m 0s

Question 1579Question →

A solutions architect is planning the migration of an on-premises Oracle database to an Amazon Aurora PostgreSQL-Compatible Edition DB cluster. The database contains tables with Large Objects (LOBs) and requires continuous replication to minimize downtime. The schema has already been converted using the AWS Schema Conversion Tool (SCT). The architect is now configuring AWS Database Migration Service (AWS DMS) for the full load and Change Data Capture (CDC) replication phases.

Which two configurations are required to ensure the replication succeeds and performs optimally? (Select two.)

Select all that apply

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

Configure the AWS DMS task using Limited LOB mode and set a Max LOB size parameter that accommodates the maximum size of LOBs in the migrated tables.

Rely on default Oracle configurations by executing the replication task without enabling supplemental logging, as AWS DMS reads the active redo logs directly to capture changes automatically.

Execute the database migration as a simple Replatforming path by utilizing the AWS SCT to automatically deploy unchanged Oracle PL/SQL stored procedures directly into the Aurora PostgreSQL target database.

Configure the AWS DMS target endpoint to use Aurora PostgreSQL read replicas to scale the database write performance and parallelize the data load during the CDC phase.

Show answer & explanation

Answer: Enable supplemental logging at the Oracle database level and add supplemental logging for primary keys on all tables selected for replication.; Configure the AWS DMS task using Limited LOB mode and set a Max LOB size parameter that accommodates the maximum size of LOBs in the migrated tables.

Answer

To perform a successful and optimal migration, you must enable supplemental logging at both the database and primary key table levels on the source Oracle database, and configure the AWS DMS task to use Limited LOB mode with an appropriate maximum LOB size.

Enabling supplemental logging at the database level and on the tables ensures that Oracle writes full row changes to its redo logs, which is a hard prerequisite for AWS DMS CDC. Configuring Limited LOB mode with a correct Max LOB size optimizes data transfer speeds during full load and replication because DMS pre-allocates memory buffers, avoiding the performance degradation associated with Full LOB mode.

Step-by-Step Solution

Configure the source database for Change Data Capture (CDC).

Supplemental logging is enabled at the database level and for primary keys on target tables, ensuring changed data details are captured in the redo logs.

Without supplemental logging, Oracle does not write the necessary columns to the redo logs for updates and deletes, preventing DMS from replicating transactions.

Determine the optimal LOB handling strategy.

Limited LOB mode is selected, and the Max LOB size parameter is configured based on the largest LOB in the source tables.

Limited LOB mode pre-allocates memory buffers, making replication much faster than Full LOB mode, which queries LOB columns line-by-line.

Establish target connections and migration types.

The target endpoint is pointed to the primary writer instance, and the migration strategy is treated as a Refactoring project.

AWS DMS must write to the writer node, and heterogeneous database migrations require code conversions that go beyond simple replatforming.

Key Concept

Heterogeneous database migration requirements including source database CDC prerequisites and LOB optimization settings in AWS DMS.

Question 1580Question →

An application is hosted on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer. The application performs external payment verification by sending outbound API requests over the internet. Currently, all outbound internet traffic is routed through a single NAT Gateway in a single Availability Zone. The application experiences sudden, brief traffic spikes. During these spikes, the application suffers from performance degradation because new instances take 10 minutes to bootstrap, while the Auto Scaling group scale-out cooldown is configured to 300 seconds. Additionally, a recent localized outage in one Availability Zone caused all outbound payment verification requests to fail.

Which of the following actions should the Solutions Architect take to improve the auto-scaling responsiveness and fault tolerance of the architecture? (Select TWO.)

Select all that apply

Deploy a NAT Gateway in each Availability Zone utilized by the Auto Scaling group, and update the private subnet route tables to direct outbound traffic to the local NAT Gateway.

Configure an Auto Scaling group warm pool to maintain pre-initialized instances in a Stopped state, and increase the scale-out cooldown period to exceed the bootstrap time.

Decrease the Auto Scaling group scale-out cooldown period to 60 seconds to allow the group to respond more rapidly to subsequent traffic spikes.

Keep the single NAT Gateway in its current Availability Zone and add a route in all private subnet route tables pointing to the NAT Gateway to ensure high availability.

Contact AWS Support to pre-warm the Application Load Balancer to handle the bootstrap delay of the EC2 instances.

Show answer & explanation

Answer: Deploy a NAT Gateway in each Availability Zone utilized by the Auto Scaling group, and update the private subnet route tables to direct outbound traffic to the local NAT Gateway.; Configure an Auto Scaling group warm pool to maintain pre-initialized instances in a Stopped state, and increase the scale-out cooldown period to exceed the bootstrap time.

Answer

Deploy a NAT Gateway in each Availability Zone and update the route tables, and configure an Auto Scaling group warm pool with an increased scale-out cooldown period.

To ensure fault tolerance for outbound internet traffic, a NAT Gateway must be deployed in each Availability Zone. This ensures that a failure in one zone does not disrupt internet access for instances in other zones. Additionally, configuring a warm pool allows instances to be pre-initialized, which drastically reduces the time required to handle sudden traffic spikes. Adjusting the scale-out cooldown period to be longer than the bootstrap time prevents the Auto Scaling group from launching extra, unnecessary instances before the initial scaling action takes effect.

Step-by-Step Solution

Address the outbound connectivity fault tolerance.

NAT Gateways are deployed in each active Availability Zone, and private subnet route tables are updated to point to the NAT Gateway in the same zone.

This removes the single point of failure for outbound payment verification requests.

Address the instance boot latency.

A warm pool is configured with instances in a stopped state.

This allows instances to be pre-initialized (bootstrapped) and quickly brought into service during scale-out events, reducing the scaling delay.

Correct the cooldown thrashing.

The scale-out cooldown period is increased to match or exceed the bootstrap time.

This ensures the Auto Scaling group waits for the newly launched instances to begin sending metrics before evaluating if further scaling is needed.

Key Concept

Implementing Auto Scaling and Fault Tolerance

PreviousPage 79 / 99Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

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

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution