Design Secure Architectures practice questions

SCPs apply to every member account in the organization, including member-account root users, but they have no effect whatsoever on the management account — not on its users, roles, or root user.

Because the SCP sits at the organization root, every member account and OU inherits it, and it binds all principals in those accounts including root. The single account that can still act outside the allowed Regions is the management account, which no SCP can constrain — which is also why AWS recommends running no workloads there. The member-root option inverts the actual rule: member-account root users are constrained by SCPs. The root-attachment option is wrong because root-level SCPs inherit down to everything. The EC2-exemption option is a distractor built on the real practice of exempting global services like IAM in Region-deny SCPs; EC2 is regional and gets no such exemption.

1. Confirm the SCP scope: attached at the organization root, it inherits to all OUs and member accounts.
2. Recall that within member accounts, SCPs bind every principal, including administrators and root.
3. Identify the one principal set SCPs can never touch: everything inside the management account.
4. Match the evidence — one unaffected account launching resources post-SCP — to the management account.
5. Note the operational lesson: keep workloads and daily activity out of the management account.

Exam tip: SCPs bind member accounts and their root users but never the management account — keep workloads out of it.

Only SCPs can constrain member-account root users, and no control of any kind constrains the management account. A guardrail design must therefore combine an SCP with the discipline of keeping workloads out of the management account.

The SCP explicit deny on the member-account OUs is the only mechanism that reaches every principal in those accounts, root included, and it is enforced from above the accounts so no insider can lift it. Keeping workloads in member accounts is the necessary second half: the management account is immune to SCPs, so any future workload placed there would escape the guarantee — the requirement explicitly covers future workloads. The IAM-policy-on-root and boundary-on-root options fail on the same precise fact: root users are not IAM identities and accept neither identity policies nor permissions boundaries. Attaching the SCP to the management account is a no-op because SCPs simply never evaluate against management-account principals.

1. Translate the requirement: a preventive restriction binding all member-account principals, including root, now and for future workloads.
2. Select the only layer that constrains member root users: an SCP with an explicit deny, attached to the relevant OUs.
3. Recall the SCP blind spot: the management account is never affected, so workloads must not live there.
4. Eliminate options that attach IAM policies or boundaries to root, since root accepts neither.
5. Eliminate attaching the SCP to the management account, which has no effect by design.

Exam tip: Guardrails that must bind root are SCPs on member accounts — and because SCPs never reach the management account, workloads must stay out of it.

Anything running on AWS compute should use an IAM role rather than access keys. Roles deliver temporary STS credentials that rotate automatically and never need to be stored in code or configuration.

The instance profile role eliminates the credential problem instead of managing it: the instance retrieves short-lived credentials from the metadata service, they expire automatically, and revocation is as simple as detaching the role. Rotating keys every 30 days still leaves a 30-day validity window for any leaked key and keeps secrets on disk. Moving the keys into Secrets Manager is a common trap — it secures storage of the keys but the keys themselves remain long-lived static credentials, and the application still needs some credential to call Secrets Manager in the first place, which is exactly what a role provides. KMS-encrypting the file protects it at rest only; at runtime the plaintext keys are back in play.

1. Spot the anti-pattern in the stem: long-lived access keys stored on compute.
2. Prefer options that eliminate static credentials over options that store or rotate them better.
3. Attach an IAM role via an instance profile so the app gets temporary STS credentials from instance metadata.
4. Scope the role's policy to the specific bucket and actions for least privilege.
5. Delete the IAM user's access keys so the old path is fully closed.

Exam tip: For AWS API access from EC2, an instance role that removes the keys always beats any scheme that stores or rotates them.

Every Lambda function runs with an execution role whose temporary credentials AWS supplies automatically. Granting permissions to that role is the native, zero-maintenance way for function code to access AWS services.

The execution role wins on both security and overhead: the SDK picks up temporary credentials automatically, they rotate without any action, and there is nothing to store, encrypt, retrieve, or leak. Secrets Manager storage secures the wrong thing — the static keys still exist and now carry retrieval code and monthly cost. Scheduled rotation is exactly the recurring operational burden the question asks to avoid, and keys are still exposed between rotations. The assume-role-from-stored-keys option is circular: it uses long-lived credentials to obtain temporary ones, when the platform already hands the function temporary credentials for free.

1. Recognize the actor: code running on AWS compute (Lambda), which always has a native role mechanism.
2. Apply the rule that compute gets roles, never IAM users with access keys.
3. Attach a least-privilege DynamoDB policy to the function's execution role.
4. Remove the proposed IAM user and its keys so no static credential path remains.
5. Compare overhead: the role needs zero ongoing maintenance; every other option adds storage, code, or rotation work.

Exam tip: Lambda code gets its AWS access from the execution role — any design that mints access keys for a function is wrong before you weigh the details.

Long-lived access keys on compute are a credential liability that roles eliminate. An instance profile delivers temporary, auto-rotated STS credentials to everything running on the instance.

Deleting the keys and attaching an instance role removes every problem the audit found at once: no shared secret, nothing stored on disk, no rotation schedule to miss, and CloudTrail attributes calls to the role session. Splitting keys per team keeps the fundamental flaw — static credentials on instances — and adds more keys to manage. Parameter Store SecureString is secure storage for the wrong object: the credentials are still long-lived, still shared by whatever reads the parameter, and the fix ignores that the instance can hold a role instead. MFA on the IAM user is irrelevant to programmatic key use by unattended scripts, which never present an MFA token.

1. List the audit findings: shared keys, stored on disk, never rotated — all properties of long-lived credentials.
2. Ask whether the workload can use a role; EC2 instances always can, via an instance profile.
3. Attach a least-privilege role to the fleet and update scripts to rely on the default credential chain.
4. Delete the IAM user's access keys to close the old path.
5. Reject options that relocate, split, or rotate the keys — they manage the liability instead of removing it.

Exam tip: The fix for keys on EC2 is never better key hygiene — it is deleting the keys and using an instance role.

Assuming a role temporarily replaces your permissions with the role's; a resource-based policy instead grants access while you keep your own identity and permissions. When a caller needs its home-account access and a remote resource in the same flow, the resource-based policy is the clean answer.

The queue policy in account B lets the execution role reach across while remaining itself, so the same invocation reads SQS in B and writes DynamoDB in A with one set of temporary credentials — no key material, no credential switching. The assume-role option fails the scenario's defining nuance: as the account B role, the function is a different principal and no longer holds its account A DynamoDB permissions, forcing awkward mid-invocation credential management. The IAM-user option violates the no-long-lived-credentials requirement outright. The forwarding function is a workable but heavier architecture — extra function, extra permissions surface, extra failure mode — losing on the fewest-moving-parts qualifier.

1. Note the dual requirement: access a resource in account B and resources in account A within one invocation.
2. Recall that assuming a role swaps identities, which would drop the function's home-account permissions mid-flow.
3. Check that the target service supports resource-based policies; SQS queue policies do.
4. Grant the execution role the needed queue actions via the queue policy in account B, and grant the SQS API actions plus DynamoDB access in the role's own identity policy.
5. Verify no long-lived credentials exist anywhere in the design.

Exam tip: When a cross-account caller must keep its own permissions, grant access with a resource-based policy — assuming a role would replace them.