Tüm alıştırma soruları

1964 soru

Tüm türler1,964 Çoktan seçmeli1,006 Çoklu seçim931 Sıralama27

A development team is deploying a new version of an API to Amazon EC2 instances behind an Application Load Balancer. To minimize update risk, the team wants to route $10\%$ of traffic to the new version while keeping $90\%$ on the existing version. They plan to monitor the new version for $10$ minutes, and then immediately route all remaining traffic to the new version if no errors occur. If any alarms are triggered during the monitoring period, the deployment must roll back instantly without affecting the traffic on the existing version. Which deployment configuration best meets these requirements?

A canary deployment configuration that shifts

10\%

of traffic to the new version, waits for

10

minutes, and then shifts the remaining

90\%

of traffic.

A linear deployment configuration that shifts traffic in equal

10\%

increments every minute until

100\%

of traffic is routed to the new version.

An in-place rolling deployment that updates a batch of the existing EC2 instances at a time.

An all-at-once deployment configuration that shifts

100\%

of traffic to the new version immediately.

Cevabı ve açıklamayı göster

Cevap: A canary deployment configuration that shifts $10\%$ of traffic to the new version, waits for $10$ minutes, and then shifts the remaining $90\%$ of traffic.

Cevap

A canary deployment configuration that shifts

10\%

of traffic to the new version, waits for

10

minutes, and then shifts the remaining

90\%

of traffic.

A canary deployment strategy matches the requirement by routing a small portion (

10\%

) of traffic to the new version, maintaining that level for a

10

-minute observation period, and then routing the remaining

90\%

of traffic. If alarms trigger, CodeDeploy can automatically and instantly route

100\%

of the traffic back to the original version, which remains completely intact and unaffected during the test.

Adım Adım Çözüm

Analyze the traffic splitting and routing requirements.

The requirements specify routing a small portion (

10\%

) of traffic to the new version, holding it there for a monitoring period of

10

minutes, and then shifting the remaining

90\%

at once.

This matches the definition of a canary deployment, which exposes a small subset of users to the new version to verify stability.

Evaluate the rollback and risk mitigation requirements.

The strategy must support instant rollback without affecting users on the old version if errors occur during the monitoring window.

Because the old version is still active and serving

90\%

of traffic on separate resources (blue/green canary), traffic can be instantly re-routed back to the old version without needing to redeploy or rebuild packages.

Compare against linear, rolling, and all-at-once strategies.

Linear shifts traffic continuously in increments (not holding at

10\%

then jumping to

100\%

). Rolling updates instances in-place, which lacks clean isolation and instant rollback. All-at-once exposes all users immediately, maximizing risk.

Only the canary deployment configuration satisfies the exact two-step traffic routing and rollback criteria.

Anahtar Kavram

Canary deployment strategy in AWS CodeDeploy

Tahmini Süre:1m 0s

Soru 562Soru →

A health-tech company has established a hybrid, multi-account AWS environment using AWS Organizations. The central network architecture consists of a Shared Services account containing a Transit Gateway and a hub VPC, and multiple application member accounts containing spoke VPCs. The spoke VPCs are attached to the Transit Gateway. The company maintains an on-premises data center connected to the Transit Gateway via an AWS Direct Connect connection. A Route 53 Private Hosted Zone (PHZ) named `corp.healthtech.internal` is hosted in the Shared Services account. The company needs to allow resources in the spoke VPCs and servers in the on-premises data center to resolve domain names in the PHZ. An inbound Route 53 Resolver endpoint is already created in the hub VPC. Which TWO actions must the Solutions Architect perform to implement this DNS resolution strategy? (Select TWO.)

Geçerli olan tümünü seçin

Create VPC association authorizations for each spoke VPC in the Shared Services account, and then associate the spoke VPCs with the Private Hosted Zone from each application member account.

Configure the on-premises DNS forwarders to route DNS queries for `corp.healthtech.internal` to the IP addresses of the Route 53 Resolver inbound endpoint in the hub VPC.

Share the Private Hosted Zone `corp.healthtech.internal` with the AWS Organization using AWS Resource Access Manager (RAM) to automatically associate it with all current and future spoke VPCs.

Configure a Route 53 Resolver outbound endpoint in the hub VPC with a forwarding rule for `corp.healthtech.internal` pointing to the Direct Connect Gateway (DXGW) to route DNS requests.

Associate the Private Hosted Zone directly with the Transit Gateway in the Shared Services account to allow transitive DNS resolution for all attached spoke VPCs.

Cevabı ve açıklamayı göster

Cevap: Create VPC association authorizations for each spoke VPC in the Shared Services account, and then associate the spoke VPCs with the Private Hosted Zone from each application member account.; Configure the on-premises DNS forwarders to route DNS queries for `corp.healthtech.internal` to the IP addresses of the Route 53 Resolver inbound endpoint in the hub VPC.

Cevap

The architecture is implemented by creating VPC association authorizations in the Shared Services account and associating the spoke VPCs from their respective application accounts, combined with configuring the on-premises DNS forwarders to point to the inbound Route 53 Resolver endpoint in the hub VPC.

The correct configurations involve performing cross-account Private Hosted Zone (PHZ) association and configuring on-premises DNS forwarding. First, because the PHZ is hosted in the Shared Services account and the spoke VPCs are in different application member accounts, a cross-account association must be established. This requires authorizing the association from the owner account (Shared Services) and then associating the spoke VPCs from the member accounts. Second, for the on-premises servers to resolve domain names in the PHZ over the Direct Connect connection, the on-premises DNS forwarders must target the IP addresses of the inbound Route 53 Resolver endpoint deployed in the hub VPC.

Adım Adım Çözüm

Authorize and associate the Private Hosted Zone with the spoke VPCs.

The spoke VPCs in the application member accounts are authorized and associated with the Private Hosted Zone hosted in the Shared Services account.

This allows resources inside the spoke VPCs to use their local Route 53 Resolver to resolve names inside the Shared Services Private Hosted Zone.

Configure on-premises DNS servers to forward queries to the inbound Route 53 Resolver endpoint.

On-premises servers route queries for `corp.healthtech.internal` to the inbound resolver endpoint in the hub VPC.

This allows the on-premises servers to resolve resources in the private hosted zone using the Direct Connect link.

Anahtar Kavram

Cross-account Private Hosted Zone association combined with inbound Route 53 Resolver endpoints for hybrid DNS resolution.

Soru 563Soru →

A financial services company is designing a multi-account environment using AWS Organizations to support a new product line. The solutions architect must implement a governance strategy that enforces two requirements. First, no user or role in the member accounts should be able to disable AWS Config or alter its configuration. Second, standard security baselines, including specific IAM roles and security groups, must be automatically provisioned in any new account that is added to the production Organizational Unit (OU). Which combination of actions will meet these requirements? (Select TWO.)

Geçerli olan tümünü seçin

Create a Service Control Policy (SCP) that denies `config:StopConfigurationRecorder`, `config:DeleteDeliveryChannel`, and `config:PutConfigurationRecorder` actions, and attach it to the production OU.

Create an AWS CloudFormation StackSet with service-managed permissions, enable automatic deployment, and target the production OU to provision the baseline resources.

Create a Service Control Policy (SCP) with an Allow statement for the `config:*` actions restricted to a specific administrator role, and attach it to the production OU.

Configure AWS Resource Access Manager (RAM) to share the baseline IAM roles and security groups from a central security account to the production OU.

Configure a federated SAML 2.0 role in the management account that trust-policies member accounts, and run a scheduled script to assume this role in each member account.

Cevabı ve açıklamayı göster

Cevap: Create a Service Control Policy (SCP) that denies `config:StopConfigurationRecorder`, `config:DeleteDeliveryChannel`, and `config:PutConfigurationRecorder` actions, and attach it to the production OU.; Create an AWS CloudFormation StackSet with service-managed permissions, enable automatic deployment, and target the production OU to provision the baseline resources.

Cevap

To protect AWS Config, deploy a Service Control Policy (SCP) that denies modifications to the configuration recorder and delivery channel. To deploy the baseline resources automatically, use an AWS CloudFormation StackSet with service-managed permissions targeted at the production Organizational Unit (OU).

The correct solution combines a Service Control Policy (SCP) and AWS CloudFormation StackSets. The SCP uses an explicit Deny statement on AWS Config modification APIs to act as a guardrail, ensuring no local user or role can disable the service. CloudFormation StackSets with service-managed permissions and automatic deployment enabled automatically provision standard baseline resources, such as IAM roles and security groups, in any new account added to the target Organizational Unit (OU) without requiring manual setup.

Adım Adım Çözüm

Identify the mechanism to prevent disabling or altering AWS Config across member accounts in AWS Organizations.

Determine that a Service Control Policy (SCP) with an explicit Deny statement for configuration modification actions is required.

SCPs act as organizational guardrails that override any local administrator permissions.

Identify the mechanism to automate the deployment of baseline resources (IAM roles and security groups) to new accounts in the production OU.

Determine that CloudFormation StackSets with service-managed permissions and automatic deployment enabled is the correct solution.

