CCNA Identity and Access Management Questions

An IAM role is the correct entity for granting temporary access because it is designed to be assumed. When a principal assumes a role, AWS STS returns temporary security credentials with a limited lifetime, governed by the role's trust policy and permissions policy. This is the standard mechanism for federated access, cross-account access, and EC2 instance profiles.

Create an IAM role with an S3 access policy, then place that role in an instance profile and attach the profile to the EC2 instance at launch or via the console/API. When the instance starts, it uses the role's trust policy to assume the role and receives temporary credentials from the instance metadata service (IMDSv1 or IMDSv2) that are automatically rotated. The SDK then uses these credentials to sign requests to S3 for the duration of the role session, enforcing the exact permissions granted by the role while avoiding the need to embed static keys.

Service control policies set permission guardrails across an AWS Organizations root, and an explicit deny for iam:CreateUser applies to every principal in every member account, including account administrators. This centrally prevents new IAM users organisation-wide, satisfying the requirement without editing each account individually.

This statement is correct because the resource ARN uses the ${aws:username} variable, which automatically resolves to the IAM user name making the API call. The resulting ARN matches only that user's own IAM user resource, restricting CreateAccessKey, UpdateAccessKey, DeleteAccessKey, and similar key actions to the caller's own keys. This is the standard pattern for delegating self-service access key management while preserving separation of duties.

iam:ChangePassword is the precise self-service action that enables a user to update their own console password (or password used for programmatic access via the password-based APIs). When a user calls ChangePassword, IAM verifies the existing password and then replaces it, with the permission scoped to the principal's own identity. It is the only action among these options that directly corresponds to the requirement of letting a user change their own password.

The simulator's explicitDeny result for iam:DeleteUser can only be produced by a Deny statement within the policy. In IAM's evaluation logic, an explicit Deny always overrides any Allow, making the action undeniably forbidden regardless of other permissions. This matches the correct interpretation of the simulation output, as the policy visibly contains a statement that rejects DeleteUser.

Requiring server-side encryption via the 's3:x-amz-server-side-encryption' condition key is a valid access restriction because it makes the presence and value of the x-amz-server-side-encryption header a precondition for the S3 operation. For example, you can require that the header equals AES256 or aws:kms, which denies requests that do not carry an encryption header even if the principal otherwise has s3:PutObject permission. This condition key is evaluated per request, giving you fine-grained, attribute-based control that enforces encryption compliance on all uploads.

The aws:PrincipalOrgID condition key is a global condition that checks the organization ID associated with the principal's account, allowing you to require that the principal comes from an account that is a member of a specified AWS organization. In a resource-based policy, it directly validates organizational membership for cross-account access, making it the appropriate choice for ensuring that only principals from your organization can access the resource.

Federated users, such as those authenticated by an external identity provider via SAML 2.0 or web identity federation, can assume an IAM role to obtain temporary AWS credentials. The user's original identity is mapped to a role, and AWS STS issues scoped, time-limited access keys that abide by the role's trust and permissions policies. This allows external identities to access AWS resources without creating an IAM user and without distributing permanent credentials.

A permissions boundary with an explicit Deny for cloudtrail:StopLogging and Allow for required actions ensures no identity-based policy can override the deny. The boundary caps maximum permissions, so even if an administrator later attaches a broad policy, the deny remains effective. This directly enforces the requirement without blocking unrelated operations.

An explicit Deny statement in the bucket policy takes precedence over every Allow, including the IAM role's identity-based permissions. In AWS authorization, the evaluation first defaults to deny, then any allow from identity-based or resource-based policy, but if an explicit deny exists in either policy, the final decision is deny. Thus if the bucket policy contains a statement that denies this role (or the role's account) the s3 operation, access will be blocked even though the role policy appears to grant the necessary permissions.

This is the correct next step. Permission sets define the level of access (e.g., read-only, admin) and are assigned to IdP groups for specific AWS accounts. This leverages the group membership from the IdP to grant access without creating individual IAM users. It centralizes management and ensures that users get the right permissions in the right accounts.

Unused access keys are dormant credentials that an attacker can abuse without the legitimate owner noticing, and they are frequently omitted from routine code and permission reviews. AWS provides the IAM credential report and the LastUsed timestamp for each key, so you should regularly identify keys that have not been used for 90 days and deactivate or delete them to reduce the total attack surface and simplify incident investigation.

The aws:PrincipalArn condition key matches the full ARN of the IAM principal (user or role) that is making the request. For a VPC endpoint policy controlling access to Amazon S3, you can specify a role ARN as the value, ensuring only requests signed with that role's credentials are allowed through the endpoint. This is the correct way to restrict access to a specific IAM role because it directly inspects the principal identity rather than the network source.

A service control policy (SCP) acts as a permission boundary for all IAM principals in an AWS account. In this scenario, the SCP's condition was written with incorrect scoping—it likely used a condition key that did not match the SecurityAdminRole's principal ARN, or failed to include an exclusion for that role—so the explicit deny in the SCP applied to every principal, including SecurityAdminRole. Because an explicit deny in an SCP overrides any allow from an identity-based policy, the role's IAM permission to call cloudtrail:StopLogging was ineffective, leaving the deny intact and blocking the stop action.

This is the correct minimum-privilege policy because it grants exactly the three write actions required for access key rotation: 'iam:CreateAccessKey' to generate a new key pair, 'iam:UpdateAccessKey' to change the old key's status to Inactive, and 'iam:DeleteAccessKey' to remove the old key. The resource ARN 'arn:aws:iam::*:user/${aws:username}' uses the policy variable '${aws:username}', which is dynamically replaced with the caller's IAM user name, so each user can only manage their own access keys. This adheres to least privilege and is the AWS-recommended pattern for self-service key rotation.

Creating an IAM role with the necessary S3 permissions and attaching it as an instance profile is the AWS-recommended best practice. The EC2 instance receives temporary security credentials through the instance metadata service (IMDS), and the AWS SDKs automatically retrieve and refresh those credentials before they expire. This avoids storing any long-term keys on the instance, enforces least-privilege permissions scoped to the role, and gives you automatic rotation without manual intervention.

Long-term IAM user credentials, an access key ID and secret access key, are the canonical way to sign AWS API requests via Signature Version 4. These credentials are used for programmatic access through the AWS CLI, SDKs, or direct HTTP calls, and must be protected with least-privilege IAM policies and rotated regularly because they do not expire by default.

IAM roles support cross-account access by allowing a principal from another AWS account to assume the role, provided the role's trust policy explicitly lists that account as a trusted entity. Once assumed, the principal gains the permissions attached to the role, enabling secure federation between accounts without sharing long-term credentials. This is a common pattern for centralized management or delegated administrative tasks across AWS environments.

Adding a bucket policy that explicitly allows the IAM role to perform s3:PutObject is a correct and often necessary step because S3 uses resource-based policies to control access at the bucket level. Even if the role has an identity-based policy permitting s3:PutObject, a bucket policy can grant the role as an explicit principal, which is particularly important in cross-account scenarios or when the bucket's AWS account uses S3 bucket owner enforced settings. In a same-account setup, this policy and the role policy work together to ensure the API call is allowed under the S3 policy evaluation model.

An IAM role with an instance profile is the correct approach because it provides temporary credentials to the EC2 instance through the instance metadata service (IMDSv2). The EC2 service assumes the role on behalf of the instance, and the credentials are automatically rotated and never stored as static secrets on disk. This follows the AWS security best practice of using temporary credentials for all applications running on EC2.

In cross-account S3 access, the requesting IAM role must have an identity-based permissions policy that explicitly allows s3:GetObject on the specific bucket. The bucket policy alone is insufficient; if the role lacks the necessary IAM permissions, the request is denied even when the bucket policy states that access is allowed. This missing permissions policy is the most common root cause when a role cannot read from a bucket it was supposedly granted access to.

This is the correct foundational enforcement mechanism: a Deny statement with a Bool condition on aws:MultiFactorAuthPresent. When the key evaluates to "false", the request is denied, so any API or console action by a user who did not authenticate with MFA fails. The policy can be scoped with NotAction to permit MFA self-management tasks, ensuring users can enroll without being locked out. This condition-based denial is what actually enforces MFA, unlike audit-only measures.

Permission sets are the correct IAM Identity Center construct because they define reusable collections of AWS permissions, similar to IAM roles, that can be assigned to users or groups across multiple AWS accounts. You attach managed policies, customer managed policies, inline policies, permissions boundaries, and session duration to a permission set, then assign it to accounts and principals. Using permission sets lets you enforce least privilege consistently across the entire AWS Organization and change permissions in one place, which is exactly what a multi-account user-access solution requires.

To launch an EC2 instance with an IAM role, the caller must have iam:PassRole permission for that role. An SCP that denies iam:PassRole blocks this action, so the RunInstances call fails. Even though ec2:RunInstances is allowed, the missing PassRole permission prevents the role association, making the launch unsuccessful. This is the intended security control.

