Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Exhibit

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello
spec:
  template:
    metadata:
      autoscaling.knative.dev/maxScale: "10"
      autoscaling.knative.dev/minScale: "2"
    spec:
      containerConcurrency: 80
      containers:
      - image: us-docker.pkg.dev/cloudrun/container/hello
        resources:
          limits:
            cpu: "1"
            memory: "256Mi"

Refer to the exhibit. A team deployed this Cloud Run service. During a load test, the service receives high traffic, but the number of container instances never exceeds 10. What is the most likely cause?

⚠ Common exam trap

Google Cloud often tests the distinction between scaling limits (maxScale) and performance tuning parameters (containerConcurrency, CPU limits), leading candidates to mistakenly attribute a hard instance cap to concurrency or resource constraints rather than the explicit annotation.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The maxScale annotation limits the maximum number of instances to 10.

The `maxScale` annotation in Cloud Run directly caps the maximum number of container instances that can be created. When the service receives high traffic but never exceeds 10 instances, it indicates that the `maxScale` annotation is set to 10, preventing further scaling even if demand increases. This is the most direct and likely cause among the options.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
The maxScale annotation limits the maximum number of instances to 10.
Why this is correct
The `autoscaling.knative.dev/maxScale` annotation directly sets the upper bound on the number of instances that Cloud Run can create. With a value of 10, the service is hard-capped at 10 concurrent instances even if traffic surges. This overrides the default maximum (which is usually 100 or unlimited), so it is the correct reason the service cannot scale beyond 10.
✗
The minScale of 2 forces at least two instances, but not the max.
Why it's wrong here
Setting `minScale` to 2 guarantees that Cloud Run keeps at least two instances warm to handle requests, but this is a floor, not a ceiling. It ensures minimum capacity and helps reduce cold starts, yet the autoscaler can still spin up additional instances beyond that minimum. The maximum number of instances is governed solely by `maxScale` (or the default limit), so minScale does not prevent scaling above 10.
✗
The containerConcurrency of 80 limits the number of concurrent requests per instance.
Why it's wrong here
`containerConcurrency` defines the maximum number of requests that a single instance can process simultaneously; here it is capped at 80. This setting helps the autoscaler decide when to create new instances—once an instance reaches 80 concurrent requests, additional requests trigger scaling. However, it does not place any limit on the total number of instances across the service, so the service can still have more than 10 instances.
✗
The CPU limit of 1 vCPU is too low to handle the traffic.
Why it's wrong here
A CPU limit of 1 vCPU allocates that amount of processing power to each instance, not to the entire service. While a low CPU per instance could affect how much traffic a single instance can handle, Cloud Run compensates by horizontally scaling—adding more instances up to the `maxScale` limit. Therefore, the CPU limit is not inherently 'too low' to handle the traffic because the service can still scale out to meet demand.

Go deeper

Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question