Examkin

All practice questions

1964 questions

All types1,964Multiple choice1,006Multiple select931Ordering27
Question 661Question →

An enterprise is designing a centralized compliance auditing and logging architecture across more than 100 AWS accounts managed under AWS Organizations. A solutions architect is setting up an organization-wide trail in the management account to deliver AWS CloudTrail logs to a centralized Amazon S3 bucket located in a dedicated Log Archive account. The security team requires all log files to be encrypted at rest using a Key Management Service (KMS) key. Member accounts must not be able to decrypt logs from other accounts, and all log delivery must be securely restricted to the organization. Which of the following configurations must the solutions architect implement to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create a customer managed key in AWS KMS in the Log Archive account. Configure the key policy to grant the cloudtrail.amazonaws.com service principal kms:GenerateDataKey* and kms:DescribeKey permissions, using a condition that restricts access to the organization's trails.; Configure the S3 bucket policy in the Log Archive account to grant the cloudtrail.amazonaws.com service principal s3:PutObject and s3:GetBucketAcl` permissions, restricting the s3:PutObject resource path to the organization's path structure and enforcing the bucket-owner-full-control ACL.

Answer

To secure centralized multi-account CloudTrail logging, create a customer managed key in the Log Archive account and configure its key policy to grant the CloudTrail service principal the necessary permissions to generate data keys. Additionally, configure the S3 bucket policy in the Log Archive account to grant the CloudTrail service principal permissions to write objects under the organization's path prefix while enforcing the bucket-owner-full-control access control list.
Implementing a centralized, encrypted logging architecture requires a Customer Managed Key (CMK) in the Log Archive account with a key policy allowing the CloudTrail service principal to generate data keys. Simultaneously, the S3 bucket policy in the Log Archive account must grant the CloudTrail service principal permissions to read the bucket ACL and write logs into the organization-specific prefix (AWSLogs/o-orgid/*) using the bucket-owner-full-control ACL to ensure log files remain owned by the Log Archive account.

Step-by-Step Solution

1
Analyze cross-account encryption requirements
Identify that an AWS-managed key cannot be used because it cannot be modified to support cross-account operations. A Customer Managed Key (CMK) must be created in the target Log Archive account.
Allows control over the key policy to grant the CloudTrail service principal cross-account access.
2
Configure the KMS CMK Key Policy
Grant the cloudtrail.amazonaws.com service principal the kms:GenerateDataKey* and kms:DescribeKey actions.
Allows CloudTrail to generate the unique data keys needed to encrypt logs before delivering them to the S3 bucket.
3
Configure the S3 Bucket Policy
Grant the cloudtrail.amazonaws.com service principal the s3:PutObject and s3:GetBucketAcl actions, restricted to the AWSLogs/o-orgid/* path structure.
Enables the CloudTrail service to write logs from any account in the organization directly to the centralized bucket while ensuring proper log isolation and resource ownership.

Key Concept

Cross-account centralized logging using AWS Organizations, AWS CloudTrail, Amazon S3 bucket policies, and AWS KMS Customer Managed Keys.
Question 662Question →

An enterprise is designing a highly resilient hybrid network for its AWS environment in the `us-east-1` Region, which consists of 8080 spoke VPCs across multiple AWS accounts. The enterprise has a primary on-premises data center in Chicago and a secondary backup data center in Dallas.

The design must satisfy the following technical requirements:
* Scalability: The solution must support routing to all 8080 spoke VPCs without exceeding default AWS service quotas or resource association limits.
* Primary Path: All traffic between the Chicago data center and the AWS VPCs must use a dedicated 1010 Gbps AWS Direct Connect (DX) connection.
* Secondary Path: The Dallas data center must connect to AWS via an IPsec VPN over the public internet, which should act as the primary path for Dallas and a standby path for Chicago traffic if the Chicago DX link fails.
* Routing Failover: Failover from the Chicago DX connection to the Dallas VPN must be fully dynamic and automated using BGP.
* Administrative Overhead: The solution must avoid configuring individual VPN connections or virtual private gateways (VGWs) for each of the 8080 VPCs.
* Transit Prevention: The Chicago and Dallas data centers must not be able to route traffic to each other through the AWS network.

Which routing configuration and architecture pattern best meets these requirements?

Show answer & explanation

Answer: Deploy an AWS Transit Gateway (TGW) and attach all 8080 spoke VPCs to it. Create a Direct Connect Gateway (DXGW) and associate it with the TGW. Establish a Transit Virtual Interface (VIF) on the Chicago DX connection to the DXGW. Deploy an AWS Site-to-Site VPN from Dallas to the TGW. Configure BGP on the customer gateways, advertising the Chicago CIDR over both the DX connection and the Dallas VPN connection. Create two TGW route tables: a Spoke Route Table associated with the VPC attachments that propagates routes from the DXGW and VPN attachments, and a Hybrid Route Table associated with the DXGW and VPN attachments that propagates routes only from the VPC attachments.

Answer

Deploying an AWS Transit Gateway with two distinct route tables to segment traffic, using a Direct Connect Gateway for the primary connection, a Site-to-Site VPN for backup, and configuring BGP to advertise the Chicago prefix over both paths.
The correct configuration uses an AWS Transit Gateway to aggregate the 8080 spoke VPCs, avoiding direct association limits on the Direct Connect Gateway. It employs two TGW route tables to separate the routing domains: VPC attachments route to both hybrid paths, while hybrid attachments (DXGW and VPN) only propagate routes from VPCs, preventing Chicago and Dallas from communicating through AWS. For failover, because TGW naturally prefers DXGW over VPN for the same prefix length, advertising the Chicago CIDR on both paths ensures the VPN remains a standby path until a DX link failure occurs.

Step-by-Step Solution

1
Evaluate scale and resource limitations.
Recognize that with 8080 spoke VPCs, associating Virtual Private Gateways directly to a Direct Connect Gateway is blocked by the default limit of 1010 VGWs per DXGW. Therefore, AWS Transit Gateway (TGW) must be utilized as the central hub.
Ensures that the design respects AWS service limits and reduces administrative complexity.
2
Establish the hybrid connectivity paths.
Deploy an AWS Transit Gateway. Connect the 8080 VPCs as attachments. Create a DXGW and associate it with the TGW. Terminate the Chicago connection on a Transit VIF to the DXGW, and deploy a Site-to-Site VPN from Dallas terminating on the TGW.
Configures the required hybrid physical and logical paths into the TGW.
3
Design routing isolation for transit prevention.
Create a 'Spoke Route Table' and a 'Hybrid Route Table'. Associate the Spoke Route Table with the VPC attachments and propagate routes from DXGW and VPN. Associate the Hybrid Route Table with the DXGW and VPN attachments and propagate routes only from the VPC attachments.
Since the Hybrid Route Table has no route propagation from the DXGW and VPN attachments, TGW will drop any traffic sent between Chicago and Dallas, preventing transit routing between them.
4
Configure dynamic failover routing.
Configure the customer gateway in Dallas to advertise Chicago's prefix (`10.1.0.0/1610.1.0.0/16`) via BGP over the VPN. Configure Chicago to advertise it over the DX connection. When the DX connection is healthy, TGW automatically prefers the DXGW route over the VPN route for the same prefix. If the DX fails, the route is withdrawn, and traffic dynamically routes over the VPN to Dallas.
Leverages the default path preference of AWS Transit Gateway (DXGW preferred over VPN for identical prefixes) to implement dynamic active/passive failover.

Key Concept

Transit Gateway Route Tables (Route Domains) and Route Preference Evaluation
Estimated Time:3m 0s
Question 663Question →

An international retail consortium manages its multi-account structure using AWS Organizations. The security team has established a dedicated workloads Organizational Unit (OU) that houses several production and development member accounts. Each member account has local administrator access granted to the respective engineering leads.

The security team has a new compliance directive: only a centralized, pre-approved IAM role named AnalyticsConsumer (which will be deployed across all member accounts) must be permitted to run queries using Amazon Athena. Local administrators must be blocked from executing Athena queries under their own sessions. Crucially, the design must prevent these local administrators from tampering with the AnalyticsConsumer role, deleting it, or recreating a role with the same name to bypass the restriction.

Which solution represents the most secure and operationally efficient configuration to meet these requirements?

Show answer & explanation

Answer: Deploy the AnalyticsConsumer role across the member accounts using AWS CloudFormation StackSets. Attach an SCP to the workloads OU that denies all athena:* actions if the aws:PrincipalARN condition is not like arn:aws:iam::*:role/AnalyticsConsumer. Attach a second SCP to the workloads OU that denies all iam:* actions on the resource arn:aws:iam::*:role/AnalyticsConsumer unless the principal is the AWS CloudFormation StackSets execution role.

Answer

Deploying the AnalyticsConsumer role across the member accounts using AWS CloudFormation StackSets, attaching an SCP that denies Athena access if the principal is not the AnalyticsConsumer role, and attaching another SCP that denies IAM actions on that role unless the caller is the CloudFormation StackSets execution role.
The correct solution involves deploying the role via CloudFormation StackSets to ensure consistency. To enforce the restriction, the first SCP acts as a guardrail by denying Athena access to all principals except the AnalyticsConsumer role. The second SCP secures the AnalyticsConsumer role itself by denying any IAM modifications on the role resource unless performed by the StackSets execution role. This prevents local administrators from bypassing the restriction by deleting or modifying the role, while still allowing central administrators to maintain it.

Step-by-Step Solution

1
Use AWS CloudFormation StackSets to deploy the AnalyticsConsumer role to all member accounts in the workloads OU, ensuring a consistent and centrally managed role configuration.
The AnalyticsConsumer role is successfully created in all target member accounts with the necessary local permissions to run Athena queries.
This establishes a consistent cross-account administrative baseline and decouples role provisioning from local member account control.
2
Attach a Service Control Policy (SCP) to the workloads OU that contains a Deny statement for all athena:* actions with a condition that checks if the aws:PrincipalARN is NOT the AnalyticsConsumer role.
All Athena actions are blocked for all users, groups, and roles in the member accounts, except when assuming the AnalyticsConsumer role.
This establishes the permission guardrail, restricting access to Athena to only the approved role regardless of local administrator status.
3
Attach a second SCP to the workloads OU that denies all iam:* actions targeting the AnalyticsConsumer role resource (arn:aws:iam::*:role/AnalyticsConsumer) unless the calling principal is the central CloudFormation StackSets execution role.
Local administrators are blocked from modifying, deleting, or recreating the AnalyticsConsumer role, while the central StackSets mechanism retains management access.
This prevents local administrators from tampering with the role to bypass the Athena access restriction, solving the principal bypass vector.

Key Concept

Multi-account permission guarding using Service Control Policies (SCPs) combined with centralized identity provisioning.
Question 664Question →

A financial services enterprise is building a new online banking platform deployed across two regions: `us-east-1` and `us-west-2`. The platform consists of a containerized application running on Amazon ECS Fargate and an Amazon Aurora PostgreSQL database. The business requirements specify a Recovery Time Objective (RTO) of 1515 minutes and a Recovery Point Objective (RPO) of 11 minute. The public API layer must serve users with the lowest network latency during normal operations, but automatically redirect users to the other region if a regional outage occurs. Additionally, the application VPCs in both regions need to resolve internal endpoints hosted in a Private Hosted Zone (PHZ) within a shared services VPC. Outbound payment gateway integration requires highly available outbound connectivity in each region. Which architecture design meets these requirements while minimizing single points of failure?

Show answer & explanation

Answer: Configure Route 53 with Latency-based routing records pointing to regional Application Load Balancers, with Route 53 health checks associated with each record. Deploy Application Load Balancers and ECS Fargate tasks across multiple Availability Zones in each region, deploying a NAT Gateway in each Availability Zone. Use Amazon Aurora Global Database for data replication, and associate the shared services Private Hosted Zone with the application VPCs in both regions.

Answer

The architecture utilizing Route 53 Latency-based routing with health checks, multi-AZ deployment with redundant NAT Gateways, Aurora Global Database, and Private Hosted Zone associations meets all criteria.
The configuration using Latency-based routing with health checks, multiple NAT Gateways, Aurora Global Database, and proper Private Hosted Zone association is correct because it ensures that public traffic is routed based on latency with automatic failover, maintains outbound high availability by deploying a NAT Gateway in every Availability Zone, meets the low RTO/RPO targets using Aurora Global Database replication, and enables internal DNS resolution across regional VPC boundaries by associating the Private Hosted Zone.

Step-by-Step Solution

1
Evaluate user routing requirements.
Using Route 53 Latency-based routing with health checks correctly ensures users route to the region with the lowest latency under normal operations and automatically redirect in the event of an outage.
Failover routing only directs traffic to a single active region, which violates the requirement for low-latency routing for all users.
2
Evaluate network path redundancy.
Deploying a NAT Gateway in each Availability Zone provides redundant paths for outbound traffic.
A single NAT Gateway per region is a single point of failure for Fargate tasks in other Availability Zones during an AZ outage.
3
Evaluate cross-VPC private DNS resolution.
Associating the Private Hosted Zone from the shared services VPC with the application VPCs in both regions allows regional Fargate tasks to resolve internal endpoints.
Private Hosted Zones cannot be resolved by default VPC DNS unless explicitly associated with the requesting VPCs.
4
Verify replication strategy and disaster recovery boundaries.
Amazon Aurora Global Database provides sub-second cross-region replication (meeting the 11 minute RPO) and managed failover within minutes (meeting the 1515 minutes RTO).
This strategy satisfies the strict recovery objectives requested by the business scenario.

Key Concept

Designing multi-region disaster recovery setups requires combining latency-sensitive routing with redundant local networking infrastructure, database global replication, and cross-VPC private DNS resource sharing.
Question 665Question →

A digital publishing company wants to establish a cross-region disaster recovery (DR) plan for its archive metadata repository. The repository has a target Recovery Time Objective (RTO) of 12 hours and a Recovery Point Objective (RPO) of 24 hours. The architecture must minimize ongoing infrastructure costs in the secondary Region during normal operations. Which two actions should a solutions architect recommend to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Use AWS Backup to schedule daily backups of the database and copy them to the secondary Region.; Deploy the application's EC2 instances and load balancers using AWS CloudFormation only after a disaster is declared.

Answer

Use AWS Backup to schedule daily backups of the database and copy them to the secondary Region, and deploy the application's EC2 instances and load balancers using AWS CloudFormation only after a disaster is declared.
For a 24-hour RPO, daily database backups are sufficient to ensure that no more than 24 hours of data is lost. For a 12-hour RTO, there is enough time to construct the application infrastructure from scratch. By using AWS Backup to copy daily database backups and using AWS CloudFormation to deploy the compute and network resources only when a disaster occurs, the company can meet its objectives while keeping ongoing idle resource costs in the secondary Region at zero.

Step-by-Step Solution

1
Analyze RTO, RPO, and cost constraints.
The target RTO is 12 hours, target RPO is 24 hours, and ongoing costs must be minimized by avoiding idle resources.
Understanding these boundaries allows the selection of the most cost-effective disaster recovery strategy.
2
Determine the database recovery method that meets the 24-hour RPO.
A backup taken once daily and copied to the secondary Region satisfies the 24-hour RPO.
AWS Backup can schedule and copy backups across Regions, avoiding active replication costs.
3
Determine the infrastructure recovery method that meets the 12-hour RTO.
Using AWS CloudFormation to spin up the infrastructure on-demand meets the 12-hour RTO without running resources in advance.
CloudFormation can provision load balancers and EC2 instances within minutes, which is well within the 12-hour limit.

Key Concept

Selecting the most cost-effective disaster recovery strategy (Backup and Restore) when RTO and RPO limits are lenient enough to avoid active resources.
Question 666Question →

An enterprise is planning to establish a secure multi-account landing zone. The solutions architect needs to migrate several legacy standalone AWS accounts into a new AWS Organizations structure and implement centralized governance. The goals are to enforce strict preventive guardrails, enable centralized security monitoring, and provide federated access. Arrange the following implementation steps in the correct logical sequence to achieve these goals with the minimum window of security vulnerability.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of implementation is first creating the organization and OUs, onboarding the legacy accounts into the organization, delegating security administration to establish monitoring, applying Service Control Policies to enforce guardrails, and finally provisioning federated access using AWS IAM Identity Center.
The correct order follows the principle of secure landing zone setup. First, the organization structure is built. Second, the accounts are enrolled as members. Third, delegated admin and organization-wide security monitoring are turned on to ensure auditing is ready. Fourth, preventive SCPs are attached to OUs to secure the environment. Finally, federated access is provisioned so that users operate under a fully audited and locked-down environment from their very first login.

Step-by-Step Solution

1
Establish AWS Organizations and create OUs
The organizational hierarchy is ready to receive accounts.
A root management account must initiate the organization before any members or structures can exist.
2
Invite and join standalone accounts to the organization
Member accounts are enrolled and grouped into OUs.
Accounts must be organizational members to inherit policies and participate in delegated administration.
3
Configure delegated administration for security monitoring
Centralized auditing is active across all member accounts.
Ensuring visibility and security logging is established before any developer or operator access is allowed.
4
Apply preventive SCPs to OUs
Guardrails are active, preventing unauthorized API calls.
Attaching SCPs before users gain access eliminates the risk of security violations during the initial access window.
5
Provision federated access via AWS IAM Identity Center
Users can log in with permissions regulated by both IAM and SCPs.
Federation is enabled last to ensure all operations are fully governed and monitored from day one.

Key Concept

Multi-Account Governance Bootstrapping Sequence
Question 667Question →

An enterprise-scale organization has structured its AWS multi-account environment with a management account, a core infrastructure account, and multiple Developer and Production member accounts under corresponding Organizational Units (OUs). The Solutions Architect is tasked with implementing a resource sharing, billing optimization, and security audit logging design under the following conditions:
1. Network subnets from the core infrastructure account must be shared with the Production OU to enable decentralized resource deployment, while preventing any resource sharing with external AWS accounts.
2. The organization has purchased a $100/hour Compute Savings Plan at the management account level. To keep development costs representative of standard rates, this Savings Plan's discount must not be applied to any accounts under the Developer OU.
3. AWS CloudTrail logs from all accounts must be stored in a central Amazon S3 bucket within a dedicated Security account. The logs must be encrypted at rest using a key that supports auditing and cross-account policy management.

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

Select all that apply

Show answer & explanation

Answer: Enable resource sharing within AWS Organizations in AWS Resource Access Manager (RAM). In the core infrastructure account, create a resource share for the subnets and share them with the Production OU. In the Management account's Billing Preferences, disable Savings Plans discount sharing for the member accounts under the Developer OU.; In the Security account, create an Amazon S3 bucket encrypted by default with an AWS KMS Customer Managed Key (CMK). Configure the S3 bucket policy to permit the s3:PutObject action from the AWS Organization ID, and modify the CMK key policy to allow the CloudTrail service principal to perform kms:GenerateDataKey* operations.

Answer

Enable resource sharing within AWS Organizations, share subnets with the Production OU using AWS RAM, and disable Savings Plans discount sharing for Developer OU accounts in Billing Preferences. Concurrently, in the Security account, create an S3 bucket with default encryption using a Customer Managed Key (CMK), configure the S3 bucket policy to allow s3:PutObject for the AWS Organization, and configure the KMS key policy to grant key usage to the CloudTrail service principal.
The correct actions involve configuring AWS RAM to share VPC subnets internally within AWS Organizations, disabling Savings Plans discount sharing for Developer OU member accounts in the Billing Preferences of the management account, and utilizing a Customer Managed Key (CMK) with a permissive key policy for secure cross-account CloudTrail log encryption in a central S3 bucket.

Step-by-Step Solution

1
Configure VPC subnet sharing using AWS Resource Access Manager (RAM).
Subnets are shared from the Central Infrastructure account with the Production OU without enabling external sharing.
This satisfies the requirement to share subnets centrally and securely within the Organization.
2
Restrict Savings Plans application to the Production accounts.
Savings Plans discount sharing is disabled for the accounts under the Developer OU in the Management account's Billing Preferences.
This prevents the Compute Savings Plan from applying to Developer accounts, preserving their normal pricing structure for accurate budget tracking.
3
Configure centralized S3 logging with cross-account KMS encryption.
An S3 bucket is created in the Security account using a Customer Managed Key (CMK) for default encryption. The S3 bucket policy allows s3:PutObject from the Organization, and the KMS key policy grants kms:GenerateDataKey* to the CloudTrail service principal.
This enables secure, encrypted cross-account log delivery. AWS managed keys (aws/s3) cannot be used because their policies cannot be customized to allow cross-account operations.

Key Concept

Multi-account resource sharing, billing isolation preferences, and cross-account KMS encryption keys within an AWS Organization.
Question 668Question →

A digital media platform is designing a network architecture to connect 1010 spoke VPCs in a single AWS Region. The architecture must enable these VPCs to communicate with one another for database replication and share a centralized egress point for internet traffic. Additionally, all VPCs must have access to a shared on-premises development server via an existing AWS Direct Connect connection. The provider wants to minimize the number of point-to-point connections and simplify routing management.

Which solution should a solutions architect recommend?

Show answer & explanation

Answer: Deploy an AWS Transit Gateway to interconnect all spoke VPCs. Create a centralized egress VPC containing a redundant NAT Gateway pool and attach it to the Transit Gateway. Connect the Transit Gateway to an AWS Direct Connect Gateway that is associated with the on-premises Direct Connect connection. Configure Transit Gateway route tables to route inter-spoke traffic, on-premises traffic, and internet-bound traffic to their respective attachments.

Answer

Deploy an AWS Transit Gateway to interconnect all spoke VPCs, create a centralized egress VPC with a NAT Gateway pool, and associate the Transit Gateway with a Direct Connect Gateway for hybrid connectivity.
The correct solution uses AWS Transit Gateway to establish a hub-and-spoke topology, which supports transitive routing between all attached spoke VPCs and a centralized egress VPC containing NAT Gateways. It also associates the Transit Gateway with a Direct Connect Gateway to enable on-premises connectivity for all spokes. This minimizes administrative overhead and scales efficiently.

Step-by-Step Solution

1
Interconnect the VPCs using a hub-and-spoke model.
Deploy an AWS Transit Gateway and attach all 10 spoke VPCs to it. This enables full mesh transitive routing between all spokes while keeping connections to a minimum.
Transit Gateway natively supports routing traffic between attached VPCs without requiring point-to-point peering connections.
2
Establish the hybrid network connection to the on-premises environment.
Connect the Transit Gateway to an AWS Direct Connect Gateway (DXGW) associated with the on-premises Direct Connect virtual interface.
Direct Connect Gateway supports attaching to Transit Gateways across accounts and regions, enabling all attached spoke VPCs to route traffic to the on-premises network.
3
Centralize internet egress traffic.
Deploy a dedicated egress VPC with NAT Gateways in multiple Availability Zones, attach this VPC to the Transit Gateway, and configure the route tables of the spoke VPCs to point default route (0.0.0.0/0) traffic to the Transit Gateway.
This centralizes public egress management, reduces the cost of maintaining NAT Gateways in every spoke VPC, and avoids the transitive routing limitations of VPC Peering.

Key Concept

AWS Transit Gateway transitive routing and hybrid connectivity limits
Question 669Question →

A company is designing a new reporting application that serves over 5 million5\text{ million} PDF reports (totaling 10 TB10\text{ TB} of static data) stored in an Amazon S3 bucket. The application also queries daily transaction summaries from an Amazon RDS for MySQL database which experiences over 100,000100,000 read queries per hour during business hours. During testing, users experience high latency when loading the reports and running dashboard queries. Additionally, a marketing campaign is scheduled that will cause a sudden, massive spike in traffic to the application's Application Load Balancer (ALB), going from 50 requests per second50\text{ requests per second} to 80,000 requests per second80,000\text{ requests per second} within 1 minute1\text{ minute}. Which combination of actions should a Solutions Architect recommend to optimize the performance and scalability of the application? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Deploy Amazon CloudFront to cache the static PDF reports from the Amazon S3 bucket at edge locations.; Create Amazon RDS read replicas and configure the application to direct read queries for the dashboard to the read replica endpoints.

Answer

Deploying Amazon CloudFront to cache the static PDF reports from the S3 bucket and creating Amazon RDS read replicas to offload read traffic from the primary database.
Deploying Amazon CloudFront reduces latency for static content by caching it closer to users. Creating RDS read replicas offloads read traffic from the primary DB instance, scaling the read workload. Amazon RDS standby instances in a Multi-AZ deployment do not support read traffic. Application Load Balancers cannot scale instantly to absorb a spike from 50 requests per second50\text{ requests per second} to 80,000 requests per second80,000\text{ requests per second} and require pre-warming. ElastiCache for Memcached does not support multi-AZ replication.

Step-by-Step Solution

1
Analyze static content performance requirements and locate the optimal caching layer.
Identify that PDF reports are static files stored in S3, which should be cached at edge locations using Amazon CloudFront to reduce retrieval latency and S3 get request costs.
Caching static objects close to the users reduces latency and load on the origin storage tier.
2
Analyze database workload pattern and identify methods to scale query execution.
Identify that dashboard summaries represent read-heavy queries that can be offloaded to Amazon RDS read replicas.
Separating read queries from write transactions allows horizontal scaling of the database tier.
3
Evaluate options for load balancer scaling during the scheduled marketing campaign spike.
Identify that relying solely on automatic scaling triggers for a sudden jump to 80,000 requests per second80,000\text{ requests per second} is insufficient because ALBs scale gradually. The ALB must be pre-warmed.
Preventing connection timeouts and failure during instantaneous, massive traffic spikes requires pre-warming the ALB.

Key Concept

Caching static assets and offloading database read traffic are fundamental optimization strategies for web applications. Caching at edge locations using CloudFront reduces load on S3 and minimizes download latency, while RDS read replicas scale read operations horizontally. Standby RDS instances are not readable, ALBs require pre-warming for sudden large spikes, and Memcached lacks multi-AZ replication capabilities.
Estimated Time:2m 0s
Question 670Question →

A biotechnology research corporation is migrating its workflows to AWS using AWS Organizations. The central network topology consists of a Network Services VPC hosted in a shared infrastructure account, connected to several Research and Development (R&D) VPCs in different member accounts via an AWS Transit Gateway. The on-premises data center connects to the Transit Gateway via an AWS Direct Connect gateway connection. A Route 53 Private Hosted Zone (PHZ) for aws.biotech.internal is created in the Network Services account and associated with the Network Services VPC. The R&D VPCs must be able to resolve domain names inside aws.biotech.internal. Additionally, all R&D VPCs must resolve on-premises domain names in the corp.biotech.internal namespace. Which TWO configurations must a Solutions Architect implement to achieve this DNS resolution strategy? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Authorize the association of the aws.biotech.internal Private Hosted Zone with the R&D VPCs from the Network Services account, and then associate the R&D VPCs with the hosted zone from each member account.; Create a Route 53 Resolver outbound endpoint in the Network Services VPC, configure an outbound forwarding rule for corp.biotech.internal pointing to the on-premises DNS servers, share this rule with the organization using AWS Resource Access Manager (RAM), and associate the rule with the R&D VPCs.

Answer

To establish hybrid and cross-account DNS resolution, the Solutions Architect must authorize and associate the private hosted zone cross-account, and configure a Route 53 Resolver outbound endpoint with a shared forwarding rule.
The correct options implement a standard hybrid DNS pattern. Cross-account Private Hosted Zones are associated using Route 53 VPC association authorization, and on-premises resolution is achieved by using a centralized outbound Route 53 Resolver endpoint and sharing the resolver forwarding rules across the AWS Organization using AWS Resource Access Manager (RAM).

Step-by-Step Solution

1
Authorize cross-account association of the Private Hosted Zone.
The Network Services account creates an association authorization for each R&D VPC.
This allows the member accounts to associate their VPCs with a Private Hosted Zone owned by a different account.
2
Associate the R&D VPCs with the Private Hosted Zone.
Each R&D VPC is associated with the aws.biotech.internal hosted zone.
This enables DNS resolution of internal AWS resources directly within the spoke VPCs.
3
Set up centralized Route 53 Resolver outbound endpoints and rules.
An outbound endpoint is created in the central VPC, and a forwarding rule for the on-premises namespace is shared via AWS RAM.
This routes all DNS queries for the on-premises domain from R&D VPCs through the Transit Gateway to the on-premises DNS servers.

Key Concept

Cross-account Private Hosted Zone sharing and hybrid name resolution using Route 53 Resolver outbound endpoints and AWS RAM.
Question 671Question →

A healthcare provider is launching a new medical telemetry streaming application across two AWS Regions: us-east-1 (primary) and us-west-2 (secondary). The application requires outbound internet connectivity to verify patient insurance APIs and uses Amazon Route 53 for external DNS. The workload is deployed on Amazon ECS (Fargate) across multiple Availability Zones in each region and uses an Amazon Aurora PostgreSQL database. The business has specified a Recovery Time Objective (RTO) of 1515 minutes and a Recovery Point Objective (RPO) of 22 minutes. Internal microservices communicate using private DNS names managed via a Route 53 Private Hosted Zone. Which of the following disaster recovery and high availability architectures should a solutions architect recommend to meet these requirements?

Show answer & explanation

Answer: Design an Active-Passive Warm Standby disaster recovery strategy. Configure an Amazon Aurora Global Database to replicate data from us-east-1 to us-west-2. Deploy the ECS tasks across multiple Availability Zones in both regions, keeping the tasks in the secondary region scaled to a minimum capacity. In both regions, deploy redundant NAT Gateways across all used Availability Zones. Associate the Route 53 Private Hosted Zone with the VPCs in both regions. Configure Route 53 Failover routing with active health checks to manage external traffic routing.

Answer

The correct strategy is to implement an Active-Passive Warm Standby disaster recovery setup using Aurora Global Database, multi-AZ redundant NAT Gateways, Route 53 Private Hosted Zone associations across both VPCs, and Route 53 Failover routing.
The correct architecture uses an Active-Passive Warm Standby strategy. Aurora Global Database ensures near-real-time cross-region replication to satisfy the 2-minute RPO. Scaling down ECS tasks instead of keeping them offline satisfies the 15-minute RTO since scaling up takes less time than bootstrapping from scratch. Associating the Private Hosted Zone with both VPCs guarantees internal DNS resolution functions after failover. Deploying redundant NAT Gateways ensures outbound internet connectivity remains highly available across all Availability Zones.

Step-by-Step Solution

1
Evaluate the RTO and RPO requirements.
An RPO of 2 minutes requires synchronous or near-synchronous replication. Aurora Global Database cross-region replication latency is typically under 1 second, fulfilling the RPO constraint. An RTO of 15 minutes is easily met by a Warm Standby strategy where the recovery infrastructure is online but scaled down, as scaling up ECS tasks and promoting the Aurora secondary cluster takes only a few minutes.
Choosing the appropriate DR pattern (Warm Standby vs. Pilot Light) ensures both RTO and RPO are satisfied.
2
Ensure internal DNS resolution works across regions during a failover.
Associate the Route 53 Private Hosted Zone (PHZ) with the VPCs in both us-east-1 and us-west-2.
Route 53 Private Hosted Zones must be explicitly associated with every VPC that requires resolution of those private DNS names.
3
Design highly available outbound network paths.
Deploy a dedicated NAT Gateway in each Availability Zone where ECS tasks are running.
A single NAT Gateway creates a single point of failure for outbound traffic, violating standard high availability requirements.

Key Concept

Disaster Recovery pattern selection based on RTO/RPO, combined with multi-region network and DNS integration.
Estimated Time:2m 0s
Question 672Question →

A multinational smart grid operator manages its infrastructure using AWS Organizations. The network topology consists of a central Hub VPC in a Network Services account and several spoke VPCs in separate production accounts. The spoke VPCs are connected to the Hub VPC via an AWS Transit Gateway. The on-premises grid operations center is connected to the Hub VPC via an AWS Direct Connect connection terminated at a Direct Connect Gateway. The on-premises environment hosts telemetry servers resolved by a local DNS server zone grid.local. The AWS environment hosts microservices that need to resolve names in the grid.local domain, and the on-premises servers must resolve services in a Route 53 Private Hosted Zone (PHZ) named aws.grid.internal hosted in a Shared Services account. To minimize latency and avoid single points of failure, the operator requires a scalable, highly available, and secure DNS resolution strategy across all environments. Which TWO actions should a Solutions Architect take to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: In the Shared Services account, authorize the association of the aws.grid.internal private hosted zone with the Hub VPC and each spoke VPC. In the respective accounts containing the Hub and spoke VPCs, associate the VPCs with the private hosted zone.; Deploy Route 53 Resolver inbound endpoints in the Hub VPC, and configure the on-premises DNS servers to forward queries for aws.grid.internal to these inbound endpoint IP addresses. Deploy Route 53 Resolver outbound endpoints in the Hub VPC, create a Resolver rule for grid.local pointing to the on-premises DNS servers, share this rule via AWS Resource Access Manager with the organization, and associate it with all spoke VPCs.

Answer

The correct actions are to authorize the cross-account association of the private hosted zone in the Shared Services account and perform the association in the respective VPC accounts, while deploying Route 53 Resolver inbound/outbound endpoints in the hub VPC, sharing the outbound rule via AWS Resource Access Manager (RAM), and configuring on-premises DNS forwarding.
The correct actions configure secure cross-account hosted zone resolution and hybrid DNS forwarding. First, because the Private Hosted Zone is owned by the Shared Services account, it must be associated with the Hub and spoke VPCs using the Route 53 cross-account authorization and association process. Second, hybrid resolution is achieved by placing inbound and outbound Route 53 Resolver endpoints in the Hub VPC, forwarding on-premises queries to the inbound endpoints, and sharing the outbound Resolver forwarding rule via AWS RAM with the spoke VPCs to allow them to resolve on-premises domains.

Step-by-Step Solution

1
Set up cross-account Private Hosted Zone association by running 'aws route53 create-vpc-association-authorization' in the Shared Services account for the Hub and spoke VPCs, and then running 'aws route53 associate-vpc-with-private-hosted-zone' in the respective Hub and spoke accounts.
The aws.grid.internal zone is resolvable by the Route 53 Resolver (.2 IP) in both the Hub and spoke VPCs.
This establishes cross-account private DNS resolution within AWS without using RAM, which does not support PHZs.
2
Create Route 53 Resolver inbound endpoints in the Hub VPC across multiple availability zones and point on-premises DNS forwarders for aws.grid.internal to these inbound IPs.
On-premises clients can resolve AWS internal resources over Direct Connect.
This provides a highly available entry point for on-premises DNS queries entering the AWS network.
3
Create Route 53 Resolver outbound endpoints in the Hub VPC, configure a forwarding rule for grid.local pointing to the on-premises DNS servers, share this rule via AWS RAM with the AWS Organization, and associate it with the spoke VPCs.
AWS spoke resources can resolve grid.local domains by routing queries through the outbound endpoints to the on-premises DNS servers.
This centralizes outbound DNS resolution, reduces endpoint costs by sharing a single outbound rule, and enables bidirectional resolution.

Key Concept

Centralized hybrid DNS architecture requires using Route 53 Resolver inbound and outbound endpoints in a hub VPC to interface with on-premises DNS, using AWS Resource Access Manager to share the outbound forwarding rules with spoke accounts, and utilizing cross-account PHZ association authorizations for internal VPC resolution.
Estimated Time:3m 0s
Question 673Question →

A technology cooperative is establishing a shared services platform across multiple AWS accounts within an AWS Organization. The cooperative wants to create a shared VPC in a central Infrastructure account to host application load balancers and share subnets with regional application accounts. Additionally, they plan to purchase a single Savings Plan from the billing management account that applies to Amazon EC2 and AWS Fargate usage across all member accounts. The cooperative also wants to ensure that any individual member account can be excluded from sharing the unused Savings Plans capacity if required. Which TWO actions should the solutions architect take to implement this strategy? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: From the central Infrastructure account, use AWS Resource Access Manager (RAM) to create a resource share for the specific VPC subnets, sharing them with the organizational units (OUs) that contain the regional application accounts.; Purchase Compute Savings Plans in the billing management account, and configure the discount sharing preferences in the management account's billing console to exclude specific member accounts that prefer not to share their discount capacity.

Answer

The correct actions are to use AWS Resource Access Manager (RAM) to share the specific subnets from the Infrastructure account with the application OUs, and to purchase Compute Savings Plans in the management account while configuring discount sharing exclusions for specific member accounts in the billing console.
The correct architecture involves sharing subnets via AWS Resource Access Manager (RAM) to allow member accounts to deploy resources within a centralized VPC, and purchasing Compute Savings Plans in the management account while configuring discount sharing settings to exclude specific member accounts that wish to opt out.

Step-by-Step Solution

1
Select the correct resource sharing mechanism for multi-account networking.
Identify that subnets (not the entire VPC) must be shared via AWS Resource Access Manager (RAM) with the destination OUs.
AWS RAM supports sharing subnets, allowing resources in other accounts to be launched into the shared subnet while keeping VPC administration centralized.
2
Select the appropriate Savings Plan type to cover both EC2 and Fargate.
Determine that Compute Savings Plans must be purchased because they apply to both EC2 and Fargate, unlike EC2 Instance Savings Plans which only cover EC2.
Meeting the requirement to apply discounts to both compute types requires a plan that covers Fargate.
3
Configure discount sharing preferences in the management account.
Adjust the Billing Preferences in the management account to disable discount sharing for specific member accounts.
By default, Savings Plans benefits are shared across all accounts in the organization, but the management account can selectively disable sharing for specific accounts.

Key Concept

AWS RAM Subnet Sharing and Savings Plans Discount Customization in Multi-Account Organizations
Estimated Time:2m 0s
Question 674Question →

A multinational financial services company uses AWS Organizations with 400 member accounts. The security team is designing a centralized monitoring and auditing solution. They require all regional AWS CloudTrail logs to be aggregated into a single Amazon S3 bucket within a dedicated Log Archive account. The logs must be encrypted at rest using a customer managed KMS key. The configuration must enforce least privilege, prevent unauthorized modification of trails within member accounts, and ensure uninterrupted log delivery. Which combination of S3 bucket policy, KMS key configuration, and Service Control Policy (SCP) satisfies these requirements while preventing log delivery failures?

Show answer & explanation

Answer: Deploy an AWS Organizations organization trail in the management account that logs to a central Amazon S3 bucket in the Log Archive account. In the Log Archive account, configure a customer managed KMS key with a key policy that allows the cloudtrail.amazonaws.com service principal to execute kms:GenerateDataKey* and kms:DescribeKey with a condition restricting the source ARN to the trail. Update the S3 bucket policy to grant s3:PutObject permissions to the cloudtrail.amazonaws.com service principal with a condition on aws:PrincipalOrgID. Apply a Service Control Policy (SCP) at the organization root that denies cloudtrail:StopLogging, cloudtrail:UpdateTrail, and cloudtrail:DeleteTrail actions.

Answer

The correct solution deploys an organization trail in the management account delivering logs to a central S3 bucket in the Log Archive account. The Log Archive account uses a customer managed KMS key with key policies permitting the CloudTrail service principal to generate data keys and describe the key, scoped to the trail's ARN. The S3 bucket policy permits the CloudTrail service principal to write objects scoped by the organization ID. Lastly, a Service Control Policy restricts member accounts from modifying or stopping CloudTrail logging.
The correct solution properly aligns cross-account S3 bucket policies and customer managed KMS key policies to trust the CloudTrail service principal (cloudtrail.amazonaws.com) using the organization's ID and trail ARN as conditions. It also leverages an SCP as a preventive guardrail to enforce logging integrity without misinterpreting it as an access-granting policy.

Step-by-Step Solution

1
Deploy an organization-wide trail in the AWS Organizations management account.
Logs from all accounts within the organization are automatically collected and aggregated.
This centralizes auditing without requiring local configurations in each individual member account.
2
Configure the S3 bucket policy in the Log Archive account to permit writes from the CloudTrail service principal.
The bucket policy allows cloudtrail.amazonaws.com to execute s3:PutObject, restricted to the organization ID.
Ensures that cross-account CloudTrail log delivery is permitted only for accounts within the specified AWS Organization.
3
Create and configure a customer managed KMS key policy in the Log Archive account.
The key policy allows the CloudTrail service principal to perform kms:GenerateDataKey* and kms:DescribeKey with an aws:SourceArn condition.
Allows CloudTrail to encrypt the logs before writing them to S3. AWS-managed keys cannot be shared cross-account, necessitating a customer managed key.
4
Apply a Service Control Policy (SCP) at the organization root.
Actions like cloudtrail:StopLogging, cloudtrail:UpdateTrail, and cloudtrail:DeleteTrail are denied for all member accounts.
Prevents member account administrators from tampering with or disabling the centralized audit logging.

Key Concept

Centralized cross-account logging requires resource-based policy alignment (S3 bucket policy and KMS key policy) allowing the service principal, while SCPs enforce logging compliance at the organization boundary.
Estimated Time:3m 0s
Question 675Question →

An organization is designing a disaster recovery (DR) strategy for an internal reporting application. The application is non-critical, and the business has set both the Recovery Time Objective (RTO) and the Recovery Point Objective (RPO) to 24 hours. The primary objective of the design is to minimize ongoing running costs. Which disaster recovery strategy should the solutions architect recommend to meet these requirements?

Show answer & explanation

Answer: Backup and Restore strategy by taking daily snapshots of the database and application data, storing them in Amazon S3, and recreating the resources only when a disaster occurs.

Answer

Backup and Restore strategy by taking daily snapshots of the database and application data, storing them in Amazon S3, and recreating the resources only when a disaster occurs.
A Backup and Restore strategy is the most cost-effective option because it does not require running active infrastructure in a secondary region under normal operations. Backups can be scheduled daily to satisfy the 24-hour RPO, and the infrastructure can be provisioned on-demand (e.g., using CloudFormation or Terraform) to restore the application within the 24-hour RTO limit.

Step-by-Step Solution

1
Analyze the RTO and RPO requirements.
The target recovery time (RTO) is 24 hours, and the allowed data loss window (RPO) is 24 hours.
This determines which DR strategy is technically viable. High availability or active replication is not required for a 24-hour window.
2
Evaluate the cost constraint.
Ongoing running costs must be minimized.
This rules out active-passive or active-active strategies that require running compute or database instances in a secondary region continuously.
3
Select the matching DR strategy.
Backup and Restore is selected since backups can be taken daily (RPO = 24 hours) and restored within 24 hours (RTO = 24 hours) without running standby resources.
It achieves the lowest possible cost by keeping no resources running in the secondary region until a disaster is declared.

Key Concept

Disaster Recovery strategies trade off RTO/RPO against cost, where Backup & Restore has the lowest cost and highest RTO/RPO.
Estimated Time:45s
Question 676Question →

A global financial technology enterprise uses AWS Organizations to manage over 100 accounts. The security engineering team is implementing a strict data classification and encryption compliance strategy. The primary requirement is that all sensitive transactional data stored in Amazon S3 buckets within the "Workloads" Organizational Unit (OU) must be encrypted using AWS KMS Customer Managed Keys (CMKs) created and managed centrally inside a dedicated "Security" account. Additionally, any direct uploads to these buckets must be blocked if they do not explicitly request encryption using the central CMKs, while preventing member account administrators from altering these baseline encryption constraints. Which of the following actions should the Solutions Architect recommend to achieve this governance policy? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: In the Workloads OU, attach a Service Control Policy (SCP) that denies the s3:PutObject action if the request condition s3:x-amz-server-side-encryption-aws-kms-key-id does not match the ARN of the central Customer Managed Key (CMK), or if the s3:x-amz-server-side-encryption header is not set to aws:kms.; In the centralized Security account, configure the key policy of the Customer Managed Key (CMK) to grant kms:GenerateDataKey and kms:Decrypt permissions to the organization's member accounts, utilizing the aws:PrincipalOrgID condition to restrict access.

Answer

In the Workloads OU, attach a Service Control Policy (SCP) that denies s3:PutObject if it does not specify the centralized Customer Managed Key (CMK) or aws:kms encryption, and in the Security account, configure the key policy of the CMK to allow kms:GenerateDataKey and kms:Decrypt permissions to the organization's member accounts using the aws:PrincipalOrgID condition.
To centrally govern S3 encryption, an SCP must conditionally deny object uploads unless they request SSE-KMS encryption with the specific Customer Managed Key (CMK) ARN from the central Security account. Simultaneously, the central CMK key policy must be modified to permit member account principals (scoped securely via the organization ID condition) to use the key for encrypting and decrypting data.

Step-by-Step Solution

1
Analyze the encryption and control requirements.
Identify that data must be encrypted with a centralized CMK in the Security account, and unauthorized uploads must be blocked at the organization level.
This establishes that we need cross-account key sharing and organizational guardrails.
2
Determine the mechanism to enforce the key usage on upload.
Identify that an SCP attached to the Workloads OU can inspect request headers during s3:PutObject and deny the action if the target key ARN or the encryption type does not match the central CMK.
SCPs act as organizational guardrails that can conditionally deny non-compliant actions across all member accounts.
3
Address key permissions for cross-account access.
Understand that the centralized Customer Managed Key (CMK) policy must be modified to allow member accounts to use it, and use aws:PrincipalOrgID to dynamically target all accounts in the organization.
By default, KMS keys are only usable within their host account, and AWS-managed keys cannot support cross-account sharing.
4
Evaluate the viability of AWS Resource Access Manager (RAM).
Discard RAM because it does not support sharing S3 buckets or KMS keys.
Understanding the limits of RAM avoids invalid architecture configurations.

Key Concept

Cross-account KMS key sharing and SCP conditional enforcement for S3 encryption
Estimated Time:3m 0s
Question 677Question →

A company is implementing a multi-account governance framework using AWS Organizations and AWS Control Tower. The solutions architect needs to onboard an existing standalone AWS account that hosts a legacy production workload into the organization. The landing zone must apply the standard enterprise security baselines and detective guardrails without disrupting the legacy workload.

What is the correct sequence of steps to successfully onboard and govern this existing account using AWS Control Tower?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order to onboard the existing standalone account is: first, send the organization invitation from the management account; second, accept the invitation from the standalone account; third, move the joined account to a registered organizational unit (OU); and fourth, enroll the account in AWS Control Tower.
The correct sequence begins with initiating the invite from the management account, followed by accepting it in the member account. Next, the member account must be moved to an Organizational Unit that is registered with AWS Control Tower, and finally, the account is enrolled to apply the standard baselines and policies.

Step-by-Step Solution

1
Invite the standalone account to the Organization.
The invitation is pending and visible in the standalone account.
Before managing the account, it must become a member of the AWS Organization.
2
Accept the invitation in the standalone account.
The standalone account becomes a member account under the Root OU.
The owner of the standalone account must approve the join request to delegate billing and management.
3
Move the account to an OU registered with AWS Control Tower.
The account is positioned within the governance scope of AWS Control Tower.
AWS Control Tower manages accounts that reside in registered OUs.
4
Enroll the account in AWS Control Tower.
Baseline guardrails, Service Control Policies, and StackSets are deployed to the account.
This step applies the security posture and governance baseline without recreating the account.

Key Concept

Onboarding existing accounts into AWS Control Tower requires first making them part of the AWS Organization, placing them in a registered OU, and then executing the enrollment process.
Question 678Question →

A company manages its multi-account environment using AWS Organizations with consolidated billing. The infrastructure team has created a shared VPC in a central Network account and wants to share its subnets with a newly acquired subsidiary account. The finance team requires that the subsidiary's usage be calculated with a 10% markup for internal chargeback reporting, while the actual AWS invoice paid by the management account remains unchanged. The subsidiary account is not yet a member of the AWS Organization. Which of the following strategies should a solutions architect implement to meet these requirements?

Show answer & explanation

Answer: Invite the subsidiary account to join the AWS Organization. Enable resource sharing within the organization in AWS Resource Access Manager (RAM), create a resource share for the subnets in the Network account, and associate the subsidiary account as a principal. In AWS Billing Conductor, create a billing group containing the subsidiary account, create a custom pricing plan with a pricing rule that applies a 10% markup, and associate the plan with the billing group.

Answer

Invite the subsidiary account to join the AWS Organization, enable organization resource sharing in AWS RAM to share the subnets, and use AWS Billing Conductor to configure a billing group with a custom pricing plan and a 10% markup pricing rule.
The correct strategy requires first inviting the subsidiary account to the AWS Organization because AWS Billing Conductor can only manage billing groups for accounts within the same consolidated billing family. Once the account is in the organization, AWS Resource Access Manager (RAM) can share the subnets directly with the account ID (or its OU) without requiring invitation acceptance, provided organization sharing is enabled. Finally, AWS Billing Conductor is used to group the subsidiary account and apply a custom pricing plan with a pricing rule containing a 10% markup, which satisfies the custom chargeback reporting requirement while leaving the management account's actual AWS invoice unchanged.

Step-by-Step Solution

1
Invite the subsidiary account to the AWS Organization.
The subsidiary account joins the consolidated billing family.
AWS Billing Conductor billing groups only support accounts that belong to the same consolidated billing family.
2
Configure AWS RAM to share subnets from the Network account to the subsidiary account.
The subnets are shared and automatically accepted by the subsidiary account.
Enabling sharing within the AWS Organization allows automatic acceptance of RAM resource shares without manual invitations.
3
Configure AWS Billing Conductor with a billing group, custom pricing plan, and pricing rule.
The subsidiary's billing reports reflect a 10% markup on usage without changing the root consolidated invoice.
AWS Billing Conductor allows the creation of pro forma billing data for specific accounts using custom pricing rules.

Key Concept

AWS Billing Conductor manages custom billing rules for accounts within an AWS Organization, while AWS RAM enables cross-account resource sharing with differences in validation between internal and external accounts.
Question 679Question →

An enterprise is designing a multi-account AWS environment utilizing AWS Organizations. The enterprise has a corporate identity provider (IdP) that supports SAML 2.0. Users in the IdP must be able to authenticate and gain access to resources across multiple AWS member accounts based on their department attributes. The security architect wants to configure direct federation to the member accounts using IAM SAML Identity Providers and IAM Roles. To enforce centralized security, a Service Control Policy (SCP) is applied at the root of the organization. During implementation, users are unable to authenticate and receive access denied errors. Which TWO configuration steps are required to establish the trust relationship and resolve the authentication failures? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure an IAM SAML identity provider in each target member account, and create a federated IAM role in each member account with a trust policy that allows the 'sts:AssumeRoleWithSAML' action for the local SAML provider principal.; Configure the corporate SAML Identity Provider to send assertions containing the 'https://aws.amazon.com/SAML/Attributes/Role' attribute, specifying the comma-separated ARNs of the target IAM role and the local SAML provider in the member account.

Answer

To establish direct SAML 2.0 federation to AWS member accounts, you must configure an IAM SAML identity provider in each target member account with a corresponding role whose trust policy allows the 'sts:AssumeRoleWithSAML' action. Additionally, the corporate IdP must be configured to pass SAML assertions containing the 'https://aws.amazon.com/SAML/Attributes/Role' attribute, containing the comma-separated ARNs of the target IAM role and the local SAML provider.
The correct configurations involve setting up an IAM SAML identity provider in each target member account, assigning a federated IAM role with a trust policy using the 'sts:AssumeRoleWithSAML' action, and configuring the corporate IdP to pass the required SAML attributes, specifically the role and provider ARNs in the 'https://aws.amazon.com/SAML/Attributes/Role' attribute.

Step-by-Step Solution

1
Configure an IAM SAML identity provider in each target member account.
Establishes a trust relationship between AWS and the corporate IdP within each target account.
SAML federation is account-specific, and the SAML provider metadata must reside in the account containing the federated role.
2
Configure the trust policy of the IAM roles in the member accounts.
Allows the federated principal to assume the role.
The trust policy must specify the SAML provider ARN as the principal and allow the 'sts:AssumeRoleWithSAML' action.
3
Configure the corporate IdP to pass the correct SAML attributes.
AWS receives the mapping of the user's role and provider.
AWS STS requires the 'https://aws.amazon.com/SAML/Attributes/Role' attribute to match the incoming request to the target role.

Key Concept

Direct SAML 2.0 Identity Federation in a Multi-Account AWS Organization
Question 680Question →

A global retail corporation is migrating its legacy inventory management systems to AWS. The target architecture spans 6060 spoke VPCs distributed equally between `us-east-1` and `us-west-2` across separate member accounts under AWS Organizations. The corporation has established two AWS Direct Connect connections at separate colocation facilities to link their on-premises core datacenter to AWS. Workloads within the same Region require high-bandwidth, low-latency inter-VPC communication. However, security policy forbids direct inter-VPC traffic across different AWS Regions. The hybrid connectivity design must ensure that on-premises database synchronization occurs primarily over the Direct Connect path, with an IPsec VPN tunnel acting as an automated secondary failover route. Which TWO actions must a solutions architect take to configure this hybrid and multi-account network topology?

Select all that apply

Show answer & explanation

Answer: Provision an AWS Transit Gateway in each Region, attach the regional spoke VPCs to it, and associate both Transit Gateways with a single Direct Connect Gateway that connects to the on-premises datacenter using Transit Virtual Interfaces.; Configure an AWS Site-to-Site VPN connection terminating on each Transit Gateway as a backup path, using Border Gateway Protocol (BGP) with AS Path prepending on the on-premises router for the VPN routes to ensure Direct Connect is preferred.

Answer

To establish the required architecture, the solutions architect must deploy an AWS Transit Gateway in each Region to connect local spoke VPCs, associate both Transit Gateways with a single Direct Connect Gateway via Transit VIFs, and establish backup AWS Site-to-Site VPN connections terminating on the Transit Gateways using BGP routing with AS Path prepending to prefer the Direct Connect path.
To build a scalable and resilient multi-account hybrid topology, a Solutions Architect should leverage AWS Transit Gateway as a regional router to consolidate VPC attachments. A single Direct Connect Gateway can associate with up to three Transit Gateways using Transit Virtual Interfaces (Transit VIFs), solving the scaling limitation of Direct Connect Gateway to VGW associations (which is capped at 1010). To establish a backup path, Site-to-Site VPN connections can be terminated on the same Transit Gateways. By running dynamic BGP routing and prepending the AS path on the VPN advertisements, the Direct Connect path is preferred due to its shorter AS path length. This configuration ensures automatic failover to the VPN only if the Direct Connect connections become unavailable.

Step-by-Step Solution

1
Select the correct regional hubs to scale inter-VPC communication for the 6060 spoke VPCs.
Provision an AWS Transit Gateway in `us-east-1` and another in `us-west-2`, attaching the local 3030 spoke VPCs to their respective regional Transit Gateway.
This scales inter-VPC routing within each region under a hub-and-spoke model, avoiding the 1010-association limit of Direct Connect Gateway to VGWs and the overhead of a full VPC peering mesh.
2
Configure hybrid connectivity to the on-premises datacenter via Direct Connect.
Associate both regional Transit Gateways with a single Direct Connect Gateway utilizing Transit Virtual Interfaces (Transit VIFs).
A Transit VIF is required to carry traffic between a Direct Connect Gateway and a Transit Gateway, allowing multiple regional Transit Gateways to share the same hybrid connection.
3
Establish the backup hybrid path and configure active/passive routing preferences.
Deploy AWS Site-to-Site VPN connections terminating on each Transit Gateway. Configure BGP dynamic routing, and prepend the AS path on the VPN connection from the customer gateway.
Dynamic routing with BGP allows for automated failover. Prepending the AS path on the VPN path ensures AWS prefers the Direct Connect path because it presents a shorter BGP AS path.

Key Concept

Hybrid and Multi-Account Network Connectivity Design
PreviousPage 34 / 99Next
All practice questions — AWS Certified Solutions Architect - Professional | Examkin