A security engineer is reviewing the IAM policy of a Cloud Storage bucket that contains sensitive data. The exhibit shows the current policy. A developer reports that they can read objects in the bucket using service account sa-2, but they cannot delete objects. What is the most likely reason?
objectAdmin includes delete, so the issue is likely an additional constraint.
Why this answer
The IAM policy shows that service account sa-2 has the roles/storage.objectAdmin role, which includes the storage.objects.delete permission. However, the presence of a condition or an organization policy (such as a VPC Service Controls perimeter or a boolean constraint) can override this permission, preventing deletion even though the role is assigned. The developer can read objects (permitted by the role) but cannot delete them, indicating that a higher-level policy is blocking the delete action.
Exam trap
Google Cloud often tests the misconception that a role with delete permissions always allows deletion, ignoring that IAM conditions or organization policies can override the permission, leading candidates to incorrectly choose a role mismatch or ACL override.
How to eliminate wrong answers
Option A is wrong because there is no explicit deny statement in the IAM policy for sa-2; explicit denies are rare and would appear as a separate 'Deny' rule, not as a missing permission. Option C is wrong because uniform bucket-level access being disabled would allow ACLs to coexist with IAM, but ACLs cannot override IAM permissions for the same principal; if sa-2 has the objectAdmin role via IAM, ACLs cannot restrict that permission unless they explicitly deny (which is not shown). Option D is wrong because the exhibit clearly shows the role is roles/storage.objectAdmin, not objectViewer; the developer can read objects, which is consistent with objectAdmin, but the inability to delete points to a condition or org policy, not a role mismatch.