AWS Certified CloudOps Engineer - Associate (SOA-C03) #12 Domain 5-1 Security — IAM,Organizations,Multi-account Operations
We finished the networking domain through #11. The last domain is security and compliance (16%). The first post covers identity and permissions, plus the multi-account governance that rules many accounts under one standard. The IAM you saw in SAA,DVA is viewed here from the operator’s perspective of checking, enforcing, and auditing permissions.
IAM Permission Operations #
We covered the definition of IAM in the earlier series, so let’s focus on what the exam frequently asks about.
| Concept | Operational point |
|---|---|
| Least privilege | Grant only as much as needed. Reducing excessive permissions is an ongoing task |
| Role | Temporary credentials instead of long-term keys for people,services. EC2,Lambda,task roles |
| Policy evaluation | Deny by default, allow with explicit Allow, explicit Deny takes precedence |
Credential Report and Last-Used Info #
Two tools the operator uses to check permissions.
- Credential Report: Bulk-queries the password,access key,MFA status of every IAM user as a CSV. The answer to “find old keys and accounts without MFA.”
- Access Advisor (last-used info): Shows the services a role,user has actually used. The basis for reclaiming unused permissions to narrow down to least privilege.
These two are the answer to “identify and clean up unused credentials and permissions.”
IAM Access Analyzer #
It analyzes resource policies to find resources unintentionally shared outside the account (external). It checks whether S3 buckets,IAM roles,KMS keys are exposed externally. The answer to “detect resources mistakenly made public externally” is Access Analyzer.
MFA Enforcement #
The foundation of operational security is MFA. The exam asks “how do you enforce MFA?”
- Root account MFA: The first thing to turn on. Don’t use root for daily work.
- Enforce by policy: Attach
aws:MultiFactorAuthPresentto aConditionin an IAM policy to deny sensitive actions without MFA. - Enforce org-wide with SCP: in Organizations below.
The answer to “block certain actions if MFA isn’t used” is a policy using the condition key aws:MultiFactorAuthPresent.
AWS Organizations: the Foundation of Multi-account #
When accounts grow, managing each one separately becomes impossible. Organizations bundles many accounts into one organization to govern them.
| Concept | Role |
|---|---|
| Management account | The root of the organization. Billing,policy management |
| OU (Organizational Unit) | A group that bundles accounts by purpose (e.g., prod,dev) |
| SCP (Service Control Policy) | A permission ceiling applied to OUs,accounts |
| Consolidated billing | Aggregates usage across all accounts for volume discounts |
Core Properties of SCP #
SCP is an exam regular and widely misunderstood.
- SCP does not grant permissions. It only sets a ceiling to restrict.
- Effective permissions = SCP-allowed scope ∩ IAM-policy-allowed scope. Both must allow.
- SCP does not apply to the Management account.
The answer to “prohibit the use of a certain region across all accounts in the org” and “block the use of services other than the designated ones” is SCP. Conversely, if an option says “grant permissions with an SCP,” that’s wrong.
Multi-account Standardization #
| Tool | Role |
|---|---|
| Organizations + SCP | Permission ceiling,guardrails |
| StackSets | Bulk deployment of standard stacks, seen in #7 |
| Control Tower | Automatically configures a multi-account environment with best practices (landing zone) |
| IAM Identity Center | SSO access across multiple accounts (formerly AWS SSO) |
The answer to “automatically apply a security baseline to new accounts and unify access via SSO” is Control Tower + Identity Center. Instead of the operator creating IAM users per account, the recommended pattern is to log in once with Identity Center and access multiple accounts,roles.
Exam Question Patterns #
- Detect old keys,users without MFA → Credential Report
- Reclaim unused permissions → Access Advisor (last-used info)
- Detect resources mistakenly exposed externally → IAM Access Analyzer
- Deny actions without MFA → policy Condition
aws:MultiFactorAuthPresent - Region,service guardrail across all accounts → SCP
- Auto-standardize new accounts + SSO → Control Tower + IAM Identity Center
- Standard stacks across all accounts → StackSets
Common Pitfalls #
1) Thinking SCP grants permissions #
SCP is a ceiling. Permissions are granted by IAM policies. The intersection of the two is the effective permission.
2) Assuming the Management account is also blocked by SCP #
SCP does not apply to the Management account. That’s why daily work is done in member accounts.
3) Creating IAM users per account #
The proper way to access multiple accounts is IAM Identity Center (SSO). Replicating users per account is a big operational burden.
4) Daily work with the root account #
Seal off root with MFA. Do daily work with roles,Identity Center.
Summary #
What we covered in this post:
- IAM operations make maintaining least privilege an ongoing task. Check with Credential Report,Access Advisor
- Detect externally exposed resources with IAM Access Analyzer
- MFA enforcement uses the policy
aws:MultiFactorAuthPresentcondition. Seal off root with MFA - Multi-account guardrails with Organizations + SCP. SCP is a ceiling, not a grant, and does not apply to the Management account
- Multi-account standardization with Control Tower (landing zone),IAM Identity Center (SSO),StackSets
Next: Domain 5-2 Detection and Auditing #
Now that we’ve covered identity and governance, next are the tools to trace and detect what happened.
In #13 Domain 5-2 Security: Config,CloudTrail,GuardDuty,Security Hub,KMS, I’ll cover how to audit APIs with CloudTrail, how to evaluate configuration compliance with Config, GuardDuty’s threat detection, Security Hub’s unified score, and KMS encryption operations.