23 Mar 2024 noon study
Last updated
Last updated
Question 7: Incorrect
A multinational consumer goods corporation structured their AWS accounts to use AWS Organizations, which consolidates payment of their multiple AWS accounts for their various Business Units (BU’s) namely Beauty products, Baby products, Health products, and Home Care products unit. One of their Solutions Architects for the Baby products business unit has purchased 10 Reserved Instances for their new Supply Chain application which will go live 3 months from now. However, they do not want their Reserved Instance (RI) discounts to be shared by the other business units. [-> Turn off RI sharing on master acc]
Which of the following options is the most suitable solution for this scenario?
Set the Reserved Instance (RI) sharing to private on the AWS account of the Baby products business unit.
Remove the AWS account of the Baby products business unit out of the AWS Organization.
Turn off the Reserved Instance (RI) sharing on the master account for all of the member accounts in the Baby products business unit.
(Correct)
Since the Baby product business unit is part of an AWS Organization, the Reserved Instances will always be shared across other member accounts. There is no way to disable this setting.(Incorrect)
Explanation
For billing purposes, the consolidated billing feature of AWS Organizations treats all the accounts in the organization as one account. This means that all accounts in the organization can receive the hourly cost-benefit of Reserved Instances that are purchased by any other account. In the payer account, you can turn off Reserved Instance discount sharing on the Preferences page on the Billing and Cost Management console.
The master account of an organization can turn off Reserved Instance (RI) sharing for member accounts in that organization. This means that Reserved Instances are not shared between that member account and other member accounts. You can change this preference multiple times. Each estimated bill is computed using the last set of preferences. However, take note that turning off Reserved Instance sharing can result in a higher monthly bill.
Hence, the correct answer is: Turn off the Reserved Instance (RI) sharing on the master account for all of the member accounts in the Baby products business unit.
The option that says: Set the Reserved Instance (RI) sharing to private on the AWS account of the Baby products business unit is incorrect because there is no "private" option in the RI and Savings Plan discount sharing settings in the Billing Management Console. By default, the member account doesn't have the capability to turn off RI sharing on their account.
The option that says: Remove the AWS account of the Baby products business unit out of the AWS Organization is incorrect because removing the Baby products business unit account from the AWS Organization is not the optimal solution to prevent the other account from sharing its RI discounts. You can simply turn off the Reserved Instance discount sharing in the payer account.
The option that says: Since the Baby product business unit is part of an AWS Organization, the Reserved Instances will always be shared across other member accounts. There is no way to disable this setting is incorrect because this statement is false. There is certainly a way to disable the current setting by simply turning off RI sharing.
References:
Check out this AWS Billing and Cost Management Cheat Sheet:
Question 15: Incorrect
An IT consulting company has multiple AWS accounts for its teams and departments that have been grouped into several organizational units (OUs) using AWS Organizations. The lead solutions architect received a report from the security team that there was a suspected breach in one of the environments wherein a third-party AWS account was suddenly added to the AWS Organization without any prior approval. [-> Control Tower, Inspector] The external account has high-level access privileges to the accounts that the company owns. Fortunately, no detrimental action was performed yet.
Which of the following actions should the solutions architect take to properly set up a monitoring system that notifies for any changes [-> CloudTrail, SNS] to the company AWS accounts? (Select TWO.)
Create a trail in Amazon CloudTrail to capture all API calls to your AWS Organizations, including calls from the AWS Organizations console and from code calls to the AWS Organizations APIs. Use Amazon EventBridge and SNS to raise events when administrator-specified actions occur in an organization and send a notification to you.
(Correct)
Set up a CloudWatch Dashboard to monitor any changes to your organizations and create an SNS topic that would send you a notification.
Configure AWS Control Tower to manage and monitor all child accounts under the organization. Use Amazon Inspector to analyze any possible breach and notify the administrators using AWS SNS.
(Incorrect)
Monitor all changes to your organization using Systems Manager and use Amazon EventBridge to notify you of any new activity to your account.
Use AWS Config to monitor the compliance of your AWS Organizations. Set up an SNS Topic or Amazon EventBridge that will send alerts to you for any changes.
(Correct)
Explanation
AWS Organizations can work with CloudWatch Events to raise events when administrator-specified actions occur in an organization. For example, because of the sensitivity of such actions, most administrators would want to be warned every time someone creates a new account in the organization or when an administrator of a member account attempts to leave the organization. You can configure CloudWatch Events rules that look for these actions and then send the generated events to administrator-defined targets. Targets can be an Amazon SNS topic that emails or text messages its subscribers. Combining this with Amazon CloudTrail, you can set an event to trigger whenever a matching API call is received.
x1
Therefore, the following options are the correct answers:
- Create a trail in Amazon CloudTrail to capture all API calls to your AWS Organizations, including calls from the AWS Organizations console and from code calls to the AWS Organizations APIs. Use Amazon EventBridge and SNS to raise events when administrator-specified actions occur in an organization and send a notification to you.
- Use AWS Config to monitor the compliance of your AWS Organizations. Set up an SNS Topic or Amazon EventBridge that will send alerts to you for any changes.
The option that says: Monitor all changes to your organization using Systems Manager and use Amazon EventBridge to notify you of any new activity to your account is incorrect. AWS Systems Manager is a collection of capabilities for configuring and managing your Amazon EC2 instances, on-premises servers and virtual machines, and other AWS resources at scale. This can't be used to monitor the changes to the setup of AWS Organizations.
The option that says: Setting up a CloudWatch Dashboard to monitor any changes to your organizations and creating an SNS topic that would send you a notification is incorrect because a CloudWatch Dashboard is primarily used to monitor your AWS resources and not the configuration of your AWS Organizations. Although you can enable sharing of all CloudWatch Events across all accounts in your organization, this can't be used to monitor if there is a new AWS account added to your AWS Organizations. Most of the time, the Amazon EventBridge service is primarily used to monitor your AWS resources and the applications you run on AWS in real-time.
The option that says: Configure AWS Control Tower to manage and monitor all child accounts under the organization. Use Amazon Inspector to analyze any possible breach and notify the administrators using AWS SNS is incorrect. AWS Control Tower can send logs to CloudWatch and CloudTrail for monitoring AWS accounts in the organization. However, Amazon Inspector is used as an automated vulnerability management service that continually scans AWS workloads for software vulnerabilities, not for monitoring events on individual AWS accounts.
References:
Check out these AWS Organizations and AWS Config Cheat Sheets:
Question 16: Incorrect
A media company hosts its entire infrastructure on the AWS cloud. There is a requirement to copy information to or from the shared resources from another AWS account. The solutions architect has to provide the other account access to several AWS resources such as Amazon S3, AWS KMS, and Amazon ES in the form of a list of AWS account ID numbers. In addition, the user in the other account should still work in the trusted account and there is no need to give up his or her user permissions in place of the role permissions [-> cross-account access with user-based policy config]. The solutions architect must also set up a solution that continuously assesses, audits, and monitors the policy configurations.[-> CloudTrail (wrong), AWS Config]
Which of the following is the MOST suitable type of policy that you should use in this scenario?
Set up a service-linked role with a service control policy. Use AWS Systems Manager rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration.
Set up cross-account access with a user-based policy configuration. Use AWS Config rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration.
(Incorrect)
Set up a service-linked role with an identity-based policy. Use AWS Systems Manager rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration.
Set up cross-account access with a resource-based Policy. Use AWS Config rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration.
(Correct)
Explanation
For some AWS services, you can grant cross-account access to your resources. To do this, you attach a policy directly to the resource that you want to share, instead of using a role as a proxy. The resource that you want to share must support resource-based policies. Unlike a user-based policy, a resource-based policy specifies who (in the form of a list of AWS account ID numbers) can access that resource.
Cross-account access with a resource-based policy has some advantages over a role. With a resource that is accessed through a resource-based policy, the user still works in the trusted account and does not have to give up his or her user permissions in place of the role permissions. In other words, the user continues to have access to resources in the trusted account at the same time as he or she has access to the resource in the trusting account. This is useful for tasks such as copying information to or from the shared resource in the other account.
AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. Config continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of recorded configurations against desired configurations.
Hence, the option that says: Set up cross-account access with a resource-based Policy. Use AWS Config rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration is correct.
The option that says: Set up cross-account access with a user-based policy. configuration. Use AWS Config rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration is incorrect because a user-based policy maps the access to a certain IAM user and not to a certain AWS resource.
The option that says: Set up a service-linked role with an identity-based policy. Use AWS Systems Manager rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration is incorrect because a service-linked role is just a unique type of IAM role that is linked directly to an AWS service. In addition, it is the AWS Config service, and not the AWS Systems Manager, that enables you to assess, audit, and evaluate the configurations of your AWS resources.
The option that says: Set up a service-linked role with a service control policy. Use AWS Systems Manager rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration is incorrect because a service control policy is primarily used in AWS Organizations and not for cross-account access. Service-linked roles are predefined by the service and include all the permissions that the service requires to call other AWS services on your behalf. This is not suitable for providing access to your resources to other AWS accounts, unlike cross-account access. You should also use AWS Config, and not AWS Systems Manager, to periodically audit changes to the IAM policy.
References:
Check out this AWS Config Cheat Sheet:
Question 35: Correct
A company has created multiple accounts in AWS to support the rapid growth of its cloud services. The multiple accounts are used to separate their various departments such as finance, human resources, engineering, and many others. Each account is managed by a Systems Administrator which has root access [->IAM] for that specific account only. There is a requirement to centrally manage policies across multiple AWS accounts [-> AWS Org; SCP] by allowing or denying particular AWS services for individual accounts, or for groups of accounts.
Which is the most suitable solution that you should implement with the LEAST amount of complexity?
Use AWS Organizations and Service Control Policies to control the list of AWS services that can be used by each member account.
(Correct)
Provide access to externally authenticated users via Identity Federation. Set up an IAM role to specify permissions for users from each department whose identity is federated from your organization or a third-party identity provider.
Connect all departments by setting up cross-account access to each of the AWS accounts of the company. Create and attach IAM policies to your resources based on their respective departments to control access.
Set up AWS Organizations and Organizational Units (OU) to connect all AWS accounts of each department. Create a custom IAM Policy to allow or deny the use of certain AWS services for each account.
Explanation
AWS Organizations offers policy-based management for multiple AWS accounts. With Organizations, you can create groups of accounts, automate account creation, and apply and manage policies for those groups. Organizations enables you to centrally manage policies across multiple accounts, without requiring custom scripts and manual processes. It allows you to create Service Control Policies (SCPs) that centrally control AWS service use across multiple AWS accounts.
Remember that AWS Organizations does not replace associating IAM policies with users, groups, and roles within an AWS account. Hence, you still need to set up appropriate IAM policies for your root and member accounts.
IAM policies let you allow or deny access to AWS services (such as Amazon S3), individual AWS resources (such as a specific S3 bucket), or individual API actions (such as s3:CreateBucket). An IAM policy can be applied only to IAM users, groups, or roles, and it can never restrict the root identity of the AWS account.
By contrast, AWS Organizations lets you use service control policies (SCPs) to allow or deny access to particular AWS services for individual AWS accounts, or for groups of accounts within an organizational unit (OU). The specified actions from an attached SCP affect all IAM users, groups, and roles for an account, including the root account identity.
When you apply an SCP to an OU or an individual AWS account, you choose to either enable (whitelist), or disable (blacklist) the specified AWS service. Access to any service that isn’t explicitly allowed by the SCPs associated with an account, its parent OUs, or the master account is denied to the AWS accounts or OUs associated with the SCP. When an SCP is applied to an OU, it is inherited by all of the AWS accounts in that OU.
Therefore, the correct answer is: Use AWS Organizations and Service Control Policies to control the list of AWS services that can be used by each member account.
The option that says: Setting up AWS Organizations and Organizational Units (OU) to connect all AWS accounts of each department and creating a custom IAM Policy to allow or deny the use of certain AWS services for each account is incorrect. Although it is correct to use AWS Organizations, this option is incorrect about IAM Policy. It is the Service Control Policy (SCP) which enables you to allow or deny the use of certain AWS services for each account, and not the IAM Policy.
The option that says: Connecting all departments by setting up cross-account access to each of the AWS accounts of the company, then creating and attaching IAM policies to your resources based on their respective departments to control access is incorrect. Although you can set up cross-account access to each department, this entails a lot of configuration compared with using AWS Organizations and Service Control Policies (SCPs). Cross-account access would be a more suitable choice if you only have two accounts to manage, but not for multiple accounts.
The option that says: Providing access to externally authenticated users via Identity Federation and setting up an IAM role to specify permissions for users from each department whose identity is federated from your organization or a third-party identity provider is incorrect. This option is focused on the Identity Federation authentication set up for your AWS accounts but not the IAM policy management for multiple AWS accounts. A combination of AWS Organizations and Service Control Policies (SCPs) is a better choice compared to this option.
References:
Check out this AWS Organizations Cheat Sheet:
