Security Foundations and Governance practice questions

The reference layout separates evidence (the log-archive account) from security tooling (the audit account); neither runs workloads.

The log-archive account is the purpose-built destination for organization CloudTrail logs: it runs no workloads and is separate from the audit account, so the people who administer the security services do not administer the evidence. The audit account is the tempting near-twin, but that is exactly where the security-service administrators work. The management account and a shared-services account both fail the isolation requirement.

1. Separate the two Security OU accounts by purpose: evidence storage versus security tooling.
2. Match the stem constraint that the tooling administrators must not alter the logs.
3. Rule out accounts that run workloads or hold the organization’s highest privileges.

Exam tip: Organization logs go to the log-archive account; security tooling goes to the audit account.

SCPs apply to every principal in member accounts, including the root user, but never to the management account.

The deciding fact is which account made the call. The payer account that created the organization is the management account, and SCPs do not affect any user or role there, wherever the SCP is attached. That is why AWS recommends running no workloads in the management account and keeping access to it tightly restricted. The other options misstate policy evaluation (an explicit deny is not overridden by an Allow), Region evaluation (the request Region is us-west-2) or inheritance (it does not depend on join date).

1. Identify the account: the payer account that created the organization is the management account.
2. Recall that SCPs never constrain principals in the management account.
3. Rule out explanations that contradict deny-wins evaluation or SCP inheritance.

Exam tip: No SCP restricts the management account, so keep it free of workloads and routine access.

Security services that integrate with AWS Organizations are run from a delegated administrator member account, normally the audit (security-tooling) account, with organization auto-enable for new accounts.

Delegated administration moves day-to-day management of GuardDuty and Security Hub CSPM out of the management account into the audit account, where findings from every member account aggregate and auto-enable covers new accounts. The log-archive near-twin uses the same mechanism in the account that must stay separate from tool administrators. A management-account permission set breaks the no-sign-in requirement, and a StackSet-plus-EventBridge build works but adds avoidable overhead.

1. List the constraints: no management-account sign-in, new accounts covered with no manual step, tooling kept away from the log store, least overhead.
2. Pick the native organization integration (trusted access plus a delegated administrator) over a custom deployment.
3. Choose the audit account, not the log-archive account, as the delegated administrator.

Exam tip: Delegate security services to the audit account and let auto-enable cover new accounts.

Requests to global services such as IAM, Route 53 and CloudFront are evaluated with aws:RequestedRegion set to us-east-1, so a Region-deny SCP needs a NotAction exemption for them.

The NotAction pattern denies everything except the listed global services outside the approved Region, so new regional services are covered by default and us-east-1 stays closed to workloads. Each distractor fixes the symptom but breaks one requirement: an Action allow-list misses future services, adding us-east-1 opens a forbidden Region, and an Allow statement cannot beat an explicit Deny. The NotAction list here is abbreviated to the services in the scenario: AWS's documented Region-deny example exempts many more global services (for example Organizations, Budgets, Cost Explorer, Health, Global Accelerator, WAF and KMS), so a real policy must exempt every global service the organization uses.

1. Explain the symptom: global-service calls carry aws:RequestedRegion us-east-1 and hit the deny.
2. Keep a deny that covers every action by default, so later services are included.
3. Exempt only the global services with NotAction instead of approving us-east-1.
4. Remember that a separate Allow never overrides an explicit Deny.

Exam tip: Region-deny SCP = Deny with NotAction on global services, conditioned on aws:RequestedRegion.

An SCP is the organization-level preventive control that constrains every principal in member accounts, including the root user.

Two facts decide this. First, an SCP binds every principal in member accounts, including the root user and administrators, so an unconditioned SCP deny at the root covers all of them. Second, the RCP twin looks just as broad, but RCPs only take effect for the services on their supported list, and these CloudTrail, GuardDuty and Config actions are not on it. The PrincipalArn-scoped SCP leaves the root user and IAM users out. A permissions boundary is per-principal, cannot apply to root and can be changed by an account administrator.

1. Identify who must be stopped: every principal in member accounts, root included.
2. Pick the policy type that binds principals organization-wide: an SCP, not a boundary.
3. Check whether the RCP even applies: RCPs cover a listed set of services, and these actions are not among them.
4. Check that no condition narrows the deny to a subset of principals.

Exam tip: Protect CloudTrail, GuardDuty and Config with an unconditioned SCP deny; SCPs bind member-account root.

SCPs never grant permissions; an action is allowed only if every SCP level permits it and an identity or resource policy grants it.

Every SCP level permits ec2:RunInstances here (FullAWSAccess at each level, and at the OU the attached SCPs combine), so the SCPs are not what blocks it. The developer's only identity policy allows s3:GetObject, and an SCP Allow cannot fill that gap. The RCP option misreads what RCPs do, a permissions boundary is optional and never required by an SCP, and the PassRole theory fails because FullAWSAccess on the OU already permits it.

1. Check every SCP level: root, OU and account all permit the action, and SCPs at one level combine.
2. Check the identity policy: it grants s3:GetObject only.
3. Apply the rule that SCPs cap permissions and never grant them.
4. Discard theories that need an extra artefact the scenario does not require, such as a boundary.

Exam tip: SCPs filter; identity and resource policies grant. Both must agree.