26 Mar 2024 morning study
Last updated
Last updated
Question 8: Skipped
A large software company has an on-premises LDAP server and a web application hosted on its VPC in AWS. The solutions architect has established an IPSec VPN connection between the AWS VPC and the company’s on-premises network. [ Direct Connect?] The company wants to enable employees to access the web application and other AWS resources using the same corporate account used inside the company network.
Which of the following actions should the solutions architect implement to achieve the company requirements? (SELECT TWO.)
Launch an identity broker that authenticates against LDAP server and then calls STS to get IAM federated user credentials. Configure the web application to call the identity broker that you created to get IAM federated user credentials with access to the appropriate AWS service.(Correct)
Integrate the on-premises LDAP server with IAM so the users can log into IAM using their corporate LDAP credentials. Once authenticated, they can use the temporary credentials to access any AWS resource.
Configure the web application to authenticate against the on-premises LDAP server and retrieve the name of an IAM role associated with the user. The application then calls the STS to assume that IAM role. The application can use the temporary credentials to access any AWS resource.
(Correct)
Create an identity broker that authenticates against STS to assume an IAM role to generate temporary AWS security credentials. For user authentication, configure the web application to call the identity broker to get AWS temporary security credentials.
Explanation
If your identity store is not compatible with SAML 2.0, then you can build a custom identity broker application to perform a similar function. The broker application authenticates users, requests temporary credentials for users from AWS, and then provides them to the user to access AWS resources.
To enable corporate employees to access the company's AWS resources, you can develop a custom identity broker application. The application verifies that employees are signed into the existing identity and authentication system of the company (which might use LDAP, Active Directory, or another system). The identity broker application then obtains temporary security credentials for the employees. To get temporary security credentials, the identity broker application calls either the AssumeRole or GetFederationToken actions in STS to obtain temporary security credentials.
The option that says: Configure the web application to authenticate against the on-premises LDAP server and retrieve the name of an IAM role associated with the user. The application then calls the STS to assume that IAM role. The application can use the temporary credentials to access any AWS resource is correct as it properly authenticates users using LDAP, gets the security token from STS, and then accesses the S3 bucket using the temporary credentials.
The option that says: Launch an identity broker that authenticates against LDAP server and then calls STS to get IAM federated user credentials. Configure the web application to call the identity broker that you created to get IAM federated user credentials with access to the appropriate AWS service is correct as it properly provides access to the users using STS and IAM. You can develop an identity broker that authenticates users against LDAP then gets the temporary security token from STS, which can be used to access the S3 bucket using the IAM federated user credentials.
The option that says: Create an identity broker that authenticates against STS to assume an IAM role to generate temporary AWS security credentials. For user authentication, configure the web application to call the identity broker to get AWS temporary security credentials is incorrect as the users need to be authenticated using LDAP first and not via STS. In addition, the temporary credentials to log into AWS should be provided by STS and not the identity broker.
The option that says: Integrate the on-premises LDAP server with IAM so the users can log into IAM using their corporate LDAP credentials. Once authenticated, they can use the temporary credentials to access any AWS resource is incorrect as you cannot use the LDAP credentials to log into IAM.
Reference:
Check out this AWS IAM Cheat Sheet:
Question 11: Skipped
A retail company has several subsidiaries with offices located in different countries in Southeast Asia. Each subsidiary has an AWS account that is used for hosting the company retail website, which is customized per country. The parent company wants to have better control on all the AWS accounts [-> Organization, Control Tower] as well as visibility on the costs incurred for each account. The Solutions Architect has been tasked to implement a solution that will satisfy the following requirements:
- Provide a cost breakdown report for each subsidiary AWS account. [-> Org]
- Have a single AWS invoice for all the subsidiary AWS accounts. [-> Org]
- Provide full administration privileges on each subsidiary AWS account, regardless of the parent company’s policy. [-> Control Tower]
- Have the ability to restrict the services and features that can be used on each subsidiary AWS account, as defined by the parent company’s policy. [-> SCP]
Which of the following actions should the Solutions Architect take in order to fulfill the requirements? (Select TWO.)
Define service quotas that will restrict services and features depending on the permissions set by the parent company policy. Apply this service quota to each subsidiary AWS account.
Create an AWS account for the parent company and create a single AWS Organization with the Consolidated Billing features set. Invite each of the subsidiary AWS accounts to join the AWS Organization of the parent company.
Create an AWS account for the parent company and create an AWS organization for each of the subsidiaries. Invite each of the subsidiary AWS Accounts to join their respective AWS organization on the parent company.
Create an AWS Organization on the parent company's AWS account and invite all the subsidiary AWS accounts. Ensure that All features set is enabled.
(Correct)
Define Service Control Policy (SCP) documents to only allow services and features defined by the parent company policy. Apply the necessary SCP for each subsidiary AWS account.
(Correct)
Explanation
AWS Organizations helps you centrally manage and govern your environment as you grow and scale your AWS resources. Using AWS Organizations, you can programmatically create new AWS accounts and allocate resources, group accounts to organize your workflows, apply policies to accounts or groups for governance, and simplify billing by using a single payment method for all of your accounts.
AWS Organizations has two available feature sets:
All features – The default feature set that is available to AWS Organizations. It includes all the functionality of consolidated billing, plus advanced features such as applying Service control policies (SCPs) to restrict the services and actions that users (including the root user) and roles in an account can access.
Consolidated billing – This feature set provides shared billing functionality, but doesn't include the more advanced features of AWS Organizations. For example, you can't enable other AWS services to integrate with your organization to work across all of its accounts or use policies to restrict what users and roles in different accounts can do. To use the advanced AWS Organizations features, you must enable all features in your organization.
Once you’ve created the organization and verified your email, you can create or invite other accounts into your organization, categorize the accounts into Organizational Units (OUs), create service control policies (SCPs), and take advantage of the Organization's features from supported AWS services.
The consolidated billing feature in AWS Organizations is used to consolidate billing and payment for multiple AWS accounts or multiple Amazon Internet Services Pvt. Ltd (AISPL) accounts. Every organization in AWS Organizations has a management account that pays the charges of all the member accounts.
Consolidated billing has the following benefits:
One bill – You get one bill for multiple accounts.
Easy tracking – You can track the charges across multiple accounts and download the combined cost and usage data.
Combined usage – You can combine the usage across all accounts in the organization to share the volume pricing discounts, Reserved Instance discounts, and Savings Plans. This can result in a lower charge for your project, department, or company than with individual standalone accounts.
No extra fee – Consolidated billing is offered at no additional cost.
With consolidated billing, the management account is billed for all charges of the member accounts. However, unless the organization is changed to support all features in the organization (not consolidated billing features only) and member accounts are explicitly restricted by policies, each member account is otherwise independent of the other member accounts. For example, the owner of a member account can sign up for AWS services, access resources, and use AWS Premium Support unless the management account restricts those actions. Each account owner continues to use their own IAM user name and password, with account permissions assigned independently of other accounts in the organization.
The option that says: Create an AWS Organization on the parent company's AWS account and invite all the subsidiary AWS accounts. Ensure that All features set is enabled. is correct. Consolidated billing allows the management account owner to have only one invoice for all accounts in the organization. And by default, each member account is independent of the other member accounts, so each subsidiary has full administration privileges unless controlled by the parent account.
The option that says: Define Service Control Policy (SCP) documents to only allow services and features defined by the parent company policy. Apply the necessary SCP for each subsidiary AWS account is correct. This satisfies the requirement for restricting access to the subsidiary AWS accounts as defined by the parent AWS account.
The option that says: Create an AWS account for the parent company and create an AWS Organization for each of the subsidiaries. Invite each of the subsidiary AWS accounts to join their respective AWS organization on the parent company is incorrect. You only have to create a single organization and link the member accounts.
The option that says: Define service quotas that will restrict services and features depending on the permissions set by the parent company policy. Apply this service quota to each subsidiary AWS account is incorrect. Applying service quota will not restrict the member accounts from using AWS services or features that are not permitted by the parent account. Service quota only restricts how much you can use for a particular service.
The option that says: Create an AWS account for the parent company and create a single AWS Organization with the Consolidated Billing features set. Invite each of the subsidiary AWS accounts to join the AWS Organization of the parent company is incorrect. Although creating an AWS organization is necessary, using only the Consolidated Billing features set is not enough to satisfy the requirements. Even though "All Features" is enabled by default, this will be overridden if you enable only the "Consolidated Billing" feature. This means that you cannot use the SCP to your member AWS accounts anymore. You need to enable "All features" on the AWS Organization to be able to create and apply SCP for each subsidiary.
References:
Check out this AWS Organizations Cheat Sheet:
Question 19: Skipped
A multinational manufacturing company has multiple AWS accounts in multiple AWS regions across North America, Europe, and Asia. The solutions architect has been tasked to set up AWS Organizations to centrally manage policies and have full administrative control across the multiple AWS accounts owned by the company, without requiring custom scripts and manual processes. [-> Org with All Features (default) OrganizationAccountAccessRole IAM role ]
Which of the following options is the recommended implementation to achieve this requirement with the LEAST effort?
Use AWS Control Tower from the master account and enroll all the member AWS accounts of the company. AWS Control Tower will automatically provision the needed IAM permissions to have full administrative control across all member accounts.
Set up AWS Organizations by sending an invitation to the master account of your organization from each of the member accounts of the company. Create an OrganizationAccountAccessRole IAM role in the member account and grant permission to the master account to assume the role.
Set up AWS Organizations by establishing cross-account access from the master account to all member AWS accounts of the company. The master account will automatically have full administrative control across all member accounts.
Set up AWS Organizations by sending an invitation to all member accounts of the company from the master account of your organization. Create an OrganizationAccountAccessRole IAM role in the member account and grant permission to the master account to assume the role.
(Correct)
Explanation
After you create an Organization and verify that you own the email address associated with the master account, you can invite existing AWS accounts to join your organization. When you invite an account, AWS Organizations sends an invitation to the account owner, who decides whether to accept or decline the invitation. You can use the AWS Organizations console to initiate and manage invitations that you send to other accounts. You can send an invitation to another account only from the master account of your organization.
If you are the administrator of an AWS account, you also can accept or decline an invitation from an organization. If you accept, your account becomes a member of that organization. Your account can join only one organization, so if you receive multiple invitations to join, you can accept only one.
When an invited account joins your organization, you do not automatically have full administrator control over the account, unlike created accounts. If you want the master account to have full administrative control over an invited member account, you must create the OrganizationAccountAccessRole IAM role in the member account and grant permission to the master account to assume the role.
Therefore, the correct answer is: Set up AWS Organizations by sending an invitation to all member accounts of the company from the master account of your organization. Create an OrganizationAccountAccessRole IAM role in the member account and grant permission to the master account to assume the role.
The option that says: Set up AWS Organizations by establishing cross-account access from the master account to all member AWS accounts of the company. The master account will automatically have full administrative control across all member accounts is incorrect. Cross-account access is primarily used for scenarios where you need to grant your IAM users permission to switch to roles within your AWS account or to roles defined in other AWS accounts that you own.
The option that says: Set up AWS Organizations by sending an invitation to the master account of your organization from each of the member accounts of the company. Create an OrganizationAccountAccessRole IAM role in the member account and grant permission to the master account to assume the role is incorrect. It entails a lot of effort to send an individual invitation to the master account from each of the member accounts of the company. It's stated in the scenario that you should achieve this requirement with the LEAST effort, and you can do this by sending an invitation to all member accounts of the company from the master account of your organization.
The option that says: Use AWS Control Tower from the master account and enroll all the member AWS accounts of the company. AWS Control Tower will automatically provision the needed IAM permissions to have full administrative control across all member accounts is incorrect. AWS Control Tower can be used to set up and manage multiple AWS accounts. However, it will not automatically provision IAM permissions for all member accounts.
References:
Check out this AWS Organizations Cheat Sheet:
Question 25: Skipped
A multinational corporation has recently acquired a smaller company. The solutions architect was instructed to consolidate the multiple AWS accounts of both entities using AWS Organizations. The solutions architect has set up the required service control policies (SCPs) to simplify the process of controlling access permissions for each individual account and Organizational Units (OUs). However, one account is having trouble creating a new S3 bucket, and it is required to investigate the cause of this issue. The account has the following SCP attached:
{"Version": "2012-10-17","Statement": [ { "Effect": "Allow", "Action": "cloudtrail:", "Resource": "" }, { "Effect": "Allow", "Action": "iam:", "Resource": "" } ]}
Each IAM user of the account has the following IAM policy attached:
{"Version": "2012-10-17","Statement": [ { "Effect": "Allow", "Action": "s3:", "Resource": [ "arn:aws:s3:::"]}, { "Effect": "Deny", "NotAction": "s3:", "NotResource": [ "arn:aws:s3:::" ] } ]}
Based on the provided SCP and IAM policy, which of the following options could be the possible root cause of this problem?
The IAM policy is the root cause because you have denied user permissions to execute any S3-related actions.
The SCP is the root cause since it does not explicitly allow the required action that would enable the account to create an S3 bucket.
(Correct)
The SCP is the root cause because it does not support whitelisting actions of the AWS resources.
Both the IAM policy and the SCP are the problem. The SCP should explicitly allow S3 bucket creation in its policy and the IAM policy should exactly match the permissions of the SCP.
Explanation
A service control policy (SCP) is a policy that specifies the services and actions that users and roles can use in the specified AWS accounts. SCPs are similar to IAM permission policies except that they don't grant any permissions. Instead, SCPs specify the maximum permissions for an organization, organizational unit (OU), or account. When you attach an SCP to your organization root or an OU, the SCP limits permissions for entities in member accounts. Even if a user is granted full administrator permissions with an IAM permission policy, any access that is not explicitly allowed or that is explicitly denied by the SCPs affecting that account is blocked.
For example, if you assign an SCP that allows only database service access to your "database" account, then any user, group, or role in that account is denied access to any other service's operations. SCPs are available only when you enable all features in your organization.
By default, an SCP named FullAWSAccess is attached to every root, OU, and account. This default SCP allows all actions and all services. So in a new organization, until you start creating or manipulating the SCPs, all of your existing IAM permissions continue to operate as they did. As soon as you apply a new or modified SCP to a root or OU that contains an account, the permissions that your users have in that account become filtered by the SCP. Permissions that used to work might now be denied if they're not allowed by the SCP at every level of the hierarchy down to the specified account.
Therefore, the correct answer is: The SCP is the root cause since it does not explicitly allow the required action that would enable the account to create an S3 bucket. The default service policy was changed which means that you would need to explicitly allow your account access to S3 to be able to create buckets. By removing the default FullAWSAccess SCP, all actions for all services are now implicitly denied. To use SCPs as a whitelist, you must replace the AWS-managed FullAWSAccess SCP with an SCP that explicitly permits only those services and actions that you want to allow. Your custom SCP then overrides the implicit Deny with an explicit Allow for only those actions that you want to permit.
The option that says: The SCP is the root cause because it does not support whitelisting actions of the AWS resources is incorrect. The SCP format is correct, and it definitely does support the whitelisting feature.
The option that says: The IAM policy is the root cause because you have denied user permissions to execute any S3-related actions is incorrect. The IAM policy allows the user to perform all actions under Amazon S3. The included Deny policy only affects actions on AWS resources that are not of S3, and therefore, should not hinder you from creating S3 buckets. Take note that the NotAction/NotResource is an advanced policy element that explicitly matches everything except the list of action/resources that you specified.
The option that says: Both the IAM policy and the SCP are the problem. The SCP should explicitly allow S3 bucket creation in its policy and the IAM policy should exactly match the permissions of the SCP is incorrect. The IAM policy does not necessarily need to match the service control policy. Although it is true that you would have to explicitly allow S3 bucket creation on the SCP, an SCP does not grant any permissions. Users and roles must still be granted permissions with appropriate IAM permission policies. A user without any IAM permission policies has no access at all, even if the applicable SCPs allow all services and all actions.
References:
Service Control Policies (SCP) vs IAM Policies:
Question 27: Skipped
A company uses Amazon WorkSpaces to improve the productivity and security of its remote workers. Hundreds of remote workers log in to the virtual desktop service using the Amazon WorkSpaces client application on a regular basis. Users have reported that they cannot log in to their virtual desktops even though they have the correct credentials.
Upon investigation, the Solutions Architect discovered that the filesystem storing the user profiles has reached its capacity, which is the reason why users cannot establish a new session in Amazon WorkSpaces. The environment is configured with a 10 TB Amazon FSx for Windows File Server file system to store the user profiles. [-> EFS ? ]
Which of the following options should the Solutions Architect implement to solve the issue and prevent it from happening again [-> CloudWatch ]?
Create a new Amazon FSx for Windows File Server file system with a larger capacity. Create a script to copy all user profiles to the new file system. Create an Amazon CloudWatch metric to monitor the FreeStorageCapacity of the filesystem and send a notification via Amazon SNS before it reaches capacity.
Create an Amazon CloudWatch Alarm using the FreeStorageCapacity metric to monitor the file system. Once triggered, use AWS Steps Functions as the target. Run the Steps Function to create a new Amazon FSx for Windows File Server file system and migrate the user profiles.
Create an Amazon CloudWatch Alarm to monitor the FreeStorageCapacity metric of the file system. Write an AWS Lambda Function to increase the capacity of the Amazon FSx for Windows File Server file system using the update-file-system command. Utilize Amazon EventBridge to invoke this Lambda function when the metric threshold is reached.
(Correct)
From the Amazon FSx console, select the desired file system to edit its attributes. Enable the option Dynamically Allocate to allow the file system to scale depending on the size of the data stored. This will present a large capacity drive to Amazon WorkSpaces clients and will grow automatically as users add more data to their profiles.
Explanation
Amazon FSx for Windows File Server provides fully managed Microsoft Windows file servers, backed by a fully native Windows file system. With file storage on Amazon FSx, the code, applications, and tools that Windows developers and administrators use today can continue to work unchanged. Windows applications and workloads ideal for Amazon FSx include business applications, home directories, web serving, content management, data analytics, software build setups, and media processing workloads.
As you need additional storage, you can increase the storage capacity that is configured on your FSx for Windows File Server file system. You can do so using the Amazon FSx console, the Amazon FSx API, or the AWS Command Line Interface (AWS CLI).
You can only increase the amount of storage capacity for a file system; you cannot decrease storage capacity. When you increase the storage capacity of your Amazon FSx file system, behind the scenes, Amazon FSx adds a new, larger set of disks to your file system. Amazon FSx then runs a storage optimization process in the background to transparently migrate data from the old disks to the new disks.
The following illustration shows the four main steps of the process that Amazon FSx uses when increasing a file system's storage capacity.
EventBridge (CloudWatch Events) helps you to respond to state changes in your AWS resources. With EventBridge (CloudWatch Events), you can create rules that match selected events in the stream and route them to your AWS Lambda function to take action.
Using the update-file-system command, you can use AWS SDK or CLI to programmatically increase the size of the FSx file system. You can use Amazon CloudWatch to monitor the metrics of the file system and trigger the Lambda function to perform an action.
Therefore, the correct answer is: Create an Amazon CloudWatch Alarm to monitor the FreeStorageCapacity metric of the file system. Write an AWS Lambda Function to increase the capacity of the Amazon FSx for Windows File Server file system using the update-file-system command. Utilize Amazon EventBridge to invoke this Lambda function when the metric threshold is reached.
The option that says: Create a new Amazon FSx for Windows File Server file system with a larger capacity. Create a script to copy all user profiles to the new file system. Create an Amazon CloudWatch metric to monitor the FreeStorageCapacity of the filesystem and send a notification via Amazon SNS before it reaches capacity is incorrect. You don't have to manually copy all user data to a new volume. You can increase the file system and Amazon FSx automatically migrates the data to a larger volume in the background.
The option that says: Create an Amazon CloudWatch Alarm using the FreeStorageCapacity metric to monitor the file system. Once triggered, use AWS Steps Functions as the target. Run the Steps Function to create a new Amazon FSx for Windows File Server file system and migrate the user profiles is incorrect. You don't need to create the Step Function to migrate the user profiles. Amazon FSx automatically migrates the data in the background when you increase the file system size.
The option that says: From the Amazon FSx console, select the desired file system to edit its attributes. Enable the option Dynamically Allocate to allow the file system to scale depending on the size of the data stored. This will present a large capacity drive to Amazon WorkSpaces clients and will grow automatically as users add more data to their profiles is incorrect. There is no option to Dynamically Allocate the file system size. You can manually adjust the file system size using the Amazon FSx console, the Amazon FSx API, or the AWS CLI.
References:
Check out this Amazon FSx Cheat Sheet and Amazon CloudWatch Cheat Sheets:
Question 34: Skipped
A leading financial company owns multiple AWS accounts that are consolidated under one AWS Organization. To properly manage all of the resources in your organization, the solutions architect has been tasked to ensure that the tags [-> TagManager?] are always added when users create any resources across all the accounts.
Which of the following options are the recommended actions to achieve the company requirements? (Select TWO.)
Set up AWS Systems Manager Automation to automatically add tags to your provisioned resources.
Set up the CloudFormation Resource Tags property to apply tags to certain resource types upon creation.
(Correct)
Set up AWS generated tags by activating it in the Billing and Cost Management console of the member account.
Set up AWS Config to add the corresponding tags to your resources right from the very moment that they are created.
Set up AWS Service Catalog to tag the provisioned resources with corresponding unique identifiers for portfolio, product, and users.
(Correct)
Explanation
AWS offers a variety of tools to help you implement proactive tag governance practices by ensuring that tags are consistently applied when resources are created.
AWS CloudFormation provides a common language for provisioning all the infrastructure resources in your cloud environment. CloudFormation templates are simple text files that create AWS resources in an automated and secure manner. When you create AWS resources using AWS CloudFormation templates, you can use the CloudFormation Resource Tags property to apply tags to certain resource types upon creation.
AWS Service Catalog allows organizations to create and manage catalogs of IT services that are approved for use on AWS. These IT services can include everything from virtual machine images, servers, software, and databases to complete multi-tier application environments. AWS Service Catalog enables a self-service capability for users, allowing them to provision the services they need while also helping you to maintain consistent governance – including the application of required tags and tag values.
AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. Using IAM, you can create and manage AWS users and groups, and use permissions to allow or deny their access to AWS resources. When you create IAM policies, you can specify resource-level permissions, which include specific permissions for creating and deleting tags. In addition, you can include condition keys, such as aws:RequestTag and aws:TagKeys, which will prevent resources from being created if specific tags or tag values are not present.
Therefore, the correct answers are:
- Set up AWS Service Catalog to tag the provisioned resources with corresponding unique identifiers for portfolio, product, and users.
- Set up the CloudFormation Resource Tags property to apply tags to certain resource types upon creation.
The option that says: Set up AWS config to add the corresponding tags to your resources right from the very moment that they are created is incorrect. Although you can use AWS Config to determine if your resources have tags or not, it does not have the capability to immediately add the corresponding tags to your resources across multiple AWS accounts by default. You usually issue the TagResource AWS Config API action to tag a resource in your current AWS account and not for multiple accounts. AWS Config supports Multi-Account Multi-Region Data Aggregation but you have to manually create an Aggregator, which is not mentioned in this option. You can use AWS Service Catalog in conjunction with AWS Config to satisfy the requirement.
The option that says: Set up AWS generated tags by activating it in the Billing and Cost Management console of the member account is incorrect. Although you can use the AWS generated tags feature in this scenario, you have to activate it using the master account and not on the member account.
The option that says: Set up AWS Systems Manager Automation to automatically add tags to your provisioned resources is incorrect because you cannot automatically add tags to your provisioned resources using AWS Systems Manager Automation.
References:
Check out this AWS Service Catalog Cheat Sheet:
Question 72: Skipped
A leading insurance firm has several new members in its development team. The solutions architect was instructed to provision access to certain IAM users who perform application development tasks in the VPC. The access should allow the users to create and configure various AWS resources such as deploying Windows EC2 servers. In addition, the users should be able to see the permissions in AWS Organizations to view information about the user's organization, including the master account email and organization limitations.
Which of the following should the solutions architect implement to follow the standard security advice of granting the least privilege?
Create a new IAM role and attach the AdministratorAccess AWS managed policy to it. Assign the IAM Role to the IAM users.
Attach the PowerUserAccess AWS managed policy to the IAM users.
(Correct)
Attach the AdministratorAccess AWS managed policy to the IAM users.
Create a new IAM role and attach the SystemAdministrator AWS managed policy to it. Assign the IAM Role to the IAM users.
Explanation
AWS managed policies for job functions are designed to closely align to common job functions in the IT industry. You can use these policies to easily grant the permissions needed to carry out the tasks expected of someone in a specific job function. These policies consolidate permissions for many services into a single policy that's easier to work with than having permissions scattered across many policies.
There are a lot of available AWS Managed Policies that you can directly attach to your IAM Users, such as Administrator, Billing, Database Administrator, Data Scientist, Developer Power User, Network Administrator, Security Auditor, System Administrator and many others.
For Administrators, you can use the AWS managed policy name: AdministratorAccess if you want to provision full access to a specific IAM User. This will enable the user to delegate permissions to every service and resource in AWS as this policy grants all actions for all AWS services and for all resources in the account.
For Developer Power Users, you can use the AWS managed policy name: PowerUserAccess if you have users who perform application development tasks. This policy will enable them to create and configure resources and services that support AWS aware application development. The first statement of this policy uses the NotAction element to allow all actions for all AWS services and for all resources except AWS Identity and Access Management and AWS Organizations. The second statement grants IAM permissions to create a service-linked role. This is required by some services that must access resources in another service, such as an Amazon S3 bucket. It also grants Organizations permissions to view information about the user's organization, including the master account email and organization limitations.
Therefore, the correct answer is: Attach the PowerUserAccess AWS managed policy to the IAM users.
The options that say: Attach the AdministratorAccess AWS managed policy to the IAM users and Create a new IAM role and attach the AdministratorAccess AWS managed policy to it. Assign the IAM Role to the IAM users are incorrect. Although an AdministratorAccess policy can meet the requirement, it is more suitable to attach a PowerUserAccess to the IAM users since this policy can provide the required access. Take note that you have to follow the standard security best practice of granting the least privilege. In addition, a managed policy can be directly attached to your IAM Users, which is one of the reasons why the latter option is incorrect.
The option that says: Create a new IAM role and attach the SystemAdministrator AWS managed policy to it. Assign the IAM Role to the IAM users is incorrect because the SystemAdministrator managed policy does not have AWS Organizations permissions to view information about the user's organization such as the master account email or the organization limitations. In this scenario, you have to use PowerUserAccess instead.
References:
