DOP-C02 Security and Compliance 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.

• ✗

  Generate and share access keys for all users.

  Why it's wrong here

  Sharing access keys obliterates individual accountability because every API action is logged in CloudTrail under a single identity, making audit trails useless for determining who actually performed a change. Furthermore, rotating a shared key disrupts all users simultaneously, and long-lived static credentials remain valid for an extended period, dramatically widening the blast radius if the key is accidentally exposed in code or a secret dump. Each principal must receive unique, individually rotated access keys or, better, temporary credentials via roles.

• ✗

  Store IAM user passwords in a shared document.

  Why it's wrong here

  Storing IAM user passwords in a shared document exposes plaintext secrets in a location that typically lacks fine-grained access controls, encryption at rest, or audit logging. Anyone with read access to the document can log in as any user, and there is no per-user access boundary or way to revoke access for one individual without changing all passwords. This violates the principle of least privilege and is far less secure than a dedicated secret manager with restricted IAM access, versioned secrets, and automatic rotation.

• ✓

  Enable multi-factor authentication (MFA) for privileged users.

  Why this is correct

  Enabling MFA for privileged users requires a second authentication factor, so a stolen or phished password alone cannot produce a console login or an authenticated API call. This control directly blocks account takeover from reused passwords, keylogging, or credential stuffing, because the attacker must also possess the virtual or hardware token. AWS recommends enforcing MFA with an IAM policy that explicitly denies actions unless aws:MultiFactorAuthPresent is true, which makes MFA mandatory rather than optional.

• ✗

  Use the root user for daily administrative tasks.

  Why it's wrong here

  The root user has unrestricted administrative power on the account and cannot be constrained by IAM policies, unlike an IAM principal. If root credentials are compromised, an attacker can permanently delete the account, change billing data, or create a new privileged user, and the root password cannot be rotated via IAM processes or replaced with a role. Daily administrative work should be done through least-privilege IAM roles, while the root account is used only for a few unavoidable tasks and protected with MFA and a strong password.

• ✓

  Use IAM roles for applications that require AWS access.

  Why this is correct

  IAM roles issue temporary AWS STS credentials that expire after a set duration and are scoped by the role's trust policy and permission policy, removing the need to embed long-lived static access keys in applications. EC2 instances, ECS tasks, and Lambda functions can assume roles automatically through instance profiles or service-provided credentials, so no secret is ever stored locally. The temporary credentials can be revoked instantly by removing the role or rejecting the trust policy, and they cannot be exfiltrated and reused indefinitely, fundamentally reducing the risk of long-term credential compromise.

Go deeper

Related to this question