SCS-C02 Identity and Access Management Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Avoid using IAM roles and instead attach policies directly to users.

  Why it's wrong here

  Attaching policies directly to IAM users creates long-lived static credentials, such as an access key ID and secret, that typically end up embedded in code or configuration files. If those keys are leaked, the attached permissions are exposed until an admin detects and rotates them. IAM roles avoid this by leveraging AWS STS to issue temporary credentials, allowing the application to assume a role via an instance profile or a trust policy without storing permanent keys, and roles can also be scoped with permissions boundaries for cross-account access.

• ✗

  Use the root user for everyday administrative tasks.

  Why it's wrong here

  The AWS root user has unrestricted access to every resource and account setting, and no IAM policy can reduce those permissions, so using it for routine admin work completely defeats least privilege and separation of duties. Everyday actions like launching EC2 instances or managing IAM should be done through an IAM user or role with only the required policies and MFA enforced. The root user should be used only for account-level operations that no other identity can perform, such as closing the account, changing the AWS Support plan, or updating account contact details, and should always be protected with a strong password plus MFA.

• ✗

  Grant broad permissions to all users to simplify management.

  Why it's wrong here

  Granting broad permissions, for example using 'Action:*' on 'Resource:*', directly violates the least-privilege principle because any compromised credential or misused identity inherits access to every action on every resource. It also inflates the blast radius of a security incident and makes audits difficult to pass because policies no longer reflect the actual operational needs of the workload. The correct practice is to start with AWS managed policies, then use IAM Access Analyzer and CloudTrail logs to develop custom policies that grant only the actions the principal genuinely performs.

• ✓

  Use conditions in IAM policies to restrict access based on tags or IP addresses.

  Why this is correct

  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.

• ✓

  Use IAM roles for applications that run on EC2 instances.

  Why this is correct

  Using an IAM role for an EC2 application is a best practice because the instance automatically obtains temporary, rotated credentials through the instance metadata service, eliminating the need to embed access keys in the AMI, user-data, or source code. The role is attached to the instance profile, EC2 assumes the role, and the SDK retrieves credentials that soon expire and are automatically refreshed. This limits the exposure of any single credential and also simplifies key management, since the role's permissions can be adjusted later without redeploying or reconfiguring the instances.

Go deeper

Related to this question