Google ACE Your company uses Google Workspace for email 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.

• ✗

  Issue each contractor a Gmail account and add it directly to IAM.

  Why it's wrong here

  Gmail accounts are consumer identities owned by the individual, not by your organization, so adding them to IAM gives you no administrative control over security settings. You cannot enforce corporate MFA, password rotation, or session policies, and you cannot centrally disable the account when a contract ends—you must remember to remove each IAM binding. Further, personal Gmail identities cannot be tied to your employee directory or audit trail, creating compliance and separation-of-duties concerns.

• ✓

  Provision contractor accounts using Cloud Identity Free, independent of Google Workspace.

  Why this is correct

  Cloud Identity Free provides a standalone managed identity directory for your domain, so contractors receive Google accounts that your organization fully controls—without paying for Google Workspace licenses or email. From the Admin console you can enforce 2-Step Verification, password length, and session settings, and you can suspend or delete a contractor's account at contract end to instantly revoke access across all Google Cloud projects. These accounts can also be integrated with an external SAML/OIDC identity provider, and because they exist within your organization's Cloud Identity service, they follow your resource hierarchy and org policies.

• ✗

  Create service accounts for each contractor and share the key JSON files.

  Why it's wrong here

  Service accounts are non-human principals meant for server-to-server authentication, not for authenticating individual humans. Handing out the JSON key file gives the contractor a long-lived credential that bypasses MFA, session control, and user-based audit—any actions appear as the service account, not the person. Rotating keys after a contractor leaves is an operational burden, and the shared key is easily leaked or replayed, making this a textbook anti-pattern for human access.

• ✗

  Add contractor email addresses as external users and grant them project-level IAM roles.

  Why it's wrong here

  Adding external contractor email addresses as IAM principals is a federated-by-default approach: the user authenticates with their own provider, and your organization has no ability to enforce MFA, password policies, or session length. While you can grant roles and potentially use IAM conditions to constrain access, you still lack a central directory to manage the accounts, and revoking access when a contractor leaves requires sweeping every project and role binding manually. Because these external identities are not in your Cloud Identity domain, you also cannot force an offboarding workflow or maintain a reliable inventory of all active contractor grants.

Go deeper

Related to this question