The IAM policy grants ec2:RunInstances but includes a Condition element that restricts the ec2:InstanceType to t2.micro. When the user attempts to launch any other instance type, the condition fails, causing the action to be denied even though the principal has an Allow for the action. This is an implicit deny resulting from the condition not being satisfied, not a missing action or a separate limitation. Thus, the exact reason the launch is blocked is the requested instance type falls outside the allowed value.

Deactivating the user in the connected identity provider is the correct action because AWS SSO relies on the IdP as the authoritative identity source. Once the user is disabled in Active Directory (or another connected IdP), they can no longer authenticate to the AWS access portal, so no new SSO sessions or temporary AWS credentials can be issued. Any active role sessions inherited from a prior sign-in remain only until their configured session duration expires, but this operation is the only option that cleanly terminates access at the identity's source.

When a request reaches S3 through a VPC endpoint, the request context includes the endpoint ID, so an IAM policy can use the aws:SourceVpce condition to require that the request came from that specific endpoint. This effectively blocks access from public internet or other VPCs even if the IAM principal is valid. It is a common pattern for enforcing network-layer isolation in addition to identity-based permissions.

Permissions boundaries are a valid use case to prevent IAM users from escalating privileges because they set a hard ceiling on the maximum permissions a principal can receive. Even if a user is allowed to attach IAM policies to their own role, the effective permissions are the intersection of the attached policy and the boundary, so they cannot grant themselves additional privileges beyond the boundary. This mitigates the risk of an IAM user creating an administrative policy or modifying their own permissions to gain elevated access.

Create an IAM execution role granting the Lambda function the minimal CloudWatch Logs permissions required (e.g., logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents) and attach that role to the function via the function's configuration. This identity-based policy defines what the function can do as its authorized identity, allowing it to write logs securely. Following least privilege here is correct because the role grants only the specific log-writing actions, not broader access.

This is the correct answer because an SCP attached to the root organizational unit is immediately inherited by all member accounts and acts as a preventive guardrail that cannot be overridden by any IAM policy, including the account administrator. Explicitly denying iam:CreateRole stops creation of new roles, and denying iam:UpdateAssumeRolePolicy prevents an attacker from modifying an existing role's trust policy to assume it from an untrusted account. Unlike reactive controls, SCPs take effect before the API call is allowed, and they can be managed centrally by the organization's management account.

This IAM policy statement uses a Deny effect with the aws:SecureTransport condition key set to 'false', so it blocks any API call that was not transmitted over a TLS/HTTPS connection. Because an explicit Deny takes precedence over all Allow statements, the policy stops every non-HTTPS request to any AWS service, while leaving HTTPS requests unaffected. The condition applies to the transport-layer security of the request itself, not to the specific action or resource, making the statement a global enforcement of HTTPS for all AWS API operations.

This is the most likely reason. To enforce MFA, the policy must include a condition such as 'aws:MultiFactorAuthPresent': 'true' in a Deny statement. If the condition is missing or misspelled, the deny will not trigger. Additionally, the condition must be in a policy that applies to the users' actions. Often, administrators forget to include the condition or use the wrong key, allowing actions without MFA.

A permissions boundary caps identity-based policies: the principal can only perform actions allowed by both. Effective permissions therefore equal the intersection, so an action permitted by the identity policy but absent from the boundary is denied.

Cross-account role assumption requires two grants: the trusting account's role trust policy must name the external principal, and the external account's IAM policy must permit that principal to call sts:AssumeRole. Both sides must allow it.

The policy explicitly grants IAM permissions such as iam:CreateUser and iam:CreateAccessKey. This allows an authenticated user to provision a new IAM identity and associated programmatic credentials, effectively creating a backdoor account with permissions that can be escalated to full administrative access. Because the new user and access key are fully functional and can be granted additional policies, this action represents a high-risk privilege escalation vector.

This is the correct and canonical method. Create an IAM role that includes a policy granting the `dynamodb:GetItem` action on the `Orders` table, define a trust policy that lets the EC2 service (`ec2.amazonaws.com`) assume it, and then create an instance profile containing that role. When you launch the EC2 instance with the instance profile, AWS automatically supplies temporary credentials through the instance metadata service (IMDSv2), so the SDK can read from DynamoDB without any stored keys. This avoids long-lived credentials and is the supported mechanism for giving an EC2 instance permissions.

