27 Mar 2024 noon study
Last updated
Last updated
Question 2: Skipped
An AWS Partner company hosts all its infrastructure on the AWS cloud. All resources are currently deployed in the us-east-1 region. The company plans to expand its business to include deployments in Europe and Asia. The solutions architect has been tasked to provision the needed resources on multiple regions across multiple AWS accounts under the company’s AWS Organization. [-> CloudFormation]
Which of the following options is the recommended solution to meet the company requirements?
Write infrastructure-as-code to maintain consistency. Create nested stacks with AWS CloudFormation templates and use global parameters to specify which target region and accounts to provision the needed resources.
Write infrastructure-as-code to maintain consistency. Use AWS Organizations to centrally orchestrate the deployment of AWS CloudFormation template from the central account. Use CloudFormation StackSets to simplify permissions and automatic provisioning of resources across multiple regions and accounts.
(Correct)
Use AWS Organizations to centrally manage the deployment of AWS CloudFormation template from the central account. Use AWS Control Tower as an orchestration layer deploying resources across multiple accounts and regions.
Write infrastructure-as-code to maintain consistency. Create AWS CloudFormation templates and create IAM policies to control multiple accounts. Use regional parameters when deploying CloudFormation templates across multiple regions to provision the needed resources.
Explanation
AWS CloudFormation StackSets allow you to roll out CloudFormation stacks over multiple AWS accounts and in multiple Regions with just a couple of clicks. With AWS Organizations, you can centrally manage multiple AWS accounts across diverse business needs including billing, access control, compliance, security and resource sharing.
Using AWS Organizations you can centrally orchestrate any AWS CloudFormation enabled service across multiple AWS accounts and regions. For example, you can deploy your centralized AWS Identity and Access Management (IAM) roles, provision Amazon Elastic Compute Cloud (Amazon EC2) instances or AWS Lambda functions across AWS Regions and accounts in your organization. CloudFormation StackSets simplify the configuration of cross-accounts permissions and allow for automatic creation and deletion of resources when accounts are joining or are removed from your Organization.
You can get started by enabling data sharing between CloudFormation and Organizations from the StackSets console. Once done, you will be able to use StackSets in the Organizations master account to deploy stacks to all accounts in your organization or in specific organizational units (OUs).
Therefore, the correct answer is: Write infrastructure-as-code to maintain consistency. Use AWS Organizations to centrally orchestrate the deployment of AWS CloudFormation template from the central account. Use CloudFormation StackSets to simplify permissions and automatic provisioning of resources across multiple regions and accounts. With AWS Organizations, you can centrally orchestrate any AWS CloudFormation enabled service across multiple AWS accounts and regions.
The option that says: Write infrastructure-as-code to maintain consistency. Create AWS CloudFormation templates and create IAM policies to control multiple accounts. Use regional parameters when deploying CloudFormation templates across multiple regions to provision the needed resources is incorrect. This is not recommended as it entails more operational overhead. It is recommended to use CloudFormation StackSets to deploy stack across multiple regions and accounts in a single operation.
The option that says: Use AWS Organizations to centrally manage the deployment of AWS CloudFormation template from the central account. Use AWS Control Tower as an orchestration layer deploying resources across multiple accounts and regions is incorrect. It is possible to use AWS Control Tower as an orchestration layer for multi-account environments. However, for this solution to work, you still need to create CloudFormation StackSets for deployment on multiple regions.
The option that says: Write infrastructure-as-code to maintain consistency. Create nested stacks with AWS CloudFormation templates and use global parameters to specify which target region and accounts to provision the needed resources is incorrect. This is not possible, if you want to deploy CloudFormation stacks on multiple regions and accounts in a single operation, you should use CloudFormation StackSets.
References:
Check out these AWS Organizations and AWS CloudFormation Sheet:
Question 25: Skipped
A large company has multiple AWS accounts [-> Org] with multiple IAM Users that launch different types of Amazon EC2 instances and EBS volumes every day. As a result, most accounts quickly hit the service limit and IAM users can no longer create any new instances. When cleaning up the AWS accounts, the solutions architect noticed that the majority of the instances and volumes are untagged. Therefore, it is difficult to pinpoint the owner of these resources and verify if they are safe to terminate. Because of this, the management had issued a new protocol that requires adding a predefined set of tags [-> SCP] before anyone can launch their EC2 instances.
Which of the following options is the simplest way to enforce this new requirement?
Configure AWS Organizations to group different accounts into separate Organizational Units (OU) depending on the business function. Create a Service Control Policy that restricts launching any AWS resources without a tag by including the Condition element in the policy which uses the ForAllValues qualifier and the aws:TagKeys condition. This policy will require its principals to tag resources during creation. Apply the SCP to the OU which will automatically cascade the policy to individual member accounts.
(Correct)
Apply an IAM policy to the individual member accounts of the OU that includes a Condition element in the policy containing the ForAllValues qualifier and the aws:TagKeys condition. This policy will require its principals to attach specific tags to their resources during creation.
Configure AWS Organizations to group different accounts into separate Organizational Units (OU) depending on the business function. Create a rule in AWS Config requiring users to tag specific resources and raise an alert whenever the rule is violated. The Config Rule should allow a user to launch EC2 instances only if the user adds all the tags defined in the rule. If the user applies any other tag then the action is denied.
Configure AWS Organizations to group different accounts into separate Organizational Units (OU) depending on the business function. Create a rule using AWS Systems Manager requiring users to tag specific resources and raise an alert whenever the rule is violated. This will allow a user to launch EC2 instances only if certain tags were defined. If the user applies any other tag then the action is denied.
Explanation
You can specify tags for EC2 instances and EBS volumes as part of the API call that creates the resources. Using this principle, you can require users to tag specific resources by applying conditions to their IAM policy. Using AWS Organizations, you can consolidate all of your AWS accounts and group the business units into separate Organizational Units (OUs) with a custom service control policy (SCP).
You can configure your IAM policy to allow a user to launch an EC2 instance and create an EBS volume only if the user applies all the tags that are defined in the policy using the ForAllValues qualifier. If the user applies any tag that's not included in the policy then the action is denied. To enforce case sensitivity, use the condition aws:TagKeys.
You can use organizational units (OUs) to group accounts together to administer as a single unit. This greatly simplifies the management of your accounts. For example, you can attach a policy-based control to an OU, and all accounts within the OU automatically inherit the policy. You can create multiple OUs within a single organization, and you can create OUs within other OUs.
Therefore, the correct answer is: Configure AWS Organizations to group different accounts into separate Organizational Units (OU) depending on the business function. Create a Service Control Policy that restricts launching any AWS resources without a tag by including the Condition element in the policy which uses the ForAllValues qualifier and the aws:TagKeys condition. This policy will require its principals to tag resources during creation. Apply the SCP to the OU which will automatically cascade the policy to individual member accounts.
The option that says: Apply an IAM policy to the individual member accounts of the OU that includes a Condition element in the policy containing the ForAllValues qualifier and the aws:TagKeys condition. This policy will require its principals to attach specific tags to their resources during creation is incorrect as it requires a lot of effort to implement the policy in each and every AWS account of the organization. You should set up AWS Organizations, group different accounts into separate Organizational Units (OU), and use SCP instead.
The option that says: Configure AWS Organizations to group different accounts into separate Organizational Units (OU) depending on the business function. Create a rule in AWS Config requiring users to tag specific resources and raise an alert whenever the rule is violated. The Config Rule should allow a user to launch EC2 instances only if the user adds all the tags defined in the rule. If the user applies any other tag then the action is denied is incorrect. AWS Config only audits and evaluates if your instance and volume configurations match the rules you have created. Unlike an IAM policy, it does not permit nor restrict users from performing certain actions.
The option that says: Configure AWS Organizations to group different accounts into separate Organizational Units (OU) depending on the business function. Create a rule using AWS Systems Manager requiring users to tag specific resources and raise an alert whenever the rule is violated. This will allow a user to launch EC2 instances only if certain tags were defined. If the user applies any other tag then the action is denied is incorrect because you cannot create a rule using AWS Systems Manager requiring users to tag specific resources and raise an alert whenever the rule is violated. You have to use an IAM policy in order to do this.
References:
Check out this AWS IAM Cheat Sheet:
Service Control Policies (SCP) vs IAM Policies:
Comparison of AWS Services Cheat Sheets:
Question 70: Skipped
A multinational bank has recently set up AWS Organizations to manage its several AWS accounts from their various business units. The Senior Solutions Architect attached the SCP below to an Organizational Unit (OU) to define the services that its member accounts can use:
{"Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":["EC2:","S3:"], "Resource":"*" } ] }
In one of the member accounts under that OU, an IAM user tried to create a new S3 bucket but was getting a permission denied error.
Which of the following options is the most likely cause of this issue?
An IAM policy that allows the use of S3 and EC2 services should be the one attached in the OU instead of an SCP.
The IAM user in the member account does not have IAM policies that explicitly grant EC2 or S3 service actions.
(Correct)
You should use the root user of the account to be able to create the new S3 bucket.
All accounts within the OU does not automatically inherit the policy attached to them. You still have to manually attach the SCP to the individual AWS accounts of the OU.
Explanation
A service control policy (SCP) determines what services and actions can be delegated by administrators to the users and roles in the accounts that the SCP is applied to. An SCP does not grant any permissions. Instead, SCPs are JSON policies that specify the maximum permissions for an organization or organizational unit (OU). The SCP limits permissions for entities in member accounts, including each AWS account root user.
If the SCP allows the actions for a service, the administrator of the account can grant permissions for those actions to the users and roles in that account, and the users and roles can perform the actions of the administrators grant those permissions. If the SCP denies actions for a service, the administrators in that account can't effectively grant permissions for those actions, and the users and roles in the account can't perform the actions even if granted by an administrator.
Users and roles must still be granted permissions using IAM permission policies attached to them or to groups. The SCPs filter the permissions granted by such policies, and the user can't perform any actions that the applicable SCPs don't allow. Actions allowed by the SCPs can be used if they are granted to the user or role by one or more IAM permission policies. Take note that the IAM user being used by the administrator does not have IAM policies that explicitly grant EC2 or S3 service actions.
Hence, the correct answer is: The IAM user in the member account does not have IAM policies that explicitly grant EC2 or S3 service actions.
The option that says: All accounts within the OU does not automatically inherit the policy attached to them. You still have to manually attach the SCP to the individual AWS accounts of the OU is incorrect because an SCP attached to an OU is automatically inherited by all accounts within that same OU. The main cause of this issue is the missing IAM policy in the account, which explicitly grants EC2 or S3 service actions to the IAM user.
The option that says: An IAM policy that allows the use of S3 and EC2 services should be the one attached in the OU instead of an SCP is incorrect because you cannot directly assign an IAM policy to an OU. In addition, there is no attached IAM policy that allows EC2 or S3 service actions to the IAM user.
The option that says: Using the root user of the account to be able to create the new S3 bucket is incorrect because SCPs do affect the root user along with all IAM users and standard IAM roles in any affected account. The issue lies in the missing IAM policy of the account and not with the SCP, OU, or its AWS Organizations settings.
References:
Check out these AWS Cheat Sheets:
