Sample questions
Aws Iam SecurityDifficulty 1
Which policy on an IAM role determines who is allowed to assume that role?
- aThe role's permissions boundary
- bAny identity policy attached to the caller, by itself
- cThe role's trust policy✓
- dThe account password policy
Explanation:A role's trust policy is the resource-based policy that names the principals or services allowed to call an STS role-assumption operation for that role. The role's identity policies define what an assumed session may do after assumption; a permissions boundary caps permissions but does not establish trust.
Aws Iam SecurityDifficulty 1
Which elements define what an identity-based IAM policy statement allows or denies?
- aRegion, account alias, service endpoint, and credential profile
- bUser, Group, Role, Policy
- cEffect, Action, Resource, and optional Condition✓
- dEncrypt, Decrypt, Sign, Verify
Explanation:An identity-based policy statement uses Effect, Action, and Resource, with an optional Condition. Principal is not used because the attached identity is already the principal; Principal is used in resource-based policies and role trust policies.
Aws Iam SecurityDifficulty 2
What is the recommended way to grant the same set of IAM permissions to 30 developers who need identical access?
- aUse federation through IAM Identity Center and assign the developers a shared permission set for the account✓
- bCopy the same inline policy into each of the 30 individual IAM users
- cShare one IAM user's access keys among all 30 developers
- dAttach the policy directly to the AWS account root user and have every developer log in as that same root account
Explanation:AWS recommends that human users access AWS through federation with temporary credentials; IAM Identity Center provides centralized account access and reusable permission sets for this purpose. Copying inline policies to 30 IAM users is difficult to maintain, sharing credentials destroys individual auditability, and daily root use is unsafe.
Aws Iam SecurityDifficulty 1
Which of these is the single most important security step for the AWS account's root user?
- aRotating the root user's password every 24 hours
- bCreating long-lived access keys for the root user so automation can use it
- cAttaching an
AdministratorAccess managed policy directly to the root user - dEnable MFA and avoid using the root user for daily work✓
Explanation:AWS's guidance is to enable MFA on the root user, avoid creating root access keys, and use root only for the few account-level tasks that require it. Human users should normally access AWS through federation, preferably centralized with IAM Identity Center, and receive temporary role credentials with least-privilege permissions. Root already has full account access, so attaching AdministratorAccess is redundant and creating root access keys adds unnecessary risk.
Aws Iam SecurityDifficulty 2
How is an IAM role attached to an EC2 instance so that applications can obtain its temporary credentials from the instance metadata service?
- aThrough an instance profile that contains the IAM role✓
- bBy placing the role ARN in the instance's user-data script only
- cBy attaching the role's trust policy directly to the network interface
- dBy converting the role into an IAM user after the instance starts
Explanation:EC2 associates a role with an instance through an instance profile. The EC2 metadata service can then provide temporary credentials for that role to SDKs on the instance. User data and network interfaces do not create this IAM association, and roles are not converted into users.
Aws Iam SecurityDifficulty 1
By default, when an IAM user has no policies attached at all, what happens when they try to call any AWS API?
- aIt is denied unless a policy explicitly allows it✓
- bThe request succeeds with read-only access by default
- cThe request succeeds because IAM defaults to allowing all actions until a Deny is added
- dThe request is routed to the account root user's permissions automatically
Explanation:IAM's foundational rule is default-deny: unless a policy explicitly allows an action, it is denied. There is no implicit read-only or full-access default (b, c are wrong), and permissions are never silently inherited from the root user (d is wrong) — every principal's access is defined by its own attached/inline policies.