IAM Policy practice questions

The management account must have an AWS Organizations SCP that allows CloudFormation StackSets operations.

Why wrong: SCPs are not required for StackSets; the necessary permissions are handled by IAM.

Each member account must have a self-managed IAM role named 'AWSCloudFormationStackSetExecutionRole' with a trust policy allowing the management account to assume it.

Why wrong: Self-managed roles are not required; StackSets can use service-managed permissions with automatic role creation.

The S3 bucket has a lifecycle policy that deletes logs after a short period.

Why wrong: Lifecycle policies do not affect access permissions.

The S3 bucket has a bucket policy that requires the analyst to assume a role in the logging account.

Why wrong: The analyst already has read-only access; assuming a role may not be necessary.

The S3 bucket is encrypted with an AWS KMS key, and the analyst does not have permissions to decrypt.

Why wrong: The question does not mention encryption; this is not the most likely cause.

Use an SCP to enforce a specific password policy and require MFA across all accounts.

Why wrong: SCPs cannot enforce a password policy or require MFA; they only deny or allow actions.

Use AWS Config rules to automatically set the password policy and enable MFA for all users.

Why wrong: AWS Config rules can detect but not remediate automatically unless combined with custom automation.

Use AWS CloudTrail to monitor password policy changes and MFA status, and trigger an automatic remediation.

Why wrong: CloudTrail logs but does not enforce or remediate.

The condition uses 'BoolIfExists' instead of 'Bool' which causes the policy to fail when the key is present.

Why wrong: BoolIfExists works correctly; it returns true if the key exists and is true.

The role requires MFA, but the user's MFA device is not configured correctly.

Why wrong: The question states MFA is enabled and token is passed.

The principal is set to the root account, which does not allow IAM users to assume the role.

Why wrong: The root account principal allows any IAM user from that account.

An SCP that allows only read-only billing actions.

Why wrong: SCPs cannot allow actions; they only deny or allow by default.

An SCP that denies all billing-related actions except read-only.

Why wrong: This would deny read access as well.

An IAM policy attached to the root OU that denies billing modifications.

Why wrong: IAM policies cannot be attached to OUs; they are attached to users/groups/roles.

Use AWS Service Catalog to provide a password policy product and require account owners to launch it.

Why wrong: Not automatic.

Use an SCP to deny the iam:CreateUser action unless the request includes a condition that the password policy meets the requirement.

Why wrong: SCPs cannot check password policy content.

Use AWS Config rules to detect accounts without the required password policy and auto-remediate with a Lambda function.

Why wrong: Reactive, not preventive.

The Lambda function does not have permission to create log groups.

Why wrong: Log permissions are granted, and missing log permissions would cause a different error.

The Lambda function is not in the same VPC as DynamoDB.

Why wrong: DynamoDB is accessible over the internet; VPC is not required.

The DynamoDB table 'Orders' does not exist.

Why wrong: The error is AccessDenied, not ResourceNotFoundException.

{"Effect": "Allow", "Action": ["s3:*"], "Resource": "arn:aws:s3:::my-bucket/*"}

Why wrong: Grants full S3 access, violating least privilege.

{"Effect": "Allow", "Action": ["logs:PutLogEvents"], "Resource": "*"}

Why wrong: Resource wildcard is too permissive.

{"Effect":"Allow","Action":["ecr:PutImage"],"Resource":"*"}

Why wrong: PutImage is for ECR, not ECS service update.

{"Effect":"Allow","Action":["ecs:RunTask"],"Resource":"*"}

Why wrong: RunTask starts a task, not updates a service.

{"Effect":"Allow","Action":["ecs:RegisterTaskDefinition"],"Resource":"*"}

Why wrong: RegisterTaskDefinition is for registering task definitions, not updating services.

The user cannot describe instances or terminate instances.

Why wrong: Describe is allowed by the first statement.

The user can terminate instances and describe instances.

Why wrong: Deny overrides Allow for termination.

The user can describe instances but cannot terminate any instances.

