4 of the 9 questions we have for this objective, shown with the answer and the reasoning.
Prescribe security controls
Harrowgate Logistics is rolling out Amazon GuardDuty across its organization of 150 accounts in us-east-1 and eu-west-1. The security operations team in account secops-prod must manage GuardDuty for all accounts, see every finding in its own account, and ensure that accounts created in the future are protected without anyone taking action. The management account must not be used for daily security work.
Which two actions should the solutions architect take? Each correct answer presents part of the solution.
- AFrom the management account, designate secops-prod as the GuardDuty delegated administrator in each Region where GuardDuty will be used.The GuardDuty delegated administrator is designated per Region, so the designation must be made in both us-east-1 and eu-west-1.
- BIn secops-prod, configure the organization auto-enable setting to enable GuardDuty for all member accounts, including existing and new accounts.Setting auto-enable to all accounts enables GuardDuty in existing members and in every account that joins the organization later.
- CSend email invitations from secops-prod to each of the 150 accounts and accept them in each account.Invitation-based membership is the legacy method for accounts outside an organization. It requires per-account action and does not cover new accounts automatically.
- DAttach a service control policy to the organization root that enables GuardDuty in all accounts.SCPs restrict permissions; they cannot enable or configure a service. An SCP can, however, prevent member accounts from disabling GuardDuty.
- EDeploy a CloudFormation StackSet from the management account that creates a GuardDuty detector in each account and Region.This uses the management account for routine security work and still leaves each detector separately managed rather than administered from secops-prod.
Why: GuardDuty integrates with AWS Organizations through a delegated administrator, which keeps security work out of the management account. Because GuardDuty is a Regional service, the delegated administrator and the auto-enable configuration must be set in each Region in use. Auto-enable for all accounts covers both existing and newly created accounts and can also turn on protection plans such as S3 or EKS protection. Findings from members then appear in the administrator account, where they can be routed to Security Hub CSPM or EventBridge.
Prescribe security controls
Glenmora Foods uses Okta as its workforce identity provider for 4,000 employees and has 90 AWS accounts in AWS Organizations. Today each account has its own IAM SAML provider and roles that are maintained by hand. The company wants employees to sign in once with Okta, see the accounts and roles they are entitled to, and have users and groups created and removed in AWS automatically when HR changes them in Okta.
Which solution should the solutions architect recommend?
- AEnable IAM Identity Center in the management account, set Okta as the external identity provider with SAML 2.0, enable SCIM automatic provisioning from Okta, and assign Okta groups to accounts with permission sets.IAM Identity Center federates with Okta over SAML for sign-in and uses SCIM to synchronize users and groups. Permission sets assigned to groups are deployed as roles in each account automatically.
- BKeep a SAML identity provider in each account and use AWS CloudFormation StackSets to deploy the IAM roles to all 90 accounts.StackSets reduce manual role creation, but users still have no central portal and there is no automatic user and group provisioning from Okta.
- CCreate an Amazon Cognito user pool federated with Okta and use the Cognito identity pool to issue credentials for all 90 accounts.Cognito is designed for customer identities in applications, not workforce access to the AWS Management Console across an organization.
- DUse AWS Directory Service AD Connector to connect Okta to IAM Identity Center.AD Connector proxies to an on-premises Active Directory. Okta is not an Active Directory, and Identity Center connects to it directly as an external IdP.
Why: IAM Identity Center is the recommended way to give a workforce access to many AWS accounts. With an external IdP such as Okta, Microsoft Entra ID or Ping, authentication happens at the IdP through SAML 2.0, and SCIM keeps users and groups in sync so that leavers lose access automatically. Permission sets define access once and are provisioned as roles in each target account. A delegated administrator account can manage Identity Center so that daily work does not happen in the management account.
Prescribe security controls
Norland Retail keeps its data lake in an S3 bucket in account datalake-prod (111122223333), encrypted with SSE-KMS using a customer managed key named key-datalake. An Amazon Athena workgroup in account analytics-prod (777788889999) runs under an IAM role named AthenaQueryRole. The bucket policy already allows AthenaQueryRole to read the objects, but queries fail with KMS AccessDenied errors. Security requires least privilege.
What should the solutions architect do to allow the queries to succeed?
- AAttach an IAM policy to AthenaQueryRole that allows kms:Decrypt on the key-datalake ARN. No other change is needed.For cross-account KMS access, the key policy in the owning account must also allow the external principal. An identity policy alone is not sufficient.
- BAdd a statement to the key-datalake key policy that allows kms:Decrypt for the AthenaQueryRole ARN, and attach an IAM policy to AthenaQueryRole that allows kms:Decrypt on the key-datalake ARN.Cross-account use of a KMS key needs both sides: the key policy in 111122223333 must allow the external role, and the role's identity policy in 777788889999 must allow the action on that key.
- CRe-encrypt the data lake with the AWS managed key aws/s3 and share that key with analytics-prod.AWS managed keys cannot have their key policies changed, so they cannot be used for cross-account access.
- DAdd a statement to the key-datalake key policy that allows kms:* for the analytics-prod account root principal.Granting kms:* is far broader than needed, and without an identity policy in analytics-prod the role still would not be allowed to use the key.
Why: AWS KMS authorization requires the key policy to permit access; IAM policies only take effect for a key when the key policy allows them. When the caller is in another account, the key policy must name that account or role, and the caller's account must also grant the permission with an identity policy. Only the necessary operations, such as kms:Decrypt for reads, should be granted. AWS managed keys cannot be shared across accounts because their policies are fixed, which is a common reason to use customer managed keys for shared data.
Prescribe security controls
Cobalt Ridge Media has 70 accounts in AWS Organizations and workloads in us-east-1, us-west-2, eu-west-1 and ap-southeast-2. The security team works from an account named security-tooling and wants a single view of findings from AWS Security Hub CSPM, Amazon GuardDuty and Amazon Inspector for all accounts and Regions. It also wants one notification pipeline that sends critical findings to an on-call Amazon SNS topic, and new accounts must be included automatically.
Which solution meets these requirements with the LEAST operational overhead?
- AFrom the management account, designate security-tooling as the Security Hub CSPM delegated administrator, use central configuration to enable it in all accounts and the four Regions, set us-east-1 as the home Region for cross-Region aggregation, and create one Amazon EventBridge rule in us-east-1 in security-tooling that matches critical findings and targets the SNS topic.Delegated administration plus central configuration covers existing and new accounts. Cross-Region aggregation brings findings from linked Regions into the home Region, so a single EventBridge rule in that Region sees all of them.
- BEnable Security Hub CSPM in each account by hand, invite each account as a member of security-tooling, and create an EventBridge rule in each Region of each account.Manual invitations and 280 per-account, per-Region rules are high overhead, and new accounts would not be included automatically.
- CCreate an organization trail in AWS CloudTrail and use CloudWatch Logs metric filters to detect findings and alert the SNS topic.CloudTrail records API activity, not security findings from GuardDuty or Inspector, so metric filters on the trail cannot produce the required finding notifications.
- DDesignate security-tooling as the delegated administrator for Security Hub CSPM and create an EventBridge rule in each of the four Regions in security-tooling.This works, but four rules and four pipelines are more to maintain than one rule in the aggregation Region, so it is not the least operational overhead.
Why: Security Hub CSPM acts as the aggregation point for findings from GuardDuty, Inspector, Macie and other services. Organization integration lets a delegated administrator account enable and configure it across all member accounts, and central configuration applies policies to new accounts as they join. Cross-Region aggregation replicates findings from linked Regions into a home Region, so a single EventBridge rule there can route critical findings to SNS, a ticketing system or automation. The distractors either add manual steps or rely on CloudTrail, which does not carry findings. The same delegated administrator and home Region pattern applies to the newer AWS Security Hub, which correlates these findings in OCSF format.