CCNA IAM Questions

AWS CloudTrail records API activity across the account, including every IAM create, update, and delete operation, with the identity, timestamp, and source IP. This provides the complete audit trail the security team needs to track all IAM resource changes.

SCPs apply to all principals in the account.

Because the only Allow statement in the attached group policy is conditioned on both a permitted source IP range and HTTPS (SecureTransport=true), a request coming from an IP outside that range does not satisfy the source IP condition. In IAM evaluation, an Allow with unsatisfied conditions contributes no effective permission, and since no other applicable statement grants the action, the default-deny rule applies. The user is therefore denied even though HTTPS might be used.

An IAM user password is the primary authentication factor for the AWS Management Console, entered together with the account ID or alias at the sign-in page. This password is stored as a login profile for the IAM user and can be rotated manually by the user or administratively by an account administrator. It functions as a persistent credential that grants full access to the console session. This is one of the two standard ways to authenticate an IAM user.

Enforcing least privilege means granting only the specific API actions and resources required for the application's function, and then further constraining them with conditions such as ec2:ResourceTag or aws:SourceIp. This limits the blast radius if the instance is compromised because a breached application can only perform the minimal set of operations. A role's policy is the sole authority for what temporary credentials obtained through the instance profile can do, so its precision directly determines the security posture.

IAM Access Advisor reports the last-accessed timestamp for each service the developer actually used. Building a custom policy from that historical usage removes unused permissions, achieving least privilege without breaking required workflows, unlike blanket administrator access.

An IAM condition using aws:SourceIp restricts valid S3 requests to a specified CIDR range, ensuring credentials are only usable from your corporate or trusted network and shrinking the attack surface. This complements least-privilege actions by adding a network-layer control, but remember that if the request goes through a VPC endpoint, aws:SourceIp is not evaluated and you must use aws:sourceVpce instead. It is a valid, cost-free way to reduce exposure.

In AWS IAM Identity Center, access to an AWS account is granted only after an account assignment links the user (or a group containing them) to a permission set in that account. The assignment is what provisions the temporary IAM role credentials, so without it the portal might still list the account but authorization fails because no IAM role exists for that user. This missing assignment is exactly the root cause and must be created in the console or CLI before access is possible.

This is the exact definition of iam:PassRole: it permits a user to specify an existing IAM role as a configuration parameter for an AWS service, such as setting the execution role for a Lambda function or the instance profile for an EC2 instance. The user is not assuming the role themselves, but rather delegating the role to the service so that the service can use its permissions after assuming it via its trust policy.

Amazon Cognito identity pools are purpose-built for granting temporary AWS credentials to mobile app users. When an identity is authenticated (via Cognito User Pools, social providers, or SAML), the identity pool exchanges the user's token for short-lived credentials by assuming an IAM role. These credentials are scoped to that role's permissions and automatically expire, eliminating the need to embed or manage long-term access keys. This is the standard serverless pattern for secure mobile access to AWS APIs.

This is correct because an IAM policy's Allow effect only takes effect when all conditions are satisfied. The IpAddress condition restricts valid source IPs to 192.0.2.0/24; if a request originates outside that range, the condition fails and the Allow does not apply. Since no other statement explicitly allows the action, the request is implicitly denied by default.

The policy statement uses "Effect": "Deny" with a condition key "aws:SecureTransport" set to "false". Since "Resource" is "*", it denies every S3 API action—on any bucket or object—when the request is transmitted over HTTP without TLS. This is a standard pattern to enforce HTTPS: any request where the secure transport boolean is false is blocked, while HTTPS requests remain unaffected by this statement.

Creating an IAM role and attaching it to the EC2 instance profile is the AWS-recommended pattern. The instance profile securely delivers temporary credentials to the instance through the instance metadata service (IMDSv2), and the AWS SDKs automatically retrieve and refresh these credentials. Permissions are scoped to the role's policy, no secrets are stored on disk or in source code, and credentials rotate automatically, minimizing the blast radius of any single credential leak.

The IAM policy includes a condition that requires requests to originate from the VPC endpoint (e.g., aws:SourceVpce). If the EC2 instance routes traffic over an internet gateway to DynamoDB's public endpoint, the source is the internet gateway, not the VPC endpoint, so the condition fails. This mismatch directly explains the access denied error. To resolve it, the instance should route DynamoDB-bound traffic through the VPC endpoint, or the condition must be changed to align with the actual traffic path.

