DVA-C02 Security 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.

• ✗

  Attach the AdministratorAccess managed policy to an IAM user.

  Why it's wrong here

  Attaching the AdministratorAccess managed policy to an IAM user grants full administrative permissions across all AWS services, including the ability to modify, delete, or create resources — far beyond the read-only access a third-party auditor requires. This violates least privilege and exposes the account to unnecessary risk if the user's long-term credentials are compromised. Additionally, creating an IAM user for an external party requires distributing and managing static credentials, which is less secure than using temporary credentials via role assumption.

• ✓

  Create an IAM role with the SecurityAudit managed policy and allow the auditor to assume it.

  Why this is correct

  Creating an IAM role with the SecurityAudit managed policy and allowing the auditor to assume it is the correct approach because SecurityAudit grants only read-only access to security-related services and many other AWS services, aligning with the auditor's need to review configurations and logs without making changes. The role uses temporary credentials through AWS STS, so no long-term keys are issued or shared, and access can be scoped with a trust policy that specifies the auditor's AWS account or external identity provider. This follows least privilege and provides a secure, auditable mechanism for third-party access.

• ✗

  Create an IAM user with a custom policy that allows all actions.

  Why it's wrong here

  Creating an IAM user with a custom policy that allows all actions is severely overprivileged because it permits not only read operations but also write, modification, and deletion operations across all services, which is not read-only access. Unlike a managed policy like SecurityAudit, this custom policy is more permissive than needed and does not adhere to least privilege. Furthermore, managing a third-party IAM user requires creating and distributing long-term credentials, increasing the risk of credential leakage and making it harder to revoke access promptly than with a role that can be assumed temporarily.

• ✗

  Share the root account credentials with the auditor.

  Why it's wrong here

  Sharing the AWS account root user credentials with a third-party auditor is a critical security violation that compromises the entire account, as the root user has unrestricted access to all resources, including billing, account settings, and the ability to change support plans or close the account. Root credentials should never be shared because there is no way to scope permissions, apply MFA per user, or revoke access selectively without rotating the root password and all associated keys. This practice eliminates accountability and auditability, making it impossible to track what the auditor did or to limit their actions to read-only.

Go deeper

Related to this question