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.

• ✓

  Delete the root user access keys.

  Why this is correct

  Root user access keys are permanent long-term credentials with unrestricted privileges across the account, including billing and even account closure. They cannot be constrained by IAM policies or permission boundaries, so if they are compromised, the attacker gains full control without any possibility of mitigating the scope. AWS best practice is to never create root access keys, and if they already exist, delete them immediately and rely on password plus MFA for the rare root sign-in.

• ✗

  Use the root user for daily administrative tasks.

  Why it's wrong here

  The root user has unconditional administrative authority over the account and is not subject to IAM policies, permission boundaries, or service control policies when used in a management account. Performing daily administration with the root user bypasses every audit and least-privilege control, making it nearly impossible to attribute actions to a specific engineer. Instead, create IAM roles with granular permissions and use them for routine management, reserving root for a limited set of account-level operations.

• ✗

  Set a password policy that locks the root user after 10 failed attempts.

  Why it's wrong here

  AWS does not apply account lockout policies to the root user; IAM password policies are only enforced for IAM users, not the account root user. The root authentication path relies on the email and password along with MFA, and any lockout attempt would actually create a denial-of-service risk for account recovery. The correct protections are a strong password and mandatory MFA, while a lockout policy is non-functional for the root account.

• ✗

  Share the root user password with senior developers for emergencies.

  Why it's wrong here

  Sharing the root password eliminates non-repudiation and traceability because any engineer with the password and MFA could execute irrecoverable actions, which are then indistinguishable from another user. Shared credentials also expand the attack surface and contradict the principle of least privilege; a compromised password leads to full account take-away. For emergencies, the right pattern is a break-glass IAM role with multi-factor authentication, not the uncontrolled root account.

• ✓

  Enable multi-factor authentication (MFA) for the root user.

  Why this is correct

  Enabling MFA on the root account adds a second authentication factor that must be present in addition to the password, blocking most credential-stuffing and phishing attacks. Because the root account can perform account-closing and billing changes, MFA is a mandatory line of defense, and several critical AWS actions can be configured to require MFA only through this device. Combined with deleting access keys, MFA becomes the primary protection during rare root-user sign-ins.

Go deeper

Related to this question