A service control policy (SCP) applied at the root organizational unit centrally enforces the 90-day access key age limit across all accounts. SCPs can use a condition like 'aws:AccessKeyAge' to deny actions (e.g., 'iam:CreateAccessKey') when the age exceeds 90 days. This is the most efficient because it's a single policy that applies to all accounts without per-account configuration or manual auditing.

Enabling MFA for all IAM users is a core AWS security best practice because it requires something the user has, such as a TOTP device or U2F key, in addition to a password or access key. This materially reduces the risk that a stolen password or access key alone can be used to access the account, and AWS recommends MFA for every user including root. MFA protects against credential theft and is an explicit requirement for privileged accounts in many compliance frameworks.

The trust policy, also called the assume-role policy, is attached to the IAM role and grants the external AWS account permission to call sts:AssumeRole, with the account ID listed as the Principal. When the external account's IAM users or roles have permission to use that trust relationship, AWS then issues temporary credentials scoped by the role's permissions policy. This is exactly the cross-account role assumption pattern required to give the external account access.

The correct approach is to create a custom IAM role with a policy that grants only the required DynamoDB actions (e.g., GetItem, Query) on the specific table ARN, and then assign that role to the Lambda function as its execution role. At runtime, Lambda uses this role to obtain temporary credentials through AWS STS, which are automatically rotated and scoped to the policy. This follows the principle of least privilege because the function can only perform the exact actions on the exact table it needs, minimizing the blast radius of a compromise. It is the AWS-recommended best practice for granting Lambda functions access to AWS services.

Lambda functions assume an execution role via the service principal lambda.amazonaws.com. The trust policy must allow that principal to call sts:AssumeRole. The permissions policy then grants secretsmanager:GetSecretValue on the secret ARN, enabling the function to retrieve credentials securely without embedding them in code. This is the standard, least-privilege approach for Lambda accessing Secrets Manager.

In IAM, the default behavior is to deny access, but that default is overridden by any applicable allow statement from another policy. This policy only allows RunInstances when the specified condition keys match; it does not explicitly deny RunInstances when the conditions are not met. Consequently, if the user has any other identity-based or resource-based policy that allows RunInstances without conditions, the user can still launch non-compliant instances. An explicit Deny statement using a condition like StringNotEquals (or a NotCondition) would be required to block those non-compliant launches, making the missing deny the root cause.

By setting the Principal to "arn:aws:iam::111111111111:root", the trust policy authorizes all IAM users and roles within account 111111111111 to assume the role. This root principal syntax is idiomatic for granting an entire account access, including both current and future IAM principals in that account. The policy does not restrict to a specific user or role, so the correct interpretation is that the whole account is permitted.

AWS Security Token Service (STS) is the service that issues short-lived credentials composed of an access key ID, secret access key, and session token, exactly what an IAM user needs for temporary access. By calling sts:AssumeRole (or GetFederationToken), the developer can request a role's permissions for a configurable duration and receive credentials that expire automatically. This matches the requirement: STS is the correct service for granting temporary access to AWS resources.

AWS Single Sign-On (now AWS IAM Identity Center) authenticates users by acting as a broker between AWS and a trusted external identity provider, such as Okta, Azure AD, or a built-in identity store. It validates the user's credentials through the IdP and then issues temporary AWS credentials or federation tokens, making it a fully functional authentication service for workforce users.

ec2:InstanceType is the IAM condition key specifically intended for restricting the type of EC2 instance a principal can launch, and it can be used with the ec2:RunInstances action. By applying, for example, a StringLike condition of "t3.*" or "t3.micro", an administrator can deny all other instance families and sizes. This key is evaluated as a request-level condition during the RunInstances call, so it directly matches the requirement to control which instance type a user is allowed to create.

The iam:PassRole error occurs because the role ARN in the request does not exactly match the Resource element in the policy. IAM evaluates ARNs literally, so any mismatch in account, path, or role name denies the action despite the Allow.

For cross-account access, the resource owner must explicitly grant the external account or its principal access in the resource-based policy. This policy defines the trust relationship because it specifies who can access the resource and what actions they can perform. Without this allow, the request fails even if the caller has valid IAM permissions in their own account.