AWS IAM Identity Center (formerly AWS SSO) is the purpose-built service for centrally managing workforce access and single sign-on across multiple AWS accounts, business applications, and SAML 2.0/OIDC-capable solutions. It can connect to an external identity provider (such as Okta or Azure AD) and map that provider's identity groups to AWS permission sets, issuing temporary credentials for the console or CLI. This makes it the correct choice for allowing employees to authenticate to AWS with their existing corporate credentials.

Correct. The trust policy of the role in Account B must include Account A as a trusted entity, and the user in Account A must have the sts:AssumeRole permission (via an IAM policy attached to their user or group).

AWS CloudTrail records S3 API activity, including object-level data events when enabled, satisfying the compliance requirement to log all bucket access. Unlike S3 server access logging, which captures only bucket-level requests, CloudTrail delivers detailed API call records to an S3 bucket or CloudWatch Logs for auditing.

Cross-account access needs two sides: the trust policy in the owning account and an identity-based policy in the external account granting sts:AssumeRole on the role ARN. Without that permission attached to the calling principal, the AssumeRole call is denied.

IAM roles for Amazon EC2 instances provide temporary security credentials through the instance metadata service, eliminating the need to store any long-term secret material inside the instance. These credentials are automatically rotated and can be scoped with a precise permissions policy, so even if the instance is compromised, the blast radius is limited. This approach also simplifies key management because there is no auth material to embed, rotate, or revoke individually.

This trust policy is correct because it grants the external account's root principal (arn:aws:iam::123456789012:root) permission to call sts:AssumeRole only when the aws:MultiFactorAuthPresent condition evaluates to true. This enforces that any IAM principal from that account must have authenticated with an MFA device before assuming the role, which is a security best practice for external auditors. Using the account root ARN as Principal is the standard pattern because it delegates the actual user and role management to the external account.

IAM policy conditions allow you to add context-aware requirements to an allow statement, such as restricting the source IP with 'aws:SourceIp', requiring an MFA token with 'aws:MultiFactorAuthPresent', or limiting EC2 actions based on resource tags with 'ec2:ResourceTag'. This goes beyond identity alone by enforcing that the request also looks like it comes from a trusted network or satisfies other organizational controls. Conditions are a core defense against stolen credentials and are essential for implementing least privilege in real-world environments where access should depend on more than just who is calling.

For SAML federation, the correct pattern is an IAM role with a trust policy that grants sts:AssumeRoleWithSAML to the SAML identity provider you create in IAM. The corporate Active Directory is the external IdP (for example, AD FS or Shibboleth), and the trust policy uses the IAM SAML provider's ARN as the principal, often with an audience condition of urn:amazon:webservices. When a user authenticates to AD, the IdP issues a SAML assertion, AWS validates it against the SAML provider, and the user receives temporary credentials scoped by that role's permissions. This achieves single sign-on without creating or maintaining AWS credentials for each AD user.

This is correct: an overly broad trust policy—for example `"Principal": "*"` without restrictive conditions—allows any AWS principal from any account to call `sts:AssumeRole` and obtain the role's temporary security credentials. Once assumed, the attacker receives all permissions attached to the role, enabling unauthorized actions in the account. In the absence of conditions like `aws:PrincipalArn`, `aws:PrincipalAccount`, or an external ID, there is no mechanism to distinguish legitimate principals from external attackers, so the role effectively exposes its permissions to the entire AWS ecosystem.

IAM roles allow EC2 instances to obtain temporary security credentials automatically through instance profiles, eliminating the need to embed long-term access keys on the instance. These temporary credentials are vended via the instance metadata service and are rotated by AWS STS, reducing the risk of leaked keys and their blast radius. Roles also let you enforce least privilege cleanly, because you can attach narrowly scoped policies to the role and update them without modifying the instance.

aws:SourceVpce is the correct condition key because it restricts access to requests that arrive through a specific VPC endpoint, identified by its endpoint ID (e.g., vpce-1234567890abcdef0). This condition is evaluated based on the endpoint's identity, which cannot be spoofed or altered through IP address translation, providing a reliable network-level control. It ensures that only traffic coming from that exact VPC endpoint is allowed to access the S3 bucket.

The Resource element is the only policy element that specifies which service resources the action applies to, using Amazon Resource Names (ARNs). To grant an IAM user access to a specific S3 bucket, you must include that bucket's ARN in the Resource field, optionally with a wildcard for objects. Without the correct Resource entry, the policy cannot define the scope of access needed.