StackSets integrated with AWS Organizations can automatically deploy resources when new accounts are added to an OU.

Anahtar Kavram

Organizational guardrails and automated multi-account resource provisioning

Tahmini Süre:2m 0s

Soru 564Soru →

A company is implementing a multi-account identity strategy using AWS Organizations. They use an external SAML 2.0 compliant Identity Provider (IdP) to authenticate corporate users. The security team wants to enable single sign-on (SSO) so that administrators can access resources in a newly created member account. The administrators must assume a specific IAM role named NetworkAdminRole in the member account after authenticating via the IdP. Which of the following actions must the Solutions Architect perform to correctly configure the trust relationship for this federated access? (Select TWO.)

Geçerli olan tümünü seçin

Create an IAM SAML identity provider in the member account using the XML metadata document from the corporate Identity Provider.

Configure the trust policy of the NetworkAdminRole in the member account to define the Principal as the ARN of the SAML identity provider in the member account and specify the Action as sts:AssumeRoleWithSAML.

Create the IAM SAML identity provider in the organization's management account, and configure the trust policy of the NetworkAdminRole in the member account to reference the management account's SAML provider ARN.

Configure the trust policy of the NetworkAdminRole in the member account to define the Principal as the member account's root user and specify the Action as sts:AssumeRole.

Attach a Service Control Policy (SCP) to the member account's Organizational Unit (OU) that explicitly grants the sts:AssumeRoleWithSAML permission to the corporate Identity Provider.

Cevabı ve açıklamayı göster

Cevap: Create an IAM SAML identity provider in the member account using the XML metadata document from the corporate Identity Provider.; Configure the trust policy of the NetworkAdminRole in the member account to define the Principal as the ARN of the SAML identity provider in the member account and specify the Action as sts:AssumeRoleWithSAML.

Cevap

To configure the trust relationship for SAML 2.0 identity federation in a multi-account environment, you must create an IAM SAML identity provider in the member account using the corporate Identity Provider's XML metadata document, and configure the trust policy of the target IAM role to define the SAML identity provider as the Principal with the sts:AssumeRoleWithSAML action.

Establishing direct SAML 2.0 federation requires creating an IAM SAML identity provider in the target AWS account where the role is located, and configuring the trust policy of that role to authorize the SAML provider using the sts:AssumeRoleWithSAML action.

Adım Adım Çözüm

Obtain the SAML metadata document from the corporate Identity Provider (IdP).

An XML file containing the identity provider's configuration, certificates, and endpoints.

This metadata document is required by AWS to establish a trust relationship with the IdP.

Create an IAM SAML identity provider in the target member account using the obtained metadata document.

An IAM SAML provider resource is created in the member account with a unique ARN.

Each member account must have its own SAML provider configuration to establish a local trust anchor.

Configure the trust policy of the NetworkAdminRole in the member account.

The role's trust policy is updated to set the federated principal to the SAML provider ARN and allow the sts:AssumeRoleWithSAML action.

This allows authenticated users from the corporate IdP to assume the specific role and obtain temporary security credentials.

Anahtar Kavram

SAML 2.0 Federation Trust Relationship Configuration

Soru 565Soru →

A company is setting up identity federation to allow corporate directory users to access the AWS Management Console of a new member account. The directory uses an on-premises SAML 2.0 identity provider (IdP). To establish federation trust in the AWS account, which two configuration steps must the solutions architect perform?

Geçerli olan tümünü seçin

Create a SAML identity provider entity in AWS IAM by uploading the SAML metadata document obtained from the on-premises IdP.

Create an IAM role with a trust policy that allows the sts:AssumeRoleWithSAML action and references the SAML identity provider's ARN in the Principal block.

Create an IAM role with a trust policy that allows the sts:AssumeRole action and references the SAML identity provider's ARN in the Principal block.

Create a Service Control Policy (SCP) at the root of the AWS Organization to allow external SAML authentication across member accounts.

Cevabı ve açıklamayı göster

Cevap: Create a SAML identity provider entity in AWS IAM by uploading the SAML metadata document obtained from the on-premises IdP.; Create an IAM role with a trust policy that allows the sts:AssumeRoleWithSAML action and references the SAML identity provider's ARN in the Principal block.

Cevap

To establish SAML federation trust, create a SAML identity provider entity in AWS IAM by uploading the SAML metadata document, and create an IAM role with a trust policy that allows the sts:AssumeRoleWithSAML action and references the SAML identity provider's ARN as the Principal.

Establishing trust with an external SAML 2.0 IdP requires two primary configuration steps: first, creating a SAML provider entity in IAM using the IdP's metadata document to establish the cryptographic trust; second, creating an IAM role whose trust policy designates the SAML provider as a principal and permits the sts:AssumeRoleWithSAML action to allow authenticated users to exchange their SAML assertion for AWS credentials.

Adım Adım Çözüm

Create a SAML identity provider entity in AWS IAM using the XML metadata document from the corporate identity provider.

The identity provider is registered in the account with a unique ARN, serving as a trust endpoint.

AWS IAM requires the metadata document to verify the signatures of SAML assertions sent by the external IdP.

Create an IAM role that defines the permissions for federated users and configure its trust relationship.

The role's trust policy specifies the SAML provider as the trusted principal and allows the sts:AssumeRoleWithSAML action.

This configuration allows users authenticated by the external IdP to assume the role and obtain temporary credentials to access AWS resources.

Anahtar Kavram

Configuring SAML 2.0 federation requires registering the identity provider in the target AWS account and associating it with an IAM role whose trust policy specifically enables sts:AssumeRoleWithSAML.

Soru 566Soru →

A solutions architect is tasked with restricting member accounts from performing unauthorized actions across a newly created AWS Organization. The architect decides to use Service Control Policies (SCPs) to enforce these boundaries. To implement this governance control, in what order should the steps be performed?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence is to first create the AWS Organization, enable the Service Control Policies feature within the organization settings, author the custom policy document, and then attach the policy to the target Organizational Unit.

Establishing governance using SCPs requires first setting up the AWS Organization. The Service Control Policies feature must then be enabled in the organization settings since it is disabled by default. Once enabled, the custom policy defining the governance limits must be created, and finally, the policy must be attached to the target Organizational Unit (OU) to enforce the rules on member accounts.

Adım Adım Çözüm

Initialize the AWS Organization.

The Organization is created, and the management account is established.

You cannot manage policies or organize accounts before the organization environment exists.

Enable the Service Control Policies policy type.

SCPs are activated and ready to be applied.

SCPs are disabled by default in newly created organizations.

Create the custom SCP document.

The SCP document with the defined policy rules is stored in the account.

A policy must exist before you can select it to attach to target nodes.

Attach the policy.

The policy is attached to the target OU, applying the restrictions to all member accounts inside.

Creating a policy does not enforce it; it must be explicitly attached to target OUs or accounts.

Anahtar Kavram

Enabling and applying Service Control Policies (SCPs) within AWS Organizations governance workflows.

Tahmini Süre:45s

Soru 567Soru →

An enterprise is designing a secure hybrid and multi-account network topology for $40$ spoke VPCs distributed across two AWS Regions: us-east-1 and us-west-2. The spoke VPCs are owned by different AWS accounts within an AWS Organization.

The network requirements are:
- High-throughput, private hybrid connectivity to an on-premises data center.
- Centralized egress to the internet through a dedicated Security VPC in us-east-1 using NAT Gateways.
- Private DNS resolution where all spoke VPCs must resolve internal AWS resources defined in a central Route 53 Private Hosted Zone (PHZ) under a Shared Services account, as well as on-premises domains ending in `.corp`.
- A highly resilient design with no single points of failure.

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

Geçerli olan tümünü seçin

Deploy redundant NAT Gateways across multiple Availability Zones in the us-east-1 Security VPC, and configure the us-east-1 Transit Gateway (TGW) route tables to direct outbound internet traffic (

0.0.0.0/0

) to the Security VPC attachment.

Create Route 53 Resolver outbound endpoints in the Shared Services VPC, and use cross-account authorizations to associate the central Private Hosted Zone (PHZ) individually with all

40

spoke VPCs.

Associate the central Private Hosted Zone (PHZ) with the regional Transit Gateways (TGWs) to allow all attached spoke VPCs to resolve the private hostnames transitively.

Deploy a single NAT Gateway in the us-east-1 Security VPC to minimize running costs, and configure the Transit Gateway (TGW) route table to direct outbound internet traffic (

0.0.0.0/0

) from all Availability Zones to the subnet hosting that NAT Gateway.

Associate the Direct Connect Gateway (DXGW) directly with the Virtual Private Gateways (VGWs) of all

40

spoke VPCs to route inter-VPC traffic transitively and provide hybrid connectivity.

Cevabı ve açıklamayı göster

Cevap: Deploy redundant NAT Gateways across multiple Availability Zones in the us-east-1 Security VPC, and configure the us-east-1 Transit Gateway (TGW) route tables to direct outbound internet traffic ( $0.0.0.0/0$ ) to the Security VPC attachment.; Create Route 53 Resolver outbound endpoints in the Shared Services VPC, and use cross-account authorizations to associate the central Private Hosted Zone (PHZ) individually with all $40$ spoke VPCs.

