A Cloud Engineer needs to deploy a custom microservice from local source code to Google Cloud Run and secure it so that only a specific client service account can invoke it. Arrange the steps in the correct sequential order from initial image creation to post-deployment verification.
- 1Build the container image from local source code and push it to Artifact Registry using `gcloud builds submit`.
- 2Deploy the container image to Cloud Run using `gcloud run deploy` with `--no-allow-unauthenticated`.
- 3Grant the client service account access by running `gcloud run services add-iam-policy-binding` with `--role=roles/run.invoker`.
- 4Test access to the service URL by passing an HTTP Authorization bearer header containing a token generated via `gcloud auth print-identity-token`.
Answer
The correct sequence is: 1. Build and push the container image to Artifact Registry using gcloud builds submit. 2. Deploy the container image to Cloud Run with unauthenticated access disabled. 3. Bind the Cloud Run Invoker role (roles/run.invoker) to the client service account. 4. Verify access by invoking the service endpoint with an identity token.
Deployment workflow follows a strict chronological order: First, the container image must be built from source code and pushed to Artifact Registry so that Cloud Run can access the container bits. Second, the Cloud Run service is created from this container image with unauthenticated invocations disabled. Third, once the service resource exists, an IAM policy binding is attached to grant the specific client service account the `roles/run.invoker` role. Fourth, the deployment is validated by sending an authenticated request using an identity token.
Step-by-Step Solution
Key Concept
Deploying containerized microservices to Cloud Run and managing service-level IAM authentication and invoker roles.