A company has a Cloud Run service that processes images uploaded by users. The service reads the images from a Cloud Storage bucket and writes processed images to another bucket. The team recently updated the service to use a custom service account named 'image-processor-sa' with minimal permissions. After the update, the service fails with permission errors when trying to read from the source bucket. The team verified that the service account has the Storage Object Viewer role on the source bucket and Storage Object Creator role on the destination bucket. What should the architect do to resolve the issue?
Cloud Run defaults to the Compute Engine default service account unless explicitly overridden, so the new permissions were never applied. Redeploying with the --service-account flag binds the revision to image-processor-sa, letting its Storage Object Viewer role take effect.
Why this answer
The error occurs because the Cloud Run service is not using the custom service account 'image-processor-sa' despite it being created and granted permissions. By default, Cloud Run uses the Compute Engine default service account unless explicitly overridden. Redeploying with the --service-account flag attaches the correct identity to the Cloud Run revision, allowing it to authenticate with Cloud Storage using the minimal permissions already assigned.
Exam trap
Google Cloud often tests the distinction between granting permissions to a service account versus actually attaching that service account to a resource; candidates mistakenly assume that creating and granting roles to a service account automatically makes it the active identity of the Cloud Run service.
How to eliminate wrong answers
Option B is wrong because the Cloud Run Invoker role grants permission to invoke the service (i.e., call its HTTP endpoint), not to read from Cloud Storage; it does not resolve the missing identity binding. Option C is wrong because assigning Storage Admin is an overly permissive solution that violates the principle of least privilege; the service account already has the necessary Object Viewer and Object Creator roles, so the issue is not about missing permissions but about the service not using the correct account. Option D is wrong because the Cloud Storage API is enabled by default when Cloud Storage is used; the error is not due to a disabled API but due to the service running under the wrong identity.