Cevap

Deploy redundant NAT Gateways across multiple Availability Zones in the us-east-1 Security VPC and configure the TGW route tables to direct outbound internet traffic to the Security VPC attachment; and create Route 53 Resolver outbound endpoints in the Shared Services VPC and use cross-account authorizations to associate the central PHZ individually with all spoke VPCs.

Deploying redundant NAT Gateways across multiple Availability Zones in the Security VPC secures high availability for all internet-bound traffic routed through the Transit Gateway. Simultaneously, private DNS resolution requires that the central Private Hosted Zone is associated with each consumer VPC, combined with Route 53 Resolver outbound endpoints to forward queries for `.corp` to the on-premises DNS servers.

Adım Adım Çözüm

Configure the centralized egress routing architecture.

Deploy redundant NAT Gateways in multiple Availability Zones in the Security VPC to avoid a single point of failure, and point the default route (

0.0.0.0/0

) of the Transit Gateway route table to the Security VPC attachment.

This guarantees that outbound internet traffic is centrally inspected and has high availability.

Establish the private DNS resolution topology across accounts.

Create cross-account authorizations and associate the central Private Hosted Zone (PHZ) with each of the

40

consumer spoke VPCs individually.

Route 53 Private Hosted Zones must be explicitly associated with each VPC in order for resources within those VPCs to resolve the hosted zone's records.

Set up hybrid DNS resolution for on-premises domains.

Deploy Route 53 Resolver outbound endpoints in the Shared Services VPC and configure a forwarding rule for the `.corp` domain to point to the on-premises DNS servers.

This allows query forwarding for the on-premises `.corp` domain from AWS VPCs to the customer gateway.

Anahtar Kavram

Multi-account hybrid networking requires explicit routing configurations on Transit Gateways, individual VPC associations for Private Hosted Zones, and multi-AZ NAT Gateways to prevent single points of failure.

Tahmini Süre:3m 0s

Soru 568Soru →

An enterprise is consolidating its identity management across 50 AWS accounts managed under AWS Organizations. Currently, each member account has a separate IAM SAML 2.0 identity provider (IdP) configured to federate with the corporate Okta directory. The administration of managing these individual identity providers and mapping IAM roles locally has become operationally inefficient. The solutions architect must implement a centralized identity federation strategy that simplifies administration and automates user provisioning from Okta. Which strategy should the solutions architect select?

Enable AWS IAM Identity Center in the Organizations management account. Configure Okta as the external identity provider using SAML 2.0 for authentication and System for Cross-domain Identity Management (SCIM) for automatic user and group provisioning. Define permission sets in IAM Identity Center to manage access to member accounts.

Define a single IAM role in each member account. Apply a Service Control Policy (SCP) at the organization root that allows the external Okta identity provider to assume these IAM roles directly based on Okta group assertions, eliminating the need for local trust relationships.

Centralize federation by creating a single IAM identity provider in a dedicated Shared Services account linked to Okta. Configure IAM roles in the member accounts with a trust policy that allows federated access from Okta using the sts:AssumeRole action instead of sts:AssumeRoleWithSAML.

Use AWS Resource Access Manager (RAM) to share a single IAM SAML identity provider from a Shared Services account to all member accounts. Instruct users to authenticate to the shared provider and assume local roles.

Cevabı ve açıklamayı göster

Cevap: Enable AWS IAM Identity Center in the Organizations management account. Configure Okta as the external identity provider using SAML 2.0 for authentication and System for Cross-domain Identity Management (SCIM) for automatic user and group provisioning. Define permission sets in IAM Identity Center to manage access to member accounts.

Cevap

Enable AWS IAM Identity Center in the Organizations management account, configure Okta as the external identity provider using SAML 2.0 for authentication and SCIM for provisioning, and manage access using permission sets.

The correct strategy uses AWS IAM Identity Center to centralize identity federation and permissions across the entire AWS Organization. Integrating with Okta via SAML 2.0 handles authentication, while implementing SCIM ensures that user accounts and group memberships are automatically synchronized from Okta to AWS, resolving the operational overhead of manual role mapping in each individual account.

Adım Adım Çözüm

Centralize identity management with AWS IAM Identity Center.

Configured AWS IAM Identity Center in the Organizations management account to act as a single point of entry and administration for access across all member accounts.

This removes the overhead of managing individual IAM SAML providers and roles in each of the 50 separate accounts.

Establish federation and automatic provisioning with Okta.

Configured Okta as the external identity provider using SAML 2.0 for federated authentication, and enabled SCIM synchronization.

SCIM automates the creation, modification, and deletion of users and groups in AWS based on changes in the Okta directory, ensuring synchronization and reducing administrative overhead.

Define and assign permissions centralized in IAM Identity Center.

Created permission sets that specify the level of access users have, and assigned them to Okta groups and specific AWS accounts.

This delegates access management to IAM Identity Center, allowing policy administration from a single plane rather than modifying individual IAM roles locally in each account.

Anahtar Kavram

AWS IAM Identity Center integration with external Identity Providers (IdP) like Okta using SAML 2.0 and SCIM for automated provisioning across a multi-account organization.

Tahmini Süre:1m 30s

Soru 569Soru →

A company is setting up identity federation with an external SAML 2.0 Identity Provider (IdP) to allow corporate users to access the AWS Management Console of a member account. A solutions architect needs to configure the trust relationship in the target member account.

Which configuration steps must the solutions architect perform in the target AWS account to establish this federated access? (Select TWO.)

Geçerli olan tümünü seçin

Create an IAM SAML identity provider in the target AWS account using the metadata document from the corporate Identity Provider.

Create an IAM role in the target AWS account with a trust policy that allows the sts:AssumeRoleWithSAML action for the SAML provider.

Create a Service Control Policy (SCP) at the Organization level that explicitly grants sts:AssumeRoleWithSAML permissions to all federated identities.

Create an IAM role in the target AWS account with a trust policy that allows the sts:AssumeRole action for the root user of the account.

Create an IAM group in the target AWS account, attach the corporate identity provider to it, and add the federated users to the group.

Cevabı ve açıklamayı göster

Cevap: Create an IAM SAML identity provider in the target AWS account using the metadata document from the corporate Identity Provider.; Create an IAM role in the target AWS account with a trust policy that allows the sts:AssumeRoleWithSAML action for the SAML provider.

Cevap

Create an IAM SAML identity provider in the target AWS account using the metadata document from the corporate Identity Provider, and create an IAM role in the target AWS account with a trust policy that allows the sts:AssumeRoleWithSAML action for the SAML provider.

Establishing federated access requires creating a SAML identity provider in IAM using the metadata document from the corporate identity provider, which allows AWS to trust the provider. Additionally, an IAM role with a trust policy permitting the sts:AssumeRoleWithSAML action must be created so that users authenticated by the SAML provider can assume the role and gain access to resources.

Adım Adım Çözüm

An IAM SAML identity provider is created representing the corporate IdP.

This establishes trust between the target AWS account and the external SAML identity provider.

Define an IAM role to map corporate users.

An IAM role is created with a trust policy granting sts:AssumeRoleWithSAML to the newly created SAML identity provider.

This allows federated users authenticated by the IdP to temporarily assume permissions in the target account.

Anahtar Kavram

Establishing SAML 2.0 identity federation in a multi-account environment requires creating a local SAML identity provider object and configuring an IAM role with a trust policy allowing the sts:AssumeRoleWithSAML action.

Tahmini Süre:1m 0s

Soru 570Soru →

A medical device company uses AWS Organizations to manage a multi-account environment. A newly acquired division has several AWS accounts grouped under a dedicated Organizational Unit (OU) named Acquisition-OU. The corporate security team must enforce a strict compliance rule: all Amazon Elastic Block Store (Amazon EBS) volumes provisioned within Acquisition-OU must be encrypted. To ensure rapid mitigation in the event of a security incident, the encryption must use a Customer Managed Key (CMK) hosted in a centralized Security account, allowing the security team to revoke access instantly. The local administrators in the member accounts have full administrative privileges and must be able to launch Amazon EC2 instances with encrypted volumes without having IAM credentials or roles in the Security account. Which combination of configurations will meet these requirements while preventing member account administrators from bypassing the encryption guardrail?

In the Security account, create a Customer Managed Key (CMK). Configure the CMK's key policy to allow the member accounts' root principals to perform the kms:Decrypt, kms:GenerateDataKeyWithoutPlaintext, and kms:CreateGrant actions. Attach a Service Control Policy (SCP) to the Acquisition-OU that explicitly allows these KMS actions on the Security account's CMK, and denies ec2:RunInstances if the EBS volume is unencrypted. Rely on the SCP to authorize the pipeline IAM roles without adding local IAM policy permissions in the member accounts.

In the Security account, create a Customer Managed Key (CMK). Configure the CMK's key policy to allow the member accounts' root principals (arn:aws:iam::<member-account-ID>:root) to perform the kms:Decrypt, kms:GenerateDataKeyWithoutPlaintext, and kms:CreateGrant actions. In each member account, grant the local IAM roles used to launch EC2 instances permissions to perform these same KMS actions on the central CMK. Attach a Service Control Policy (SCP) to the Acquisition-OU that denies the ec2:RunInstances action if the EBS volume is unencrypted or if the KMS key specified is not the central CMK ARN.