A bucket policy in Account A can specify the Amazon Resource Names (ARNs) of IAM users from Account B in the Principal element, granting them explicit actions such as s3:GetObject on the bucket and its objects. For this to work, those IAM users also need an identity-based policy in Account B that allows the corresponding S3 actions, but the bucket policy is what authorizes the cross-account access at the resource level. This approach is precise, auditable, and follows least privilege because only the named IAM users get access, not any broader principal.

AWS Organizations is a governance service that lets you centrally manage multiple AWS accounts by organizing them into organizational units and applying service control policies (SCPs). SCPs define the maximum allowed permissions for every IAM principal in an account, effectively managing identity and access by creating guardrails at the organization level. This makes Organizations a correct service for managing identity and access across accounts.

A custom IAM policy should be scoped to the exact S3 actions the application requires, such as s3:GetObject and s3:PutObject, and limited to the specific bucket ARNs and optional prefixes. When attached to the instance role, this policy ensures the temporary credentials issued to the EC2 instance can perform only the intended S3 operations, aligning with the least-privilege principle. This is the standard and recommended way to control S3 access for EC2 roles.

After an IAM user signs in to the console with only a password, the resulting temporary credentials have aws:MultiFactorAuthPresent set to false. An explicit deny policy using that condition key will block every console action, forcing the user to either re-authenticate with MFA or call STS GetSessionToken with MFA to obtain valid credentials. This effectively enforces MFA for all console access and directly satisfies the stated requirement for production users.

IAM groups are the recommended way to organize permissions by job function: you attach a managed policy (AWS-managed or customer-managed) to the group, and any user added to the group automatically receives those permissions. This separates identity management from permission management, so updating a group policy affects all members consistently, and you can onboard/offboard users simply by adding or removing them from the group. Groups also help you adhere to least privilege without duplicating policy content across individual users.

An explicit Deny in any attached identity policy, permissions boundary or AWS Organizations SCP always overrides Allow, producing explicitDeny in the simulator. The Allow in the supplied policy cannot take effect while that deny remains in force.

Amazon Cognito identity pools (federated identities) are the correct choice because they are specifically built to trade identity tokens—from Cognito user pools, social IdPs, or custom OIDC providers—for temporary AWS credentials. Internally, this uses AWS Security Token Service (STS) actions like AssumeRoleWithWebIdentity, and the resulting credentials are automatically refreshed by the AWS mobile SDKs. They also support unauthenticated guest access when guest users need limited access. This maps the authenticated/unauth user to an IAM role with fine-grained permissions to AWS resources.

The policy grants RunInstances only when the ec2:InstanceType condition key exactly equals t2.micro, so a request for m5.large does not satisfy the condition and is implicitly denied. IAM evaluation requires an explicit Allow to match all parts of the request—action, resource, and condition—and because the condition fails here, the request falls through to the default deny, producing AccessDenied. This is the correct explanation because the user did have permission to launch instances, but only for the specific instance type t2.micro, not m5.large.

Because the trust policy allows 'sts:AssumeRole' from any principal (often expressed as 'Principal': '*'), any IAM user in any AWS account can call the STS API to assume this role. Upon successful assumption, AWS returns temporary credentials bound to the role's permission policy, so the user gains whatever access that policy grants. This is precisely the overly permissive condition that makes the role dangerous.

A VPC endpoint policy is an additional authorization boundary for S3 traffic routed through the gateway endpoint. Even when the IAM role explicitly allows s3:GetObject and the bucket policy permits the request, the endpoint policy must also allow the action; if it only allows s3:ListBucket or omits the operation, the request is denied. S3 evaluates the endpoint policy alongside the IAM role's permissions, and any missing allow from this policy results in AccessDenied.

Attaching an IAM role with the appropriate S3 access policy to the EC2 instance profile enables the instance to obtain temporary credentials from AWS STS via the instance metadata service (IMDSv2). The AWS SDK automatically retrieves and rotates these credentials, meaning the application never stores or manages long-lived keys. This follows the principle of least privilege and is the AWS-recommended pattern for granting EC2 instances access to S3, because it ties permissions to the instance itself rather than to a user or stored key.

iam:ChangePassword permits a user to change only their own console password, provided they supply the existing password. It grants no ability to modify other users' credentials, matching the requirement to manage solely their own password.