Why wrong: The user can describe, but the Deny prevents termination.

The policy does not grant permission to call ec2:DescribeSnapshots, which is required before creating a snapshot.

Why wrong: DescribeSnapshots is not a prerequisite for CreateSnapshot.

The policy lacks a condition key to restrict the snapshot creation to specific volumes.

Why wrong: Condition keys are optional; the issue is missing resource permissions for the volume.

The policy does not include ec2:CreateTags for the volume, only for snapshots.

Why wrong: The script tags the snapshot, not the volume; the policy allows CreateTags on snapshots.

Use AWS Config rules to remediate non-compliant objects

Why wrong: Remediation is reactive, not preventive.

Require users to use pre-signed URLs for uploads

Why wrong: Pre-signed URLs do not enforce encryption.

Attach an SCP that denies s3:PutObject without encryption

Why wrong: SCPs are account-level, not bucket-level.

Use AWS Config rules to detect users without MFA and send alerts.

Why wrong: Config rules are detective, not preventive.

Enable AWS CloudTrail to log console access without MFA.

Why wrong: CloudTrail only logs, does not enforce.

Use AWS Single Sign-On (SSO) with MFA enabled for all users.

Why wrong: AWS SSO applies to federated users, not IAM users.

Create an IAM policy that requires tags on all resources and attach it to all IAM users.

Why wrong: IAM policies cannot enforce tags on resources created by CloudFormation unless using condition keys that may not be supported.

Configure CloudFormation to reject any stack that does not include tags.

Why wrong: CloudFormation does not have a built-in mechanism to reject stacks based on tags.

Use AWS Config to detect resources without tags and automatically remediate using Systems Manager Automation.

Why wrong: AWS Config detects non-compliance after creation; it does not prevent creation of untagged resources.

Use a VPC endpoint and route logs through a central VPC.

Why wrong: CloudTrail logging does not require VPC endpoints.

Attach an SCP to allow CloudTrail to write to the central bucket.

Why wrong: SCPs cannot grant permissions; they only deny or allow actions.

Create an IAM role in each member account and allow the central account to assume it.

Why wrong: CloudTrail does not use IAM roles to deliver logs; it uses resource-based policies.

Enable AWS CloudTrail and set up a metric filter for CreateAccessKey

Why wrong: Only logs, does not prevent.

Apply an IAM policy to all users in each account that denies iam:CreateAccessKey

Why wrong: Not centrally managed.

Use AWS Config to detect access key creation and trigger a Lambda to delete the key

Why wrong: Reactive, not preventive.

Access is allowed because the Principal is "*".

Why wrong: The Principal is "*", but the Condition restricts by IP.

Access is denied because the bucket is not public.

Why wrong: The bucket policy allows access, but only from specific IPs.

Access is allowed because the policy does not explicitly deny.

Why wrong: Deny is not required; the Allow only applies to the IP range.

Use AWS Config rules to detect and remediate any changes to CloudTrail configurations.

Why wrong: Config rules are reactive, not preventive.

Create an IAM policy that denies cloudtrail:StopLogging and cloudtrail:DeleteTrail for all IAM users.

Why wrong: IAM policies do not prevent actions by the root user or users in other accounts.

Apply a resource-based policy to the CloudTrail trail that denies these actions.

Why wrong: CloudTrail trails do not support resource-based policies.

Enable AWS CloudTrail Insights to detect unusual activity.

Why wrong: Insights detects but does not prevent deletion.

Use IAM roles with a permissions boundary that restricts CloudTrail actions.

Why wrong: Permissions boundaries only affect IAM roles, not all principals.

Enable AWS CloudTrail to log role assumptions and send alerts when external assumptions occur.

Why wrong: CloudTrail logs but does not prevent external assumptions.

Use AWS Config to detect roles with external trust relationships and automatically delete them.

Why wrong: AWS Config can detect but not automatically delete roles; also, this is reactive, not preventive.

Modify the trust policy of each IAM role to allow only principals from the organization.

Why wrong: This requires modifying each role individually and is not scalable.