Cloud Run service concept in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Cloud Run Service Scaling Behavior

What happens when a Cloud Run service receives a sudden spike of 1000 requests at the same time?

A Cloud Run rejects all requests exceeding the first instance's capacity without scaling.

B Cloud Run queues all requests and processes them one by one on a single instance.

C Cloud Run automatically creates multiple instances to handle the requests concurrently, scaling up quickly.

D Cloud Run requires manual intervention to add more instances to handle the load.

💡 Hint

Think about how serverless platforms handle sudden traffic.

Cloud Run automatically scales the number of instances based on incoming requests, allowing it to handle sudden spikes without manual intervention.

❓ Architecture

intermediate

Cloud Run Service and Traffic Splitting

You want to deploy a new version of your Cloud Run service and gradually send 20% of traffic to it while keeping 80% on the current version. How can you achieve this?

A Deploy the new version to a separate Cloud Run service and manually route 20% of requests via DNS.

B Use Cloud Run's traffic splitting feature to assign 20% traffic to the new revision and 80% to the old revision.

C Update the existing service to the new version and rely on Cloud Run to automatically split traffic.

D Create a load balancer in front of Cloud Run and configure it to split traffic by percentage.

💡 Hint

Cloud Run supports gradual rollouts using built-in features.

Cloud Run allows you to split traffic between revisions of the same service by percentage, enabling gradual rollouts without extra infrastructure.

❓ security

advanced

Cloud Run Service Authentication Configuration

You want to restrict access to your Cloud Run service so only authenticated users from your Google Workspace domain can invoke it. Which configuration achieves this?

A Set the Cloud Run service to allow only authenticated invocations and configure IAM to grant the 'Cloud Run Invoker' role to your Google Workspace domain users.

B Make the Cloud Run service public and rely on application-level authentication inside the container.

C Disable authentication on Cloud Run and use a firewall to block unwanted IP addresses.

D Use a VPN to restrict network access to the Cloud Run service.

💡 Hint

Think about how Cloud Run integrates with IAM and Google identities.

Cloud Run supports IAM-based authentication. Granting the 'Cloud Run Invoker' role to your domain users and requiring authentication restricts access properly.

❓ service_behavior

advanced

Cloud Run Service Concurrency Setting Impact

If you set the concurrency of a Cloud Run service to 1, what is the effect on instance scaling and request handling?

A Each instance handles only one request at a time, so Cloud Run may create more instances under load to handle concurrent requests.

B Each instance can handle multiple requests simultaneously, reducing the number of instances needed.

C Cloud Run queues requests internally and processes them sequentially on a single instance regardless of concurrency setting.

D Setting concurrency to 1 disables autoscaling and limits the service to one instance.

💡 Hint

Consider how concurrency affects instance utilization and scaling.

Concurrency set to 1 means each instance processes one request at a time, so Cloud Run scales out more instances to handle multiple requests concurrently.

✅ Best Practice

expert

Optimizing Cloud Run Service Startup Time

Your Cloud Run service experiences high latency on the first request after a period of inactivity. Which approach best reduces this cold start delay?

A Use a scheduled Cloud Function to send requests periodically to keep the service active.

B Increase the CPU and memory allocation to the service to speed up startup.

C Deploy the service to multiple regions to distribute the load.

D Use Cloud Run's minimum instance setting to keep a small number of instances always warm and ready.

💡 Hint

Think about how to keep instances ready without manual pings.

Setting minimum instances keeps some instances running even when idle, reducing cold start latency without extra maintenance.

Practice

1. What is the main benefit of using Cloud Run for your applications?

easy

A. You must manually scale your application.

B. You don't need to manage servers or infrastructure.

C. It only runs applications written in Python.

D. You need to configure virtual machines yourself.

Solution

1. Step 1: Understand Cloud Run's server management

   Cloud Run automatically manages the servers, so you don't have to.

2. Step 2: Compare other options

   Manual scaling and VM configuration are not needed with Cloud Run.

3. Final Answer:

   You don't need to manage servers or infrastructure. -> Option B

4. Quick Check:

   Serverless = No server management [OK]

Hint: Cloud Run means no server setup needed [OK]

Common Mistakes:

• Thinking you must manage servers manually
• Believing Cloud Run only supports one language
• Confusing Cloud Run with VM services

2. Which gcloud command correctly deploys a container image to Cloud Run?

easy

A. gcloud run deploy --image gcr.io/my-project/my-image

B. gcloud compute instances create --image gcr.io/my-project/my-image

C. gcloud app deploy --image gcr.io/my-project/my-image

D. gcloud container clusters create --image gcr.io/my-project/my-image

Solution

1. Step 1: Identify the correct service for deploying containers

   Cloud Run uses gcloud run deploy to deploy container images.

2. Step 2: Eliminate other commands

   compute instances is for VMs, app deploy is for App Engine, and container clusters create is for Kubernetes clusters.

3. Final Answer:

   gcloud run deploy --image gcr.io/my-project/my-image -> Option A

4. Quick Check:

   Cloud Run deploy = gcloud run deploy [OK]

Hint: Use 'gcloud run deploy' for Cloud Run containers [OK]

Common Mistakes:

• Using compute or app commands instead of run
• Confusing Kubernetes cluster commands with Cloud Run
• Missing the --image flag

3. Given this Cloud Run service configuration snippet, what happens when traffic increases?

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-service
spec:
  template:
    spec:
      containers:
      - image: gcr.io/my-project/hello-image
        resources:
          limits:
            cpu: 1
            memory: 512Mi

medium

A. Cloud Run automatically creates more instances to handle the traffic.

B. The service crashes because CPU is limited to 1.

C. You must manually add more instances in the config.

D. Traffic is rejected when CPU limit is reached.

Solution

1. Step 1: Understand Cloud Run scaling behavior

   Cloud Run automatically scales container instances based on incoming traffic.

2. Step 2: Analyze resource limits

   CPU and memory limits set max per instance but do not prevent scaling.

3. Final Answer:

   Cloud Run automatically creates more instances to handle the traffic. -> Option A

4. Quick Check:

   Auto scaling = more instances on traffic rise [OK]

Hint: Cloud Run scales instances automatically with traffic [OK]

Common Mistakes:

• Thinking CPU limit stops scaling
• Believing manual scaling is required
• Assuming traffic is rejected on resource limits

4. You deployed a Cloud Run service but get an error: Container failed to start. What is a likely cause?

medium

A. The container image is too large to deploy.

B. You forgot to set the CPU limit in the deployment.

C. The container image does not have a listening port configured.

D. Cloud Run requires a VM instance to be created first.

Solution

1. Step 1: Check container requirements for Cloud Run

   Cloud Run requires the container to listen on a port for incoming requests.

2. Step 2: Evaluate other options

   CPU limits are optional, Cloud Run is serverless (no VM setup), and image size usually causes warnings, not start failure.

3. Final Answer:

   The container image does not have a listening port configured. -> Option C

4. Quick Check:

   Listening port missing = start failure [OK]

Hint: Containers must listen on a port for Cloud Run [OK]

Common Mistakes:

• Assuming VM setup is needed
• Blaming CPU limits for start failure
• Thinking image size causes start errors

5. You want to deploy a Cloud Run service that scales down to zero when idle but also supports up to 10 concurrent requests per instance. Which configuration is correct?

hard

A. Set --concurrency=1 and --min-instances=10 to scale down to zero.

B. Set --min-instances=1 and --concurrency=10 to scale to zero.

C. Set --max-instances=10 and --concurrency=1 to allow 10 concurrent requests.

D. Set --concurrency=10 and deploy normally; Cloud Run scales to zero automatically.

Solution

1. Step 1: Understand concurrency and scaling in Cloud Run

   Concurrency controls how many requests one instance handles; setting it to 10 allows 10 requests per instance.

2. Step 2: Understand scaling to zero behavior

   Cloud Run automatically scales down to zero when idle unless --min-instances is set above zero.

3. Final Answer:

   Set --concurrency=10 and deploy normally; Cloud Run scales to zero automatically. -> Option D

4. Quick Check:

   Concurrency 10 + no min-instances = scale to zero [OK]

Hint: No min-instances means auto scale to zero [OK]

Common Mistakes:

• Setting min-instances prevents scaling to zero
• Confusing max-instances with concurrency
• Assuming concurrency 1 means 10 requests