In the Security account, enable cross-account sharing on the AWS-managed KMS key for EBS (aws/ebs) by updating its key policy to trust the member accounts. In each member account, grant local EC2 execution roles permissions to use the Security account's aws/ebs key. Attach a Service Control Policy (SCP) to the Acquisition-OU that denies the ec2:RunInstances action if the EBS volume is unencrypted.

In the Security account, create a Customer Managed Key (CMK) and configure its key policy to trust the member accounts' root principals. In the member accounts, create and attach a customer managed IAM policy to all local IAM users and roles that denies the ec2:RunInstances action if the EBS volume is unencrypted or does not use the central CMK. Avoid attaching any Service Control Policies (SCPs) at the Organization level to minimize performance impact on API requests.

Cevabı ve açıklamayı göster

Cevap: In the Security account, create a Customer Managed Key (CMK). Configure the CMK's key policy to allow the member accounts' root principals (arn:aws:iam::<member-account-ID>:root) to perform the kms:Decrypt, kms:GenerateDataKeyWithoutPlaintext, and kms:CreateGrant actions. In each member account, grant the local IAM roles used to launch EC2 instances permissions to perform these same KMS actions on the central CMK. Attach a Service Control Policy (SCP) to the Acquisition-OU that denies the ec2:RunInstances action if the EBS volume is unencrypted or if the KMS key specified is not the central CMK ARN.

Cevap

Create a Customer Managed Key in the Security account, trust the member accounts' root principals in its key policy, grant the local EC2 roles in the member accounts permission to use the central key, and enforce the configuration using an OU-level Service Control Policy that blocks instance launches with unencrypted volumes or unauthorized keys.

The correct solution uses a Customer Managed Key (CMK) in the Security account because AWS-managed keys cannot be shared cross-account. It delegates key access to the member accounts via the root principal in the key policy, and then explicitly grants access to the local EC2 roles using local IAM policies. Finally, it uses a Service Control Policy (SCP) attached to the Organizational Unit to deny launching instances unless they use the approved central key, which cannot be bypassed by local administrators.

Adım Adım Çözüm

Select the correct KMS key type.

A Customer Managed Key (CMK) must be created in the central Security account because the default AWS-managed KMS key (aws/ebs) does not allow policy modification and cannot be shared across different AWS accounts.

Enables cross-account usage for EBS encryption.

Configure the central key policy.

The CMK policy must trust the root principal of the member accounts (arn:aws:iam::<member-account-ID>:root) for the required actions: kms:Decrypt, kms:GenerateDataKeyWithoutPlaintext, and kms:CreateGrant.

Enables the member accounts to delegate these permissions to their local roles.

Configure local IAM permissions in member accounts.

Local IAM policies must grant the EC2 execution roles permission to use the central CMK.

Allows the EC2 service to create a grant and use the key when launching instances, since SCPs only establish permission boundaries and do not grant permissions.

Enforce compliance via a Service Control Policy (SCP).

Attach an SCP to the Acquisition-OU that denies ec2:RunInstances if the volume is unencrypted or uses a key other than the central CMK.

Ensures that even local administrators cannot bypass the encryption policy, as SCPs apply to all principals in member accounts including administrators.

Anahtar Kavram

Cross-account KMS key delegation and Service Control Policy (SCP) enforcement in AWS Organizations

Tahmini Süre:3m 0s

Soru 571Soru →

A multinational enterprise manages its multi-account environment using AWS Organizations. The setup includes a management account, a central network account, and multiple member accounts for various business units. The network team needs to share private subnets and Transit Gateway attachments from the central network account to other internal member accounts. The security team requires all VPC Flow Logs to be encrypted using a Customer Managed Key (CMK). Additionally, a joint venture partner's account (Account P) must be billed under a separate pro forma structure that applies a 10% markup on standard AWS rates, and Account P must not benefit from any organization-wide volume discounts or Savings Plans. The remaining internal business units utilize a mix of Amazon EC2 and AWS Fargate, and they must share a discount model to optimize compute costs. Which combination of actions will meet these requirements with the least administrative effort?

Enable resource sharing within AWS Organizations. In the central network account, create an AWS RAM resource share for the subnets and Transit Gateway targeting the organization's OUs. Use a Customer Managed Key (CMK) with a cross-account key policy to encrypt the destination S3 bucket for VPC Flow Logs. Purchase Compute Savings Plans in the management account, and disable discount sharing for Account P in the Billing Preferences. In AWS Billing Conductor, configure a billing group for Account P with a 10% global markup rule.

Enable resource sharing within AWS Organizations. In the central network account, create an AWS RAM resource share for the subnets and Transit Gateway. Use the default AWS-managed KMS key (aws/s3) in the central network account to encrypt the Flow Logs S3 bucket. Purchase EC2 Instance Savings Plans in the management account, and disable discount sharing for Account P in the Billing Preferences. In AWS Billing Conductor, configure a billing group for Account P with a 10% global markup rule.

In the management account, attach a Service Control Policy (SCP) to the OU containing Account P that denies access to consolidated Savings Plans discounts and grants write permissions to the central Flow Logs bucket. Share the subnets and Transit Gateway from the central network account by creating an AWS RAM resource share targeting the specific account IDs of the internal business units. In AWS Billing Conductor, create a billing group containing Account P and apply a pricing rule with a 10% markup.

In the central network account, create an AWS RAM resource share for the subnets and Transit Gateway. Configure the share to allow external entities, and manually add the account IDs of the internal business units without enabling organizational sharing. Use a Customer Managed Key (CMK) in the central network account to encrypt the Flow Logs S3 bucket. Purchase Compute Savings Plans in the management account, and use IAM policies in Account P to deny access to Savings Plans resources. In AWS Billing Conductor, configure a billing group with a 10% markup for Account P.

Cevabı ve açıklamayı göster

Cevap: Enable resource sharing within AWS Organizations. In the central network account, create an AWS RAM resource share for the subnets and Transit Gateway targeting the organization's OUs. Use a Customer Managed Key (CMK) with a cross-account key policy to encrypt the destination S3 bucket for VPC Flow Logs. Purchase Compute Savings Plans in the management account, and disable discount sharing for Account P in the Billing Preferences. In AWS Billing Conductor, configure a billing group for Account P with a 10% global markup rule.

Cevap

The correct solution uses AWS RAM within the organization to share subnets and Transit Gateway attachments, which is a supported and secure sharing model. Using a Customer Managed Key (CMK) with a modified key policy allows cross-account logging services to encrypt and write to the centralized S3 bucket. Compute Savings Plans are selected because they apply to both EC2 and Fargate, and sharing is disabled specifically for the partner account using consolidated Billing Preferences. AWS Billing Conductor is used to create a billing group for the partner account and apply a 10% global markup rule for pro forma calculations.

Adım Adım Çözüm

Enable sharing within the AWS Organization in AWS Resource Access Manager (RAM), then create a resource share for the subnets and Transit Gateway in the central network account targeting the organization's OUs.

Subnets and Transit Gateways are securely shared with the appropriate member accounts within the organizational boundary.

VPC subnets can only be shared via AWS RAM within the same AWS Organization, and organizational sharing must be explicitly enabled.

Create a Customer Managed Key (CMK) in the central network account, edit its key policy to allow cross-account access, and use it to encrypt the S3 bucket where Flow Logs are published.

Cross-account Flow Logs can be successfully written to and read from the encrypted S3 bucket.

AWS-managed keys (like aws/s3) cannot be shared across accounts because their key policies cannot be customized.

Purchase Compute Savings Plans in the management account, and configure Billing Preferences to disable discount sharing for Account P.

Compute costs for EC2 and Fargate are optimized for internal accounts, while Account P is excluded from these benefits.

Compute Savings Plans are needed to cover both EC2 and Fargate usage, and selectively disabling discount sharing at the management account level is the only way to exclude specific accounts.

Configure AWS Billing Conductor by creating a custom billing group containing Account P and applying a pricing rule with a 10% global markup.

Account P receives a customized pro forma billing view showing the 10% markup.

AWS Billing Conductor allows organizations to define custom pricing rules and billing groups for showback or chargeback purposes without affecting the consolidated billing invoice.

Anahtar Kavram

AWS RAM organizational sharing boundaries, cross-account KMS key policy delegation, Billing Preferences for selective Savings Plans sharing, and AWS Billing Conductor custom billing groups.

Soru 572Soru →

A solutions architect is configuring single sign-on access to a member account within AWS Organizations. The architect establishes a trust relationship with an external SAML 2.0 Identity Provider (IdP) by creating an IAM identity provider in the member account. However, when corporate directory users attempt to federate, the authentication flow fails when trying to assume the designated target role.

Which of the following represents the correct configuration required in the target IAM role's trust policy to resolve this issue?

Configure the IAM role trust policy to define the SAML identity provider as the principal and allow the sts:AssumeRoleWithSAML action.

