IAM, AWS Organizations, and Compliance Tools for CloudOps (SOA-C03)

Day-to-day IAM operations come down to three controls: the account password policy, MFA enforcement, and replacing long-term credentials with roles and temporary credentials.

The account password policy sets minimum length, required character types, maximum password age, and password reuse prevention (the last 1 to 24 passwords). It applies only to IAM user passwords. It does not govern access keys, the root user, federated users, Amazon Cognito user pool users (a user pool has its own password policy), or users in AWS Managed Microsoft AD (governed by the directory's fine-grained password policies). The AWS Config managed rule iam-password-policy only detects an account whose policy falls short; it does not set the policy. Audit individual users with the credential report.

MFA is registered per user, but registration is not enforcement, and the password policy has no MFA setting. To enforce it, attach a policy that denies every action except the MFA self-management actions whenever MFA is absent. The condition must be written carefully because requests signed with long-term access keys carry no MFA context at all: the aws:MultiFactorAuthPresent key is simply missing.

That is why the AWS-recommended pattern uses BoolIfExists. It also means a CLI user with access keys is locked out until they obtain MFA-backed credentials: aws sts get-session-token --serial-number <MFA device ARN> --token-code <current code> returns temporary credentials whose requests carry aws:MultiFactorAuthPresent = true. (For a role, the same effect comes from passing the serial number and token code to AssumeRole.) Enable MFA on the root user first; a root account without MFA is one of the basic Trusted Advisor security checks.

Roles beat long-term keys everywhere a workload needs AWS access. An EC2 instance gets credentials through an instance profile; a Lambda function runs with its execution role, whose temporary credentials the Lambda service supplies to the function code; principals in other accounts assume a cross-account role with sts:AssumeRole instead of receiving shared keys. Role credentials are short-lived and rotated automatically, so there is nothing to leak into code or AMIs. Access keys copied onto an instance, baked into an AMI or shared between accounts are the anti-pattern this skill exists to remove; the next section covers workloads that do not run on EC2.

Every workload can get temporary credentials without a stored access key; the mechanism depends on where it runs.

Amazon ECS has two roles that are easy to confuse. The task role supplies credentials to your application code inside the container — the role whose policy must allow the S3, DynamoDB or SQS calls the app makes. The task execution role is used by the ECS agent and Fargate on your behalf to pull images from Amazon ECR, write logs to CloudWatch Logs, and fetch secrets referenced in the task definition. An application AccessDenied is fixed on the task role; an image-pull or secret-retrieval failure at task start is fixed on the execution role. A container that falls back to the EC2 instance role is usually missing a task role.

Servers outside AWS have two options that solve different problems:

Choose Roles Anywhere when the requirement is "this on-premises application must call AWS APIs without long-term keys" — especially when a PKI already exists or no agent may be installed. Choose a hybrid activation when the requirement is to patch, run commands on, or inventory the server with Systems Manager.

Federated identity means a user or workload authenticates with an external identity source and receives temporary AWS credentials for an IAM role — no IAM users to create and no passwords or keys to rotate. Which federation route fits depends on who is signing in.

For CI federation, create an IAM OIDC identity provider for the CI system's issuer (for GitHub, token.actions.githubusercontent.com with audience sts.amazonaws.com). The role's trust policy must allow sts:AssumeRoleWithWebIdentity — not sts:AssumeRole — from that federated principal, and it must condition on the token's sub claim, which identifies the repository and branch or environment (for example repo:my-org/my-repo:ref:refs/heads/main). Conditioning on aud alone trusts every repository that can obtain a token for that audience, and a wildcard in the repository part of sub widens the trust the same way. IAM Identity Center federates people signing in to a portal; it is not a credential source for pipeline jobs.

Separately, know the two policy families. Identity-based policies attach to users, groups and roles and state what that principal can do. Resource-based policies attach to the resource itself — S3 bucket policies, SQS queue and SNS topic policies, KMS key policies, Lambda function policies, and DynamoDB table and stream policies — and name a Principal that may access it.

The distinction matters most across accounts. Within one account, an allow from either family is generally enough. Across accounts, both sides must allow: the caller's identity policy must permit the action, and the resource policy in the target account must name the caller (or its account). Resource-based access also lets the caller keep its own identity — no role switching — which is why cross-account bucket policies appear so often in ops scenarios.

Encrypted objects add a third policy to that chain. When a bucket uses SSE-KMS with a customer managed key, a cross-account reader or writer also needs the KMS actions (kms:Decrypt to read, kms:GenerateDataKey to write): the key policy in the key's account must allow the external account or role, and the caller's identity policy must allow those actions on the key ARN. A bucket policy cannot grant KMS permissions, and enabling an S3 Bucket Key only reduces the number of KMS requests — it authorizes nothing. (Key policies and encryption at rest are covered in depth in the data protection lesson.)

Condition keys turn a broad allow or deny into a targeted control. The hard part is knowing what each global key actually sees:

Operators matter as much as keys. A missing key never matches a positive operator (IpAddress, StringEquals), but a negated operator such as NotIpAddress or StringNotEquals evaluates true when the key is missing. A Deny with NotIpAddress on aws:SourceIp therefore blocks calls from outside the corporate range — and also every call that arrives through a VPC endpoint or from an AWS service acting for the user, unless the policy exempts them (for example with aws:ViaAWSService). The ...IfExists suffix exists to control exactly this missing-key behaviour.

Attribute-based access control (ABAC) uses tags as the condition. One policy can allow actions only when aws:ResourceTag/project equals ${aws:PrincipalTag/project}, so a principal tagged project=alpha reaches only resources tagged alpha, and new projects need no policy edits. aws:ResourceTag checks the tags a resource already has; aws:RequestTag checks the tags supplied in the request, which is how you require correct tags at creation. ABAC is only as strong as the tags: deny principals the ability to add or change the controlling tag keys (for example a deny on tagging actions when aws:TagKeys includes project), or they can retag resources into their own scope.

Permissions boundaries cap the maximum permissions of an individual IAM user or role. The effective permission is the intersection of the identity policy and the boundary; the boundary itself grants nothing. The standard use is delegation: let a team create its own roles without letting them escalate. A safe delegation policy:

• allows iam:CreateRole (and attaching or putting policies on roles) only when the iam:PermissionsBoundary condition key equals the approved boundary policy ARN;
• denies iam:DeleteRolePermissionsBoundary and changing a role's boundary to anything else;
• denies editing the boundary policy itself (iam:CreatePolicyVersion, iam:SetDefaultPolicyVersion, iam:DeletePolicy on its ARN).

Without the last two, the team can simply remove or rewrite the cap. A session policy is a different tool: it is passed when a role is assumed or a federated session is created, it limits only that one session, and — like a boundary — it can only narrow what the role's policies allow, never add to it.

Tie it together with the evaluation order: an explicit deny in any policy ends evaluation. Then the gates must pass — every applicable SCP (which caps the principal), every applicable resource control policy (RCP, which caps the resource), the permissions boundary (if one exists) and the session policy (if one was passed) must allow the action. Only then does an allow from an identity-based or resource-based policy take effect. Two same-account edge cases follow from how resource policies name principals:

• A resource-based policy that grants access to an IAM user ARN or a role session ARN is not limited by an implicit deny in that principal's permissions boundary (or session policy) — the grant flows straight to the principal.
• A grant to a role ARN is limited by the role's boundary and any session policy, so an action missing from the boundary is still denied.

An explicit deny in a boundary, SCP or RCP still wins in every case. When a perfectly good allow still fails, look for an explicit deny or a gate that never allowed the action.

An application on EC2 suddenly logs AccessDenied calling s3:PutObject on arn:aws:s3:::app-uploads/reports/daily.csv. Triage it in order and you will locate any IAM failure:

1. Read the whole error message. For most services it names the principal, the action, the resource, the policy type responsible and whether the deny was explicit or implicit: "with an explicit deny in a service control policy" means an SCP statement denies the action; "because no service control policy allows the action" means no SCP at some level of the hierarchy allows it (an allow-list gap); "with an explicit deny in a resource control policy" means an organization RCP on the target resource's account blocks the request; "because no identity-based policy allows the action" means the role simply lacks a grant. Each points at a different fix.
2. Which principal made the call? Don't assume. Check the instance profile role, or read the userIdentity block of the CloudTrail event. Errors often trace to a different principal than expected — an old role, or a container using the instance role instead of its task role.
3. Which action on which resource? The exact action and ARN matter: an allow on arn:aws:s3:::app-uploads covers bucket-level actions such as ListBucket, but PutObject needs arn:aws:s3:::app-uploads/*. A missing /* on object-level actions is a classic cause. With SSE-KMS, the KMS key permissions are part of the same call.
4. Does an identity policy allow it? Review the role's attached and inline policies for the action and resource.
5. Does anything explicitly deny it? Check the bucket policy for denies with conditions — a deny on non-TLS transport or on requests from outside a specific VPC endpoint rejects an otherwise-allowed call.
6. Do the gates allow it? SCPs and RCPs attach to the organization root, OUs and accounts — never to an individual role or user — so an SCP problem is fixed at the OU or account, or by moving the account. A permissions boundary or session policy can also withhold the allow.

Session duration errors are their own category. Role chaining — using a role's credentials to assume another role — limits the chained session to one hour; an AssumeRole call that asks for more than 3,600 seconds while chaining fails rather than being shortened, whatever the role's maximum session duration.

Confirm the diagnosis with the IAM policy simulator before touching production, then make the smallest change that fixes the identified layer and re-run the simulation to verify.

Auditing answers two different questions: what happened, and what could happen.

CloudTrail answers what happened. Each event records the principal (userIdentity), the action (eventName), the source IP address (sourceIPAddress) and the time (eventTime). Event history is on by default: it keeps the last 90 days of management events in each Region, searchable by event name, user or resource, with no trail to create — enough to find who called AuthorizeSecurityGroupIngress last week. Create a trail delivering to S3 (an organization trail for every account) for longer retention, and enable log file integrity validation when you must prove the logs were not altered.

Data events are not logged by default. Object-level S3 calls such as GetObject and PutObject, Lambda invocations and DynamoDB item operations are data events: high-volume and billed separately. To record who read an object, add data events to a trail, using advanced event selectors to scope them to the buckets and event types you need. Logging read management events does not capture them, and log file validation only protects what is already logged. CloudTrail Insights is different again: it flags unusual API call rates and error rates (since late 2025 for data events as well as management events), but it detects anomalies rather than recording each individual call.

The IAM policy simulator answers what would happen. Choose a user, group or role (or paste a new or edited policy that is not yet attached), pick actions and resource ARNs, and it reports allowed or denied and which statement decided it — without calling the service, so nothing is created or changed. It is the safe way to test a policy change before rollout or to reproduce an AccessDenied. Don't confuse it with the DryRun parameter: DryRun is mainly an EC2 API parameter (for example on RunInstances) that checks permissions without making the change; S3, DynamoDB and SQS have no equivalent, so the simulator is the general-purpose way to test a policy.

IAM Access Analyzer answers what could happen, and it is several tools under one name:

An external access finding is not automatically a problem; it is a fact to confirm as intended (archive it) or to remediate. Access Analyzer reasons about what policies allow; the simulator evaluates a specific request; CloudTrail shows what actually happened. Round out the kit with two IAM built-ins: the credential report, a CSV of every IAM user's password age, access key age and MFA status, and last accessed information (access advisor), which shows when a principal last used each service.

AWS Organizations is the multi-account foundation: one management account, member accounts grouped into organizational units (OUs), consolidated billing, and central policy attachment. Structure OUs by function — workloads, sandbox, security — so guardrails can differ per group.

Service control policies (SCPs) are those guardrails, and four rules decide most SCP questions:

• SCPs never grant permissions. They define the maximum available; a principal still needs an IAM allow. An SCP that allows s3:* while a user still cannot reach S3 simply means no identity policy grants it.
• An action must be allowed at every level of the path: the root, each OU between the root and the account, and the account itself. A deny anywhere in the chain wins.
• SCPs do not affect the management account — one more reason to run no workloads in it — and they do not restrict service-linked roles.
• SCPs attach to the root, OUs and accounts, never to individual users or roles.

Resource control policies (RCPs) are the resource-side counterpart. An SCP caps what the principals in an account can do; an RCP caps what can be done to the resources in an account, whoever the caller is — including principals from outside the organization. That makes RCPs the tool for an organization-wide data perimeter, for example denying access to S3 buckets or KMS keys from any principal whose aws:PrincipalOrgID is not yours. RCPs apply to a supported set of services (including S3, AWS STS, AWS KMS, SQS and Secrets Manager), follow the same rules as SCPs — they grant nothing, a deny at any level wins, and they do not affect the management account or service-linked roles — and the AWS managed RCPFullAWSAccess policy stays attached everywhere, so RCPs are written as deny statements.

The every-level rule shapes the two SCP strategies. With the default deny-list approach, the AWS managed FullAWSAccess SCP stays attached everywhere and you add explicit deny statements. With an allow-list approach, you remove FullAWSAccess at a level and attach SCPs that allow only approved services. The allow must then exist at every level: if the OU's SCP allows only EC2 and S3, attaching FullAWSAccess to an account beneath it does not restore DynamoDB — the gap above still blocks it.

IAM Identity Center supplies the human access layer: connect an identity source, create permission sets, and assign users or groups to accounts with a permission set; Identity Center provisions a matching role in each assigned account. A permission set can include AWS managed policies, an inline policy, and references to customer managed policies or a customer managed permissions boundary. Those references are by name and path only: a policy with the same name and path must already exist in every account the permission set is assigned to, or provisioning to that account fails.

AWS Control Tower packages the whole pattern: a landing zone that sets up Organizations, a log archive and audit account, and (optionally) Identity Center, plus managed controls. Preventive controls are enforced with organization policies, chiefly SCPs; detective controls use AWS Config rules; proactive controls check resources before CloudFormation provisions them. Account Factory creates new accounts already enrolled in a governed OU, so the guardrails apply from day one. When a requirement says guardrails must apply to every new account automatically and must not be removable by account administrators, an organization-level control (an SCP or a Control Tower preventive control) fits; per-account IAM policies or Config rules that local admins could delete do not.

Remember the middle column: only identity and resource policies grant. SCPs, RCPs, boundaries and session policies only cap.

AWS Trusted Advisor checks your account against best practices, and its security checks are the ones Task 4.1 names. A basic set of security checks is available on every Support plan, including security groups with unrestricted access to specific ports, IAM use, MFA on the root account, Amazon S3 bucket permissions and Amazon EBS public snapshots; higher Support plans unlock the full set of checks and programmatic access.

Trusted Advisor only flags; remediation is your job, so match each check to the change that clears it. An open security group means removing or narrowing the offending inbound rule. A red root-MFA check means enabling an MFA device on the root user. A public S3 bucket usually means turning on Block Public Access and correcting the bucket policy. Old or unused access keys mean rotation or deletion — and preferably replacement with roles.

To automate the loop, use Amazon EventBridge. Trusted Advisor publishes check-status change events only to the default event bus in us-east-1 (N. Virginia), and only for accounts on Business Support+, Enterprise or Unified Operations support. Create the rule in us-east-1 and target something that changes the resource — a Lambda function or a Systems Manager Automation runbook (an SNS target only notifies). Keep two principles in mind. AWS service events are emitted only in the Region the service publishes them to; permissions on an event bus control who may send events to it, not where service events originate, so a rule elsewhere never sees them unless you forward them from us-east-1. And recording or notifying is not remediation: an alert, a ticket or an OpsCenter OpsItem tells an operator about the problem, but only a target that changes the resource closes the loop automatically. The same check → EventBridge → automated remediation pattern recurs with AWS Config and Security Hub.

Compliance enforcement has two halves: prevent the violation, and continuously detect the ones that slip through.

Prevention is the SCP's job. The Region-restriction pattern is a deny on all actions when aws:RequestedRegion is not in your approved list — attached at the root or an OU, it stops every principal in every member account, which no per-account IAM policy can do. Requests to global services such as IAM, AWS Organizations, Route 53, CloudFront and AWS Support are served from us-east-1, so the standard version uses NotAction to exempt those services from the deny. The principle: exempt the specific global services by action, never by allowing a whole extra Region, because a Region allowance applies to every service, not just the global ones. Restricting services works the same way: an SCP that denies the unapproved service's actions, or an allow-list SCP that permits only approved ones.

Detection is AWS Config. The configuration recorder tracks supported resources' configurations over time, and Config rules evaluate each resource as compliant or noncompliant. Reach for managed rules — prebuilt checks such as restricted-ssh (no security group allows SSH from 0.0.0.0/0) or encrypted-volumes — before writing custom rules backed by Lambda or Guard.

A rule can carry a remediation action: a Systems Manager Automation runbook that Config runs against the noncompliant resource, manually or automatically with a retry limit. For example, restricted-ssh paired with the AWS-owned runbook AWS-DisablePublicAccessForSecurityGroup removes rules that open SSH and RDP to the world, with an automation role (passed as the runbook's assume-role parameter) that holds the permissions to make the change. Without remediation, Config only reports.

Conformance packs bundle Config rules and their remediation actions into one template deployed as a unit; sample packs map to common frameworks. To roll one out across the organization, deploy an organization conformance pack from the management account or, preferably, from a delegated administrator account registered for Config; it lands in every member account (and new ones) and is reported at the pack level. Config compliance also feeds AWS Security Hub CSPM security standards, which aggregate findings into a posture score — the continuous-monitoring half of skill 4.1.5. (Reporting and remediating findings across Security Hub, GuardDuty and Inspector is covered in the data protection and security services lesson.)