aws:ResourceTag allows you to write a condition such as StringEquals: aws:ResourceTag/Project: Dev, which is evaluated against tags attached to the resource that the request targets. This AWS global condition key supports attribute-based access control and works in both identity-based and resource-based policies. It directly enforces that a developer can only perform an action when the specific resource has the required tag key-value pair, making it the correct choice for this requirement.

This is the correct least-privilege policy: it restricts the s3:GetObject action to a specific Resource ARN, arn:aws:s3:::my-bucket/*, which matches only objects inside the my-bucket bucket. The lack of s3:ListBucket permission is fine for direct object retrieval—the caller must know the object key, but that matches the requirement of granting access to the bucket's objects. The policy contains no wildcards beyond the object-name segment (*), so it does not grant access to other buckets or to bucket-level operations like listing. This scoping aligns with AWS's recommended practice of using resource-level permissions for S3 actions and is the only option that satisfies the principle of least privilege.

When environment variables are set, the AWS SDK prioritizes them over the instance profile credentials. If those credentials are expired or have insufficient permissions, the application will receive access denied errors even though the instance profile role has the correct permissions. The SDK does not fall back to the instance profile when explicit credentials are provided.

Adding a bucket policy with a Deny effect and the condition `aws:SecureTransport: false` will reject any request that is not sent over SSL/TLS. This is the most direct and comprehensive way to enforce HTTPS on S3 because the bucket policy is evaluated for every request to the bucket, regardless of which IAM principal, account, or anonymous user makes it. Using a resource-based policy at the bucket level also aligns with AWS best practices for S3 security and is the recommended mechanism to mandate encrypted connections.

An IAM role attached to the instance profile supplies temporary, automatically rotated credentials to the EC2 instance, avoiding long-term access keys on the instance. This satisfies the requirement for read-only S3 access using the most secure mechanism.

Launching an EC2 instance requires more than the `ec2:RunInstances` action; the policy must also allow dependent resources. The `RunInstances` call authorises each referenced AMI, security group, subnet and key pair, so a policy granting only the run action fails with `AccessDenied` when those resource-level permissions are absent.

Create an IAM role with a policy allowing s3:GetObject on the specific bucket and object ARNs, then set that role as the Lambda function's execution role. The role's trust policy must allow lambda.amazonaws.com to assume it, after which Lambda calls STS to receive temporary credentials scoped to that role. These credentials are automatically rotated and passed to the AWS SDK, making this the least-privilege, auditable way to grant the function read access to S3.

aws:MultiFactorAuthPresent is the correct global condition key because it is a Boolean request context key that indicates whether the principal authenticated with an MFA device. By adding a condition such as "Bool": {"aws:MultiFactorAuthPresent": "true"} to an IAM policy, administrators can require every matching request to come from a session that has completed MFA. This directly enforces the organization's MFA requirement and cannot be substituted by IP, client, or time-based checks.

Defining an account password policy is a core IAM feature: IAM provides the UpdateAccountPasswordPolicy API and a dedicated console page to enforce policies such as minimum password length, complexity, expiration, and reuse prevention for all IAM users. This policy is stored and enforced by the IAM service as part of its identity-management responsibilities. Since IAM directly manages user credentials, password policy configuration is one of the two actions correctly performed using AWS IAM.

This is the correct enforcement pattern: a Deny statement with the condition aws:MultiFactorAuthPresent equal to false (or using BoolIfExists to treat a missing key as false) explicitly blocks every action from principals that did not use MFA. Because explicit Deny statements take precedence over any Allow, attaching this policy ensures no other policy can accidentally allow unauthenticated-with-MFA access. This is the standard AWS-recommended way to enforce MFA across all AWS API actions.

The SCP explicitly denies all DynamoDB actions for the OU, and service control policies are evaluated before IAM identity policies. Because a deny in an SCP always takes precedence over an allow in an IAM policy, the user's PutItem call will be denied even if the attached IAM policy grants it. This is the correct outcome under AWS's policy evaluation model.

An identity-based IAM policy attached directly to the user grants that user the specified S3 actions on the bucket. This is a standard, valid mechanism for granting an IAM user access, independent of any bucket policy or group membership.

The Deny statement's resource element is scoped to the exact ARN of the requested object, so it matches this specific GetObject call. In IAM's evaluation logic, an explicit Deny that matches the action and resource is an absolute veto: it overrides all Allow statements and default-deny is not even reached. Consequently, the download fails with AccessDenied because the request is explicitly denied, not because of any other condition or lack of permission.

An explicit deny statement in a bucket policy always overrides any allow granted by an IAM policy, regardless of how specific or broad that allow is. Here, even if the developer's IAM user is explicitly allowed `s3:ListBucket` by an identity-based policy, a bucket policy that contains a matching `Effect: "Deny"` for that principal (or a deny condition that matches the user) will make the request fail with AccessDenied. This is the only option that explains a denied request despite valid credentials and an otherwise permissive IAM setup.

This is correct because AWS IAM policy evaluation uses a single decision tree in which any explicit deny overrides all allow statements, regardless of where those allows originate. The IAM policy allows s3:GetObject, but the bucket policy contains an explicit deny for the same action and principal. That explicit deny takes precedence, causing the request to be denied. This fundamental rule ensures that explicit deny statements are always authoritative over allows.

This is the correct approach because it uses an IAM role with a trust policy that explicitly delegates the ability to assume the role to the development account. When the development account calls sts:AssumeRole, it receives temporary, automatically rotating credentials scoped to the permissions policy attached to the role, so no long-term access keys are stored or shared. The trust policy should also include a condition such as aws:SourceAccount to protect against the confused deputy problem and ensure only the intended development account can request the role.

IAM roles are the correct mechanism because they support cross-account trust relationships: the organization can configure a role in a target account with a trust policy allowing principals from a central account to assume it. When a user or service in the central account calls sts:AssumeRole, AWS STS returns temporary credentials scoped to the role's permissions policy, enabling centrally governed access across accounts. This is the standard way to grant access to AWS accounts, and it can be combined with AWS Organizations' central management for auditing and policy enforcement.

Attaching an IAM role to the EC2 instance profile allows the instance to retrieve temporary security credentials from the instance metadata service (IMDSv2). The SDK automatically calls the Amazon EC2 metadata endpoint (http://169.254.169.254) to obtain an access key, secret key, and session token, which are then used for API requests. These credentials are temporary, automatically rotated, and carry only the permissions defined by the role's policy, avoiding any embedded secrets.

AWS STS is the service that issues temporary, limited-privilege credentials through APIs like GetSessionToken, AssumeRole, and GetFederationToken. These credentials consist of an access key ID, a secret access key, and a session token, and they automatically expire after a configurable duration, ranging from 15 minutes to 36 hours depending on the API used. This reduces the risk of long-term credential exposure and is the correct IAM feature that directly grants temporary credentials.

This is the correct approach because an IAM role attached to an EC2 instance profile securely provides the instance with temporary credentials through the instance metadata service. The role enforces least-privilege permissions for S3, automatically rotates credentials, and eliminates the need to embed long-term keys, aligning with AWS security best practices and following the principle of granting only the required access.

The aws:SourceVpce condition key can be used to restrict access to requests that come through a specific VPC endpoint. Adding this condition ensures that the user can only access objects when the request originates from that endpoint, meeting the requirement to limit access to a specific VPC endpoint.

This is the complete cross-account access solution: the role's trust policy allows the user's account to assume the role, and the bucket policy grants the role's ARN explicit permission to perform S3 actions. The user calls sts:AssumeRole and receives temporary credentials scoped to the role, then uses those credentials to access the bucket; the bucket policy recognizes the assumed-role principal. Both policies are necessary because the trust policy does not confer resource permissions, and the bucket policy does not grant the ability to assume the role.

AWS CloudTrail records API activity across the account, capturing every IAM action as a management event with caller identity, timestamp and source IP. This satisfies the requirement to audit all IAM actions, since CloudTrail logs control-plane operations by default. CloudWatch, Config and Trusted Advisor do not provide this comprehensive API audit trail.

Effective permissions for any principal are always the intersection of all applicable policies: the permissions boundary acts as a ceiling, and the identity-based policy (e.g., attached to the role) acts as the grant. The IAM engine evaluates both, and an action is permitted only if it is allowed by the identity-based policy, not denied by the boundary, and not denied by any other policy (like a service control policy or resource policy). This intersection model is the fundamental logic of IAM permissions boundaries: the boundary limits the maximum permissions, but the identity policy must still explicitly grant the action within that limit.

Launching an EC2 instance is an ec2:RunInstances API call, and IAM requires a separate, explicit authorization for that action. A policy that grants iam:PassRole only authorizes the developer to attach a pre-existing role to a resource; it does not authorize creating or starting the instance itself. Without ec2:RunInstances permission, AWS denies the request even though the PassRole policy is valid, so this is the correct reason for the failure.

CloudWatch Logs requires exactly these three log actions for a Lambda function to create its log group, stream and write events. Omitting any action causes logging to fail, so this is the minimum viable set.