Allowing `iam:UpdateAccessKey` lets the user activate or deactivate their own existing access keys, satisfying the "update" half of the manage requirement. It does not create keys, so it must be paired with `iam:CreateAccessKey`; together these two actions cover the full create-and-update scope the stem demands.

This policy exactly implements read-only object access by allowing the s3:GetObject action on the objects within the bucket. The resource ARN arn:aws:s3:::my-bucket/* correctly scopes the action to object keys under my-bucket, rather than the bucket itself or all buckets. This grants the user the ability to retrieve object data and metadata while denying writes, deletions, or bucket-level administrative changes.

An IAM role has no embedded long-term credentials such as static IAM user access keys. Instead, it contains a trust policy and permission policies, and when an entity assumes the role, AWS STS issues temporary credentials — an access key ID, a secret access key, and a session token — that expire after a configurable duration between 15 minutes and 12 hours.

This is the correct minimal policy because s3:ListBucket is the exact permission required for the S3 ListObjects/ListObjectsV2 API calls used to list objects and prefixes. The resource is correctly set to the bucket ARN, which is where S3 checks the ListBucket authorization; object-level ARNs like arn:aws:s3:::my-bucket/* are not valid for this action. It is least-privilege because it grants only the ability to list, with no object-level read, write, or delete permissions and no bucket administrative rights.

Attaching the MFA enforcement policy to every IAM user, or to a group that all users belong to, is the required deployment step: IAM policies have no effect until they are attached to an identity. Using a group is the most maintainable approach because new users added to the group automatically receive the policy, and it prevents individual users from being missed. This distribution is what makes the deny-unless-MFA condition universally enforced across the account.

The ability to pass a role (iam:PassRole) combined with permission to launch EC2 instances (ec2:RunInstances) lets the instance specify a different, more privileged IAM instance profile at launch. Because the PassRole permission is often granted broadly without restricting which roles can be passed, the current instance can create a new instance carrying permissions beyond its own, thereby escalating privileges within the account.

Attaching an IAM role as the Lambda function's execution role is the recommended pattern. In the role's trust policy you allow the Lambda service principal, lambda.amazonaws.com, to assume the role; the role's permissions policy then grants the minimal DynamoDB actions needed, such as GetItem or Query. Lambda automatically calls sts:AssumeRole and obtains short-term credentials, so no long-lived keys are ever stored in the function.

For cross-account access, S3 requires an explicit allow from both the resource-based policy (the bucket policy in Account B, which is already in place) and an identity-based policy on the IAM user in Account A. The IAM user's permissions are evaluated separately, and even though the bucket policy grants the Account A root access, the user does not inherit that permission without an explicit identity-based allow. Attaching a policy that grants s3:GetObject on the specific bucket is the necessary, minimal step to complete the authorization chain.

This is the standard cross-account access pattern. The role's trust policy specifies the vendor's account as the principal, allowing its IAM users to assume the role via STS. The permissions policy grants S3 access. No IAM users are created in the company account, and all access is audited through CloudTrail, which logs AssumeRole and S3 API calls. This meets all requirements.

s3:ListBucket is a bucket-level action, so IAM evaluates the Resource against the bucket's ARN (arn:aws:s3:::bucket), not the ARN of objects inside it. A resource pattern that includes only the wildcard for object keys (e.g., arn:aws:s3:::bucket/*) does not match the bucket ARN, because the bucket itself is a distinct resource. Consequently, the allow statement does not cover this request, and the user cannot list the bucket.

In S3, an explicit deny in a bucket policy takes precedence over any allow from an identity-based IAM policy. When a bucket policy includes a Deny statement that matches the principal, action, and resource, the request is rejected regardless of the user's IAM permissions. This is the most direct and common cause of an Access Denied error when the user's IAM policy already grants the s3:ListBucket action.

The Deny statement applies to all actions, including sts:AssumeRole, because its Action element is the wildcard '*'. Its condition, typically 'aws:MultiFactorAuthPresent' being false, is true for a user who has not authenticated with MFA, so the explicit deny is in effect. Under IAM's evaluation logic, an explicit deny always blocks the request, regardless of any other matching Allow statements, so the role assumption fails.

Launching an instance with a resource-scoped IAM policy requires the ec2:RunInstances action to be granted on each dependent resource, including the subnet ARN (e.g., arn:aws:ec2:region:account-id:subnet/subnet-...). If the policy's Resource element omits the subnet but references the instance or AMI, the request fails with an explicit access denied because RunInstances is a 'create' action that conditionally requires subnet permission. This is the exact reason a user can have broad EC2 permissions yet still be blocked for a specific subnet.

AWS CloudTrail records every IAM control-plane API call, including CreateUser and AttachUserPolicy, as management events with the user identity, source IP, and timestamps. By delivering the trail to Amazon CloudWatch Logs and creating a metric filter that matches on the eventName field for these API calls, you can trigger an Amazon CloudWatch alarm to alert a security engineer in near real-time. This gives you both a complete audit trail and an automated detection mechanism, making it the appropriate detective control for this scenario.

Inline policies are identity-based policies that are embedded directly into a single IAM user, group, or role. They are maintained as part of the entity itself, rather than as standalone managed policies, which ensures a strict one-to-one relationship between the policy and the identity. This direct attachment qualifies inline policies as a valid type of identity-based policy in IAM. They are particularly useful when you need to guarantee that a specific policy cannot be accidentally attached to another entity.

An explicit deny in any applicable policy, such as a service control policy (SCP) attached to an organizational unit or a permissions boundary on the IAM principal, overrides any allow in the user's own IAM policy. During policy evaluation, AWS determines the final decision by first considering all applicable policies and applying the rule that an explicit deny takes precedence over any allow. Even if the user's policy grants s3:GetObject, the explicit deny in the SCP or boundary will cause the request to fail with an access denied error. To resolve this, the security engineer must identify and modify the deny statement or remove the restricting boundary.

An instance profile is the container that delivers an IAM role's temporary credentials to EC2 via the instance metadata service. Auto Scaling groups reference the profile in their launch template, so each launched instance automatically assumes the role.

The most common cause of consistently rejected MFA codes is clock drift between the authenticator device and AWS’s TOTP server, so the 30-second time window computed by the device does not match AWS’s window. AWS compares the presented code with codes for the current time step and an allowed clock skew; if the device’s time is off by more than the skew, even a freshly generated code will fail. To fix this, synchronize the device clock (or re-register the MFA device), which is why 'MFA device is not properly synchronized with AWS' correctly describes the failure.

The IAM password policy is the account-level setting designed to enforce password requirements for all IAM users. It lets you require minimum length, uppercase/lowercase letters, numbers, non-alphanumeric characters, password expiration, and prevent password reuse, and users see the requirements during sign-in. Because this policy is applied natively by the IAM service during authentication and password changes, it exactly matches the security policy described.

By creating an IAM role in the target account with read-only permissions to the S3 bucket, the application can use the EC2 instance's existing instance profile role to assume that role via STS AssumeRole. The target account role's trust policy must explicitly allow the EC2 instance role as a principal, and the instance role needs sts:AssumeRole permission. This yields temporary security credentials, avoids storing long-term keys, and adheres to least-privilege cross-account access.

The IAM users in Account A must have an identity-based policy that explicitly grants the sts:AssumeRole action against the role ARN in Account B. Without this allow, the AssumeRole API call is denied even if the trust policy in Account B permits the user, because IAM policies are evaluated by default-deny. The policy should specify the exact role ARN in the Resource element, for example arn:aws:iam::AccountB:role/CrossAccountRole.

The trust policy in the role should list the vendor's AWS account as a principal, allowing that account's users or roles to call sts:AssumeRole. The role's permissions policy then grants only s3:* on 'vendor-bucket' (e.g., arn:aws:s3:::vendor-bucket and arn:aws:s3:::vendor-bucket/*), adhering to least privilege. A bucket policy that explicitly allows the role can be added to make the resource-based authorization unambiguous and to satisfy any governance requirement that the bucket owner also approve access.

The request does not satisfy the condition placed on the Allow, so the policy engine cannot produce an effective Allow for this operation. AWS evaluates IAM condition blocks as part of determining whether a statement applies, and a false condition causes the statement to be skipped entirely. Consequently, the s3:GetObject action is denied by default even though the statement text appears to authorize the action.

The pipeline must call the AWS Security Token Service (STS) AssumeRole API using the pipeline's existing IAM role or a dedicated deployment role, passing the ARN of the target-account role as the RoleArn parameter. STS then returns temporary, automatically expiring credentials (access key, secret key, and session token) that grant exactly the permissions defined in the target role's permissions policy. These temporary credentials can be passed to AWS SDK clients or exported as environment variables so that the deployment commands interact with the target account without human involvement or long-lived secrets.

This is the correct least-privilege policy because s3:ListBucket is the only permission needed to list the objects in a bucket, and it must be applied to the bucket ARN (arn:aws:s3:::my-bucket). Unlike object-level actions such as GetObject, ListBucket is evaluated against the bucket resource itself, so adding an object-path wildcard would make the ARN invalid. This statement grants exactly the ability to list keys and nothing else, such as reading or writing object contents.

The key policy's Allow for kms:Decrypt is explicitly conditioned on kms:ViaService matching the S3 service endpoint, for example s3.us-east-1.amazonaws.com. When the call is made directly to KMS or through any service other than S3, that condition key does not match. Since the condition is false, the Allow is not applied and KMS returns AccessDenied. The decryption therefore fails precisely because the request did not come via Amazon S3.

The Deny statement blocks requests from IPs not in the allowed range.

This is correct because the user successfully authenticated to IAM Identity Center (the portal loaded and they can log in), but the portal only displays AWS accounts to which the user has been explicitly granted access. In IAM Identity Center, administrators must create an account assignment that pairs a principal (user or group) with a permission set for a specific AWS account. If no such assignment exists for this user, the login succeeds but the account list is empty, so the user sees no accounts to choose from.

Service Control Policies (SCPs) are organization policies attached to the AWS Organizations root, an organizational unit, or an individual account, and they apply to every IAM principal—including the root user—within the affected accounts. An explicit Deny in an SCP overrides any Allow generated by identity-based, resource-based, or permissions-boundary policies, but an SCP itself never grants permissions. This makes SCP the correct choice for an account-wide, centrally managed restriction that cannot be bypassed by individual principals.

An explicit Deny statement always overrides any Allow in IAM policy evaluation. The simulate-custom-policy output returning explicitDeny confirms a matching Deny statement exists for ec2:RunInstances, so the request is blocked regardless of any Allow statements present.

This is correct because cross-account role assumption requires two halves: the role's trust policy in the development account must list the production account (or the user ARN) as a trusted principal, and the user in the production account must have an IAM identity policy that explicitly grants sts:AssumeRole against the development role's ARN. Without this identity-side permission, the user is not authorized to call AssumeRole even though the role trusts the account. Attaching the policy to the user therefore completes the authorization chain and allows the user to receive temporary credentials for the development role.

For cross-account S3 access, the IAM role must have an identity-based policy that explicitly allows s3:GetObject on the target bucket. Even if the bucket policy trusts the role, the role's own permissions are evaluated independently; without that allow, the request fails with Access Denied. This is the classic root cause of this scenario.

An explicit deny in the S3 bucket policy takes precedence over any allow granted by the IAM policy attached to the role. When the role attempts to access the bucket, S3 evaluates the bucket policy alongside the IAM policy; if it contains a Deny statement that applies to the role's ARN (or any principal that includes the role), the request fails with AccessDenied. This is the most direct cause here because the role and instance are otherwise correctly configured, isolating the issue to the resource policy.

Cross-account access requires two sides: the target account's role trust policy naming the source account as principal, plus a permissions policy granting the needed actions. The source account must additionally let its users call sts:AssumeRole, otherwise the role cannot be assumed.

Creating a gateway VPC endpoint for DynamoDB gives the Lambda function's subnet a private route to the DynamoDB service, avoiding the public internet and any need for a NAT gateway. The Lambda execution role should carry an identity policy with the specific DynamoDB actions and resource (table ARN) so the function is both network-reachable and authorized to perform the operation. This combines the correct network path with the correct IAM authorization, and the endpoint works through a route-table prefix list rather than an ENI in the function's subnet.

Adding a bucket policy condition with the aws:SourceVpce key set to the specific VPC endpoint ID is the correct approach because this condition is automatically populated when a request reaches S3 through that exact endpoint. This ensures that only requests that travel via the designated VPC endpoint are allowed, effectively bounding access to instances in the associated VPC. It is a recommended, unambiguous way to enforce network-level restrictions on S3 resources and works in tandem with IAM policies that grant permissions.