Configure the IAM role trust policy to define the corporate user directory as the principal and allow the sts:AssumeRole action.

Attach a Service Control Policy to the organizational unit that explicitly allows the sts:AssumeRoleWithSAML action for external identity providers.

Configure the IAM role trust policy to define the SAML identity provider as the principal and allow the sts:AssumeRoleWithWebIdentity action.

Cevabı ve açıklamayı göster

Cevap: Configure the IAM role trust policy to define the SAML identity provider as the principal and allow the sts:AssumeRoleWithSAML action.

Cevap

Configure the IAM role trust policy to define the SAML identity provider as the principal and allow the sts:AssumeRoleWithSAML action.

The configuration that defines the SAML identity provider as the principal and allows the sts:AssumeRoleWithSAML action is correct. This is because AWS STS requires this specific API action to exchange a SAML assertion for temporary credentials, and the IAM role's trust policy must specify the IAM SAML identity provider as the trusted principal.

Adım Adım Çözüm

Identify the federation protocol being configured.

The federation protocol is SAML 2.0.

The scenario specifies that the trust relationship is established with a SAML 2.0 Identity Provider (IdP).

Determine the correct AWS Security Token Service (STS) action for SAML 2.0.

The correct action is sts:AssumeRoleWithSAML.

AWS Security Token Service requires the sts:AssumeRoleWithSAML API action to process SAML assertions and issue temporary security credentials.

Formulate the trust relationship policy document for the target IAM role.

Create a trust policy with the Principal pointing to the SAML provider ARN and the Action set to sts:AssumeRoleWithSAML.

The IAM role must explicitly trust the SAML identity provider as a principal and allow the correct STS action to authorize the federation request.

Anahtar Kavram

SAML 2.0 Federation Trust Policy Configuration

Soru 573Soru →

An organization is updating a microservice running on AWS Lambda. The team wants to use AWS CodeDeploy to perform a canary deployment. The requirement is to route 10% of the production traffic to the new Lambda function version, wait for 10 minutes, and then shift the remaining 90% of the traffic to the new version. Which of the following CodeDeploy configurations can achieve this setup? (Select TWO.)

Geçerli olan tümünü seçin

The predefined CodeDeploy configuration named CodeDeployDefault.LambdaCanary10Percent10Minutes

A custom deployment configuration created using the AWS CLI or CloudFormation with a canary traffic-shifting type, a 10% step percentage, and a 10-minute interval

The predefined CodeDeploy configuration named CodeDeployDefault.LambdaLinear10PercentEvery10Minutes

The predefined CodeDeploy configuration named CodeDeployDefault.ECSCanary10Percent10Minutes

The predefined CodeDeploy configuration named CodeDeployDefault.LambdaAllAtOnce

Cevabı ve açıklamayı göster

Cevap: The predefined CodeDeploy configuration named CodeDeployDefault.LambdaCanary10Percent10Minutes; A custom deployment configuration created using the AWS CLI or CloudFormation with a canary traffic-shifting type, a 10% step percentage, and a 10-minute interval

Cevap

The predefined CodeDeployDefault.LambdaCanary10Percent10Minutes configuration, and a custom deployment configuration configured with a canary traffic-shifting type, a 10% step percentage, and a 10-minute interval.

The scenario requires routing 10% of traffic, waiting 10 minutes, and then routing the remaining 90%. This can be achieved using the predefined configuration named CodeDeployDefault.LambdaCanary10Percent10Minutes, or by creating a custom CodeDeploy deployment configuration using AWS CLI or CloudFormation with a canary shifting type, a 10% step percentage, and a 10-minute interval.

Adım Adım Çözüm

Determine the required deployment pattern from the scenario details.

The scenario requires shifting 10% of traffic initially, waiting for a single 10-minute period, and then shifting the remaining 90% of traffic.

This identifies that a canary deployment strategy is needed rather than a linear or all-at-once strategy.

Check predefined CodeDeploy configurations for AWS Lambda that match this pattern.

CodeDeployDefault.LambdaCanary10Percent10Minutes is identified as matching the requirements exactly.

AWS CodeDeploy provides built-in configurations for common traffic-shifting patterns on Lambda.

Identify valid alternatives or custom deployment configurations for AWS Lambda.

A custom deployment configuration can be created using the AWS CLI or CloudFormation with the same canary shifting behavior.

AWS CodeDeploy supports defining custom configurations if specific parameters are required or if they need to be managed as custom resources.

Anahtar Kavram

AWS CodeDeploy deployment configurations for AWS Lambda deployments, comparing canary and linear traffic shifting, as well as predefined versus custom configurations.

Soru 574Soru →

An enterprise is designing a hybrid network to connect its on-premises environment with 20 spoke VPCs in a multi-account AWS environment. The design must use an AWS Transit Gateway for centralized routing. The network architecture requires a primary $10\text{ Gbps}$ AWS Direct Connect connection and a backup AWS Site-to-Site VPN connection, with automatic failover and failback. Additionally, on-premises servers must resolve domain names for resources inside an AWS Route 53 Private Hosted Zone (PHZ) that is managed in a shared services VPC.

Which two configurations should a solutions architect implement to meet these requirements? (Select TWO.)

Geçerli olan tümünü seçin

Associate the AWS Direct Connect gateway with the Transit Gateway using a Transit Virtual Interface (Transit VIF), and attach the Site-to-Site VPN to the Transit Gateway, configuring BGP routing on both paths.

Create Route 53 Resolver inbound endpoints in the shared services VPC, associate the Route 53 PHZ with all 20 spoke VPCs and the shared services VPC, and configure on-premises DNS forwarders to target the inbound endpoint IP addresses.

Associate the Route 53 PHZ only with the shared services VPC, and rely on Transit Gateway route propagation to automatically route DNS queries from the other 20 spoke VPCs to the Route 53 Resolver in the shared services VPC.

Associate the Direct Connect Gateway directly with all 20 spoke VPCs using Private Virtual Interfaces (Private VIFs) to establish direct transitive routing, bypassing the Transit Gateway to optimize latency.

Deploy a single NAT Gateway in the shared services VPC and route all egress traffic from the 20 spoke VPCs through this gateway to provide a single public egress point for on-premises DNS forwarding.

Cevabı ve açıklamayı göster

Cevap: Associate the AWS Direct Connect gateway with the Transit Gateway using a Transit Virtual Interface (Transit VIF), and attach the Site-to-Site VPN to the Transit Gateway, configuring BGP routing on both paths.; Create Route 53 Resolver inbound endpoints in the shared services VPC, associate the Route 53 PHZ with all 20 spoke VPCs and the shared services VPC, and configure on-premises DNS forwarders to target the inbound endpoint IP addresses.

Cevap

To meet the requirements, the solutions architect must associate the AWS Direct Connect gateway with the Transit Gateway using a Transit VIF and configure BGP routing on both paths, while also creating Route 53 Resolver inbound endpoints in the shared services VPC and associating the Route 53 PHZ with all 20 spoke VPCs and the shared services VPC.

To establish a highly available, scalable hybrid network, AWS Transit Gateway acts as the central hub. Associating the Direct Connect gateway via a Transit VIF and establishing a BGP-configured VPN attachment allows for automatic failover and failback, as AWS naturally prioritizes Direct Connect over VPN when identical routes are advertised. For on-premises servers to resolve names in the Private Hosted Zone, Route 53 Resolver inbound endpoints must be created in the shared services VPC. Furthermore, because DNS queries targeting the VPC-local resolver IP (169.254.169.253) cannot cross Transit Gateway attachments, the Private Hosted Zone must be associated with the shared services VPC and all 20 spoke VPCs.

Adım Adım Çözüm

Configure hybrid routing using AWS Transit Gateway.

Connect the AWS Direct Connect Gateway using a Transit VIF to the Transit Gateway, and establish a backup Site-to-Site VPN attachment to the same Transit Gateway.

This centralizes transit network management for all 20 spoke VPCs and avoids the scale limitations of Direct Connect Gateway associations.

Configure BGP routing on both the Direct Connect and VPN paths.

Dynamic routes are advertised via BGP. By default, AWS route preference prioritizes the Direct Connect path over the VPN path when identical prefixes are advertised.

This configuration enables automatic failover to the VPN connection and automatic failback to the Direct Connect connection when it recovers.

Implement the hybrid DNS architecture.

Deploy Route 53 Resolver inbound endpoints in the shared services VPC. Configure the on-premises DNS server to forward queries for the internal domain to these inbound endpoint IPs. Associate the Private Hosted Zone with all 20 spoke VPCs and the shared services VPC.

On-premises servers need the inbound endpoints to query AWS DNS. The PHZ must be associated with every VPC from which queries are initiated (including the inbound endpoint's VPC) because DNS query traffic to the Route 53 Resolver IP cannot cross Transit Gateway attachments.

Anahtar Kavram

Centralized hybrid network routing using AWS Transit Gateway combined with BGP routing, and private DNS query resolution across hybrid environments using Route 53 Resolver inbound endpoints and explicit Private Hosted Zone associations.

Soru 575Soru →

A solutions architect is configuring a centralized logging solution to aggregate AWS CloudTrail logs from all member accounts within an AWS Organization. The logs will be deposited into a single Amazon S3 bucket situated in a dedicated Security account. The architect needs to ensure that CloudTrail in the member accounts can successfully deliver logs to the bucket and that the log files are encrypted at rest using KMS. Which TWO configurations are required to meet these requirements?

Geçerli olan tümünü seçin

Configure the S3 bucket policy in the Security account to grant s3:PutObject permissions to the CloudTrail service principal, specifying the aws:PrincipalOrgID condition key.

Create a customer managed KMS key in the Security account with a key policy that grants the CloudTrail service principal permissions to perform kms:GenerateDataKey* operations.

Enable encryption on the S3 bucket using the AWS-managed KMS key for S3 (aws/s3) and grant cross-account write permissions to the member accounts using IAM policies.

Apply a Service Control Policy (SCP) at the organization root that grants the s3:PutObject permission on the destination S3 bucket to the CloudTrail service principal.

Configure the S3 bucket policy to only permit local IAM roles in the Security account to write objects, and configure member accounts to assume these roles during log delivery.

Cevabı ve açıklamayı göster

Cevap: Configure the S3 bucket policy in the Security account to grant s3:PutObject permissions to the CloudTrail service principal, specifying the aws:PrincipalOrgID condition key.; Create a customer managed KMS key in the Security account with a key policy that grants the CloudTrail service principal permissions to perform kms:GenerateDataKey* operations.

Cevap

The configurations required are: first, setting up the S3 bucket policy in the Security account to grant s3:PutObject permissions to the CloudTrail service principal using the aws:PrincipalOrgID condition; second, creating a customer managed KMS key in the Security account and configuring its policy to allow the CloudTrail service principal to generate data keys.

The correct configurations involve allowing the CloudTrail service principal to write to the destination S3 bucket via its bucket policy, using the aws:PrincipalOrgID condition to securely filter access to the organization. Additionally, since the logs are encrypted at rest using KMS and come from multiple member accounts, a customer managed key is required because its policy must be updated to allow CloudTrail to generate data keys for encryption.

Adım Adım Çözüm

Configure S3 Bucket Policy

An S3 bucket policy is created and attached to the centralized logging bucket in the Security account, allowing the 'cloudtrail.amazonaws.com' principal to perform 's3:PutObject' for paths matching the AWS Organization ID.

CloudTrail requires direct resource-based permissions on the target S3 bucket to deliver logs from multiple member accounts.

Configure KMS Key and Policy

A customer managed KMS key is created in the Security account with a key policy allowing the CloudTrail service principal to perform 'kms:GenerateDataKey*' and 'kms:DescribeKey' operations.

AWS-managed KMS keys do not support cross-account access or custom resource policies, making a customer managed key necessary for cross-account log encryption.

Anahtar Kavram

Centralized cross-account logging requires resource policies (S3 bucket policy and KMS key policy) that explicitly trust the CloudTrail service principal and restrict access using organizational context (e.g., aws:PrincipalOrgID).

Soru 576Soru →

A biopharmaceutical research organization is deploying a multi-account AWS environment. The core network is built on a Hub-and-Spoke topology using AWS Transit Gateway, with a central Hub VPC in the Network Services account and multiple Spoke VPCs in separate member accounts (Production and Development) within the same AWS Organization. A Route 53 Private Hosted Zone (PHZ) named `research.internal` is hosted in a dedicated Shared Services account. The company's on-premises laboratory network is connected to the Hub VPC via AWS Direct Connect, where on-premises DNS servers manage the `lab.local` domain. The architecture must allow on-premises laboratory systems to resolve resources in the `research.internal` PHZ, and EC2 instances in all Spoke VPCs to resolve both `lab.local` and `research.internal` resources. The design must minimize administrative overhead and ensure that DNS traffic does not traverse the public internet.

Which TWO configuration steps are required to establish this DNS resolution path? (Select TWO.)

Geçerli olan tümünü seçin

In the Shared Services account, authorize the association of the research.internal private hosted zone with the Hub VPC and each Spoke VPC. In the Network Services and member accounts, accept the association to link the VPCs to the private hosted zone.

In the Network Services account, create Route 53 Resolver inbound and outbound endpoints in the Hub VPC. Create a Resolver forwarding rule for lab.local pointing to the on-premises DNS servers, share this rule with the member accounts using AWS Resource Access Manager (RAM), and associate it with the Spoke VPCs.

In the Shared Services account, associate the research.internal private hosted zone with the Hub VPC. Enable DNS support on the Transit Gateway attachments to allow the Spoke VPCs to transitively resolve queries within the research.internal zone.

In the Network Services account, create a Route 53 Resolver forwarding rule for research.internal pointing to the VPC resolver (

10.0.0.2

) of the Hub VPC, and associate this rule with all Spoke VPCs.

Configure the on-premises DNS servers to forward queries for research.internal to the Direct Connect Gateway (DXGW) IP addresses, and configure the DXGW to route these queries to the Route 53 Resolver in the Shared Services account.

Cevabı ve açıklamayı göster

Cevap: In the Shared Services account, authorize the association of the research.internal private hosted zone with the Hub VPC and each Spoke VPC. In the Network Services and member accounts, accept the association to link the VPCs to the private hosted zone.; In the Network Services account, create Route 53 Resolver inbound and outbound endpoints in the Hub VPC. Create a Resolver forwarding rule for lab.local pointing to the on-premises DNS servers, share this rule with the member accounts using AWS Resource Access Manager (RAM), and associate it with the Spoke VPCs.

Cevap

The correct options are: (1) authorizing the association of the research.internal private hosted zone with the Hub VPC and each Spoke VPC in the Shared Services account, and accepting the association in the Network Services and member accounts; and (2) creating Route 53 Resolver inbound and outbound endpoints in the Hub VPC, creating a forwarding rule for lab.local pointing to the on-premises DNS servers, sharing the rule via AWS Resource Access Manager (RAM), and associating it with the Spoke VPCs.

The correct configurations involve establishing cross-account Private Hosted Zone (PHZ) associations and deploying Route 53 Resolver endpoints. First, because the PHZ is hosted in the Shared Services account, it must be associated with the Hub VPC and the Spoke VPCs in the other accounts. This requires a cross-account authorization from the Shared Services account followed by acceptance in the respective target accounts. Second, a centralized resolver pattern in the Network Services Hub VPC using Route 53 Resolver inbound and outbound endpoints manages the hybrid traffic. An outbound endpoint with a forwarding rule for the on-premises domain is shared with the Spoke VPC accounts via AWS Resource Access Manager (RAM) to resolve on-premises names, while the inbound endpoint allows on-premises servers to forward queries to AWS.

Adım Adım Çözüm

Authorize and establish cross-account Private Hosted Zone (PHZ) associations.

The Shared Services account authorizes the association of the research.internal PHZ with the Hub VPC and all Spoke VPCs. The Network Services and member accounts accept the associations, allowing local resolvers in all VPCs to resolve research.internal.

Since the PHZ is owned by a different account, a cross-account association is mandatory for the VPCs to resolve the private DNS zone locally.

Deploy Route 53 Resolver inbound endpoints in the central Hub VPC and configure on-premises forwarding.

On-premises DNS servers are configured to forward queries for research.internal to the inbound endpoint IPs.

This allows on-premises clients to safely query and resolve the AWS private DNS zone without exposing resources to the public internet.

Deploy Route 53 Resolver outbound endpoints and configure outbound forwarding rules.

A Resolver forwarding rule for lab.local is created pointing to the on-premises DNS servers. This rule is shared via AWS RAM and associated with the Spoke VPCs.

This enables instances in the Spoke VPCs to forward queries for on-premises domains through the Hub VPC's outbound endpoint.

Anahtar Kavram

Hybrid DNS resolution and cross-account Private Hosted Zone associations using Route 53 Resolver endpoints.

Soru 577Soru →

A company is restructuring its AWS multi-account environment under AWS Organizations. The environment consists of a Management account, a Shared Network account, and multiple business unit accounts divided into Production and Development Organizational Units (OUs).

The company has two primary requirements:
1. Share specific private subnets owned by the Shared Network account with only the Production business unit accounts to deploy application resources.
2. Ensure that Compute Savings Plans purchased in the Management account apply discounts to workloads in the Production business unit accounts, but do not apply discounts to workloads in the Development business unit accounts.

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

Geçerli olan tümünü seçin

In the Management account's AWS Billing console, disable Savings Plan discount sharing for the individual accounts belonging to the Development Organizational Unit (OU).

In the Management account, enable resource sharing within AWS Organizations. In the Shared Network account, use AWS Resource Access Manager (RAM) to create a resource share containing the private subnets and associate it with the Production business unit Organizational Unit (OU).

Attach a Service Control Policy (SCP) to the Development business unit Organizational Unit (OU) that denies the savingsplans:ApplyDiscount action.

In the Management account, use AWS Resource Access Manager (RAM) to create a resource share containing the private subnets from the Shared Network account, and associate the share with the Production business unit accounts.

Purchase EC2 Instance Savings Plans in the Management account to automatically prevent the discounts from applying to any accounts running serverless workloads in the Development business unit.

Cevabı ve açıklamayı göster

Cevap: In the Management account's AWS Billing console, disable Savings Plan discount sharing for the individual accounts belonging to the Development Organizational Unit (OU).; In the Management account, enable resource sharing within AWS Organizations. In the Shared Network account, use AWS Resource Access Manager (RAM) to create a resource share containing the private subnets and associate it with the Production business unit Organizational Unit (OU).

Cevap

To meet the requirements, the Solutions Architect must disable Savings Plan discount sharing for the Development business unit accounts in the Management account's AWS Billing console, and use AWS Resource Access Manager (RAM) in the Shared Network account to share the private subnets with the Production business unit Organizational Unit (OU) after enabling sharing in AWS Organizations.

The correct strategy requires two actions: disabling Savings Plan discount sharing for the Development accounts in the Management account's Billing Preferences, and creating a resource share for the subnets inside the Shared Network account where the subnets reside, after enabling AWS Organizations resource sharing in the Management account. Disabling discount sharing for specific member accounts in the Billing Preferences allows the management account to control which accounts benefit from the organization's pooled Savings Plans. Sharing subnets must be done from the resource-owning account (Shared Network account) and directed to the Production Organizational Unit (OU).

Adım Adım Çözüm

Configure resource sharing globally at the organization level.

Enables AWS Resource Access Manager (RAM) to share resources across accounts within the AWS Organization.

AWS RAM requires sharing with AWS Organizations to be explicitly enabled in the Management account before resources can be shared with OUs or other accounts in the organization.

Create the resource share for the subnets in the resource-owning account.

The private subnets are shared with the Production business unit Organizational Unit (OU).

Subnets must be shared from the account in which they were created (the Shared Network account) rather than from the Management account.

Configure Savings Plan sharing preferences in the AWS Billing console of the Management account.

Savings Plan discounts are disabled for the Development business unit accounts while remaining active for the Production business unit accounts.

AWS Consolidated Billing allows selective sharing of Reservation and Savings Plan discounts. Disabling discount sharing for specific member accounts ensures they pay regular rates and do not consume the Compute Savings Plans purchased by the Management account.

Anahtar Kavram

AWS Resource Access Manager (RAM) and consolidated billing discount sharing controls.

Soru 578Soru →

A global health-technology company is deploying a clinical trial data platform across a multi-account AWS environment managed by AWS Organizations. The architecture consists of a Shared Services VPC, a Production Workload VPC, and a Dev/Test VPC, all interconnected via an AWS Transit Gateway. The Transit Gateway also connects to the company's on-premises legacy clinical database network via an AWS Direct Connect connection with a Transit Virtual Interface (Transit VIF). A Private Hosted Zone (PHZ) named clinical.local is hosted in the Shared Services AWS account.

The company needs to establish a DNS resolution strategy that meets the following requirements:
- On-premises servers must be able to resolve domain names in the clinical.local PHZ.
- EC2 instances in all three VPCs must be able to resolve both clinical.local domains and on-premises domains ending in corp.internal.
- The architecture must minimize operational overhead, contain DNS query costs, and enforce network isolation policies that prevent direct VPC-to-VPC traffic except through approved channels.

Which of the following configurations represents the most architecturally sound and operationally efficient strategy to satisfy these requirements?

Associate the clinical.local PHZ with the Shared Services VPC. Create Route 53 Resolver Inbound and Outbound Endpoints in the Shared Services VPC. Create a forward rule for corp.internal pointing to the on-premises DNS servers, and associate it with the Shared Services VPC. For the Production and Dev/Test VPCs, modify their DHCP options sets to set the domain name servers to the IP addresses of the Route 53 Resolver Inbound Endpoints in the Shared Services VPC, and configure Transit Gateway route tables to allow DNS traffic on port 53 to those IPs.

In the Shared Services account, associate the clinical.local PHZ with the Shared Services VPC. Create Route 53 Resolver Inbound and Outbound Endpoints in the Shared Services VPC. Share the clinical.local PHZ with the Production and Dev/Test accounts using AWS Resource Access Manager (RAM) to automatically associate the zone with all VPCs. Create a Route 53 Resolver rule for corp.internal pointing to the on-premises DNS servers, associate the rule with the Shared Services VPC, and configure the workloads' DHCP options sets to point to the Inbound Endpoint IP addresses for all DNS resolution.

In the Shared Services account, associate the clinical.local PHZ with the Shared Services VPC. Create Route 53 Resolver Inbound and Outbound Endpoints in the Shared Services VPC. Authorize the association of the clinical.local PHZ with the Production and Dev/Test VPCs from the Shared Services account, and associate them using the Route 53 API in the respective workload accounts. Create a Route 53 Resolver rule for corp.internal pointing to the on-premises DNS servers, associate the rule with all three VPCs, and configure on-premises DNS servers to forward queries for clinical.local to the Inbound Endpoint IP addresses.

In the Shared Services account, associate the clinical.local PHZ with the Shared Services VPC. Create Route 53 Resolver Inbound and Outbound Endpoints in the Shared Services VPC. Set up a Resolver rule for corp.internal pointing to the on-premises DNS servers. Share and associate this rule with all three VPCs. Route all DNS traffic from the workload accounts to the on-premises network by associating a Direct Connect Gateway directly to each workload VPC using private virtual interfaces (Private VIFs) instead of using the Transit Gateway, bypassing the Shared Services VPC entirely for corporate queries.

Cevabı ve açıklamayı göster

Cevap: In the Shared Services account, associate the clinical.local PHZ with the Shared Services VPC. Create Route 53 Resolver Inbound and Outbound Endpoints in the Shared Services VPC. Authorize the association of the clinical.local PHZ with the Production and Dev/Test VPCs from the Shared Services account, and associate them using the Route 53 API in the respective workload accounts. Create a Route 53 Resolver rule for corp.internal pointing to the on-premises DNS servers, associate the rule with all three VPCs, and configure on-premises DNS servers to forward queries for clinical.local to the Inbound Endpoint IP addresses.

Cevap

The correct strategy involves associating the Private Hosted Zone with the workload VPCs using cross-account authorization APIs, sharing a centralized Route 53 Resolver Outbound rule for the corporate domain via AWS RAM, and forwarding on-premises DNS queries to centralized Route 53 Resolver Inbound Endpoints in the Shared Services VPC.

The correct strategy establishes cross-account PHZ associations for local VPC resolution of clinical.local domains, minimizing latency and query costs. Centrally created Route 53 Resolver Outbound Rules are shared using AWS Resource Access Manager (RAM) and associated with the workload VPCs, routing corporate queries to the on-premises DNS servers via the Outbound Endpoints. Centralized Inbound Endpoints handle incoming queries from the on-premises servers to resolve clinical.local domains. This pattern aligns with AWS Well-Architected guidelines for hybrid and multi-account DNS architecture.

Adım Adım Çözüm

Authorize the cross-account association of the Private Hosted Zone.

The Shared Services account owner creates an association authorization for the Production and Dev/Test VPCs using the Route 53 API.

Private Hosted Zones cannot be shared via AWS RAM or associated across accounts without explicit owner authorization.

Associate the Private Hosted Zone with the workload VPCs.

The Production and Dev/Test account owners accept the authorization and associate their VPCs with the clinical.local Private Hosted Zone.

This allows EC2 instances in those VPCs to resolve clinical.local domains locally using the Route 53 Resolver, avoiding cross-VPC Transit Gateway transit costs for local DNS queries.

Provision Route 53 Resolver Inbound and Outbound Endpoints.

Inbound and Outbound Resolver Endpoints are created in the Shared Services VPC across multiple Availability Zones.

Inbound endpoints receive DNS queries from the on-premises network. Outbound endpoints forward DNS queries to the on-premises DNS servers. Placing them in multiple AZs ensures high availability.

Create and share the Route 53 Resolver Rule.

A forwarding rule for corp.internal pointing to the on-premises DNS servers is created in the Shared Services account, shared via AWS Resource Access Manager (RAM), and associated with all three VPCs.

Sharing the resolver rule enables all three VPCs to resolve on-premises queries through the centralized Outbound Endpoints over the Transit Gateway.

Anahtar Kavram

Multi-Account and Hybrid DNS Architecture Strategy using Route 53 Resolver and Private Hosted Zone cross-account association.

Tahmini Süre:3m 0s

Soru 579Soru →

An enterprise manages its multi-account environment using AWS Organizations. The security team must establish a secure governance framework that centralizes the administration of Amazon GuardDuty and AWS Security Hub in a dedicated Security account. The framework must ensure that member accounts cannot disassociate themselves from the organization, disable these security services, or modify their centralized configurations, even if users in the member accounts have administrative or root privileges. Which TWO actions must the solutions architect take to implement this architecture? (Select TWO.)

Geçerli olan tümünü seçin

From the AWS Organizations management account, designate the Security account as the delegated administrator for Amazon GuardDuty and AWS Security Hub. From the Security account, enable both services for all organization member accounts and configure them to auto-enable for any new accounts.

Create a Service Control Policy (SCP) in the management account that denies organizations:LeaveOrganization, guardduty:DeleteDetector, guardduty:DisassociateFromMasterAccount, and securityhub:DisableSecurityHub. Attach this SCP to the Organizational Units (OUs) containing the member accounts.

Create an SCP that denies organizations:LeaveOrganization, guardduty:DeleteDetector, and securityhub:DisableSecurityHub, and attach it directly to the organization's management account to enforce these constraints globally, including on the management account itself.

From the Security account, configure AWS-managed KMS keys (e.g., aws/guardduty and aws/securityhub) to encrypt and share findings across the organization, delegating key administration permissions directly to member account root users.

Configure all member accounts to write their audit logs directly to a centralized S3 bucket in the Security account by updating each member account's local IAM policies to grant write permissions to the bucket, without modifying the Security account's S3 bucket policy.

Cevabı ve açıklamayı göster

Cevap: From the AWS Organizations management account, designate the Security account as the delegated administrator for Amazon GuardDuty and AWS Security Hub. From the Security account, enable both services for all organization member accounts and configure them to auto-enable for any new accounts.; Create a Service Control Policy (SCP) in the management account that denies organizations:LeaveOrganization, guardduty:DeleteDetector, guardduty:DisassociateFromMasterAccount, and securityhub:DisableSecurityHub. Attach this SCP to the Organizational Units (OUs) containing the member accounts.

Cevap

To secure the multi-account architecture, the solutions architect must designate the Security account as the delegated administrator for GuardDuty and Security Hub, and create an SCP in the management account restricting member accounts from disabling these services or leaving the organization, attaching it to the member Organizational Units.

To establish the required governance, the solutions architect must designate the Security account as the delegated administrator for GuardDuty and Security Hub, enabling central control. Additionally, an SCP must be created to block actions such as disabling the detectors, disassociating from the master, and leaving the organization. This SCP must be attached to the member OUs because SCPs apply only to member accounts, not the management account. Together, these actions ensure centralized operations and strict guardrails that cannot be bypassed by member account administrators.

Adım Adım Çözüm

Enable trusted access for GuardDuty and Security Hub in the AWS Organizations management account, and delegate administration to the Security account.

The Security account becomes the delegated administrator, allowing it to manage findings, members, and configurations centrally.

This isolates organizational management activities from security administration, conforming to the principle of least privilege.

Configure GuardDuty and Security Hub within the Security account to enable both services for all existing and new member accounts automatically.

All member accounts are enrolled under the delegated administrator.

This guarantees that security monitoring is consistently active across all workloads without requiring manual intervention.

Create an SCP that denies organizations:LeaveOrganization, guardduty:DeleteDetector, guardduty:DisassociateFromMasterAccount, and securityhub:DisableSecurityHub.

A policy definition is created that blocks these critical operations.

This establishes a hard guardrail that prevents local account administrators or root users from disabling security monitoring or detaching from the organization's governance.

Attach the created SCP to the Organizational Units (OUs) that contain the member accounts, avoiding the management account.

The guardrail takes effect on all member accounts, while leaving the management account unrestricted.

SCPs do not apply to the management account, so they must be applied at the OU level or the organization root to affect member accounts.

Anahtar Kavram

Multi-account security governance using AWS Organizations delegated administration and Service Control Policies (SCPs).

Soru 580Soru →

A global pharmaceutical research corporation is designing a hybrid DNS resolution strategy for its multi-account AWS environment. The network architecture uses a central hub-and-spoke topology, where spoke VPCs in multiple member accounts are connected via AWS Transit Gateway to a Shared Services VPC in a central networking account. An on-premises laboratory network is connected to the Transit Gateway using an AWS Direct Connect connection with a Transit Virtual Interface (Transit VIF).

A Private Hosted Zone (PHZ) named `aws.pharma.internal` is hosted in the Shared Services AWS account and associated with the Shared Services VPC. The on-premises network uses DNS servers hosting the zone `corp.local`. Spoke VPCs must be able to resolve resources in both `aws.pharma.internal` and `corp.local`. Additionally, on-premises hosts must be able to resolve resources in `aws.pharma.internal`.

Which of the following configurations represents the most secure and operationally efficient way to meet these requirements?

Share the `aws.pharma.internal` Private Hosted Zone directly with all spoke accounts using AWS Resource Access Manager (RAM). In each spoke account, associate the shared hosted zone with the local spoke VPCs. Create Route 53 Resolver Outbound Rules in the Shared Services account for `corp.local` pointing to on-premises DNS, share the rules via AWS RAM, and configure on-premises DNS forwarders to target a Route 53 Resolver Inbound Endpoint in the Shared Services VPC.

Associate the `aws.pharma.internal` Private Hosted Zone with the Shared Services VPC. In each spoke VPC, create Route 53 Resolver Outbound Rules that forward queries for `aws.pharma.internal` to the Route 53 Resolver Inbound Endpoint in the Shared Services VPC. To resolve `corp.local`, configure Route 53 Resolver Outbound Rules in each spoke account and route the DNS traffic to on-premises DNS servers directly over a Direct Connect Gateway (DXGW) public virtual interface, bypassing the Transit Gateway.

In the Shared Services account, authorize the association of the `aws.pharma.internal` Private Hosted Zone with each spoke VPC. In each member account, associate the spoke VPC with the Private Hosted Zone. In the Shared Services account, create a Route 53 Resolver Outbound Endpoint and a resolver rule for `corp.local` pointing to the on-premises DNS servers. Share the resolver rule with the member accounts using AWS Resource Access Manager (RAM) and associate it with each spoke VPC. Create a Route 53 Resolver Inbound Endpoint in the Shared Services VPC, and configure the on-premises DNS servers to forward queries for `aws.pharma.internal` to the inbound endpoint IP addresses.

In each member account, submit an association request to link the spoke VPCs with the `aws.pharma.internal` Private Hosted Zone directly. In the Shared Services account, create a Route 53 Resolver Outbound Endpoint and a resolver rule for `corp.local` pointing to the on-premises DNS servers. Associate the outbound rule directly with the Transit Gateway to automatically enable resolution for all spoke VPCs. Create a Route 53 Resolver Inbound Endpoint in the Shared Services VPC, and configure the on-premises DNS servers to forward queries for `aws.pharma.internal` to the inbound endpoint IP addresses.

Cevabı ve açıklamayı göster

Cevap: In the Shared Services account, authorize the association of the `aws.pharma.internal` Private Hosted Zone with each spoke VPC. In each member account, associate the spoke VPC with the Private Hosted Zone. In the Shared Services account, create a Route 53 Resolver Outbound Endpoint and a resolver rule for `corp.local` pointing to the on-premises DNS servers. Share the resolver rule with the member accounts using AWS Resource Access Manager (RAM) and associate it with each spoke VPC. Create a Route 53 Resolver Inbound Endpoint in the Shared Services VPC, and configure the on-premises DNS servers to forward queries for `aws.pharma.internal` to the inbound endpoint IP addresses.

Cevap

The correct answer is the configuration that authorizes cross-account Private Hosted Zone association, shares the outbound resolver rules via AWS Resource Access Manager (RAM), and configures inbound endpoints for on-premises forwarding.

To resolve private DNS names across different AWS accounts, a Private Hosted Zone must be associated with the target VPCs. Because the Private Hosted Zone is in a different account than the spoke VPCs, the owner account must first authorize the association, and then the spoke accounts must accept the association. For hybrid DNS resolution of the on-premises domain, Route 53 Resolver Outbound Endpoints and rules must be created in the hub/Shared Services VPC and shared with spoke accounts via AWS Resource Access Manager (RAM) to allow spoke VPCs to associate with the rules. On-premises DNS resolution of the private hosted zone is achieved by forwarding queries to Route 53 Resolver Inbound Endpoints in the Shared Services VPC over the established Direct Connect connection.

Adım Adım Çözüm

Establish cross-account Private Hosted Zone (PHZ) resolution for the spoke VPCs.

The Shared Services account owner authorizes the spoke VPCs to associate with the `aws.pharma.internal` PHZ, and each member account creates the association.

This allows instances in the spoke VPCs to resolve records in the PHZ directly and efficiently without traversing resolver endpoints.

Configure resolution of the on-premises `corp.local` domain from AWS.

An outbound resolver endpoint is created in the Shared Services VPC, an outbound rule for `corp.local` is defined pointing to on-premises DNS IPs, shared via RAM, and associated with all spoke VPCs.

This permits spoke VPCs to resolve on-premises hostnames over the Transit Gateway and Direct Connect connection.

Configure resolution of the `aws.pharma.internal` domain from on-premises.

An inbound resolver endpoint is created in the Shared Services VPC, and on-premises DNS forwarders are configured to route queries for `aws.pharma.internal` to the inbound endpoint IPs.

This enables on-premises clients to resolve AWS resources by querying the Route 53 Resolver over the Direct Connect transit virtual interface.

Anahtar Kavram

Multi-Account and Hybrid DNS Architecture Strategy

Tahmini Süre:2m 30s

ÖncekiSayfa 29 / 99Sonraki

Tüm alıştırma soruları

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram