Deploying workloads in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding GKE Pod Scheduling Behavior

You deploy a Kubernetes Pod on Google Kubernetes Engine (GKE) with a node selector that matches no nodes. What will happen to the Pod?

GCP

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: nginx
    image: nginx
  nodeSelector:
    disktype: ssd

A The Pod will remain in Pending state indefinitely because no nodes match the selector.

B The Pod will be scheduled on any available node ignoring the nodeSelector.

C The Pod will be deleted automatically by GKE after 5 minutes.

D The Pod will start running on the master node.

💡 Hint

Think about how Kubernetes schedules Pods with node selectors.

If no nodes match the nodeSelector, the Pod cannot be scheduled and stays Pending until a matching node appears.

❓ Architecture

intermediate

Choosing the Right Compute Service for a Stateless Web App

You want to deploy a stateless web application that must scale automatically based on HTTP traffic. Which Google Cloud service is the best choice?

A Google App Engine Standard Environment with automatic scaling.

B Google Compute Engine with manual instance group scaling.

C Google Kubernetes Engine with a single node cluster.

D Cloud Functions triggered by HTTP requests.

💡 Hint

Consider which service offers automatic scaling for web apps without managing infrastructure.

App Engine Standard Environment automatically scales stateless web apps based on traffic without user management of servers.

❓ security

advanced

Securing Workloads with Service Accounts

You deploy a workload on Google Cloud Run that needs to access a Cloud Storage bucket securely. What is the best practice to grant access?

A Use a user’s personal credentials to access the bucket from the Cloud Run service.

B Assign the Cloud Run service's default service account the Storage Object Viewer role on the bucket.

C Embed the Cloud Storage credentials as environment variables in the Cloud Run service.

D Make the Cloud Storage bucket public so Cloud Run can access it without credentials.

💡 Hint

Think about the principle of least privilege and secure identity management.

Assigning the service account the minimal required role is secure and avoids embedding credentials.

❓ Configuration

advanced

Configuring Autoscaling for a GKE Deployment

You want to configure Horizontal Pod Autoscaling (HPA) for a GKE Deployment based on CPU usage. Which YAML snippet correctly defines the HPA?

A

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: webapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: cpu
      target:
        type: AverageValue
        averageValue: 50m

B

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

C

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: webapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapp
  minReplicas: 2
  maxReplicas: 10
  targetMemoryUtilizationPercentage: 50

D

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: webapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapp
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

💡 Hint

Look for the correct apiVersion and field names for CPU-based autoscaling.

autoscaling/v1 with targetCPUUtilizationPercentage is the standard way to configure CPU autoscaling in GKE.

✅ Best Practice

expert

Designing a Multi-Region Deployment for High Availability

You need to deploy a web application on Google Cloud to achieve high availability across multiple regions. Which architecture follows best practices?

A Deploy the application in multiple zones within a single region and rely on client-side retries for failover.

B Deploy the application in multiple regions with independent databases and use DNS round-robin to distribute traffic.

C Deploy the application in multiple regions with a global HTTP(S) Load Balancer and a multi-region managed database with replication.

D Deploy the application in a single region with multiple zones and use a global HTTP(S) Load Balancer with Cloud CDN.

💡 Hint

Consider global load balancing and data consistency across regions.

Using a global load balancer with multi-region database replication ensures availability and data consistency.

Practice

1. What does deploying a workload on Google Cloud Run primarily do?

easy

A. Stores your application code without running it

B. Creates a virtual machine that you must manage manually

C. Runs your application in a managed environment that scales automatically

D. Only backs up your application data

Solution

1. Step 1: Understand Cloud Run's purpose

   Cloud Run runs your app in a managed environment that automatically scales based on traffic.

2. Step 2: Compare options

   Options B, C, and D describe other services or actions, not workload deployment on Cloud Run.

3. Final Answer:

   Runs your application in a managed environment that scales automatically -> Option C

4. Quick Check:

   Cloud Run = managed auto-scaling app hosting [OK]

Hint: Cloud Run runs and scales apps automatically [OK]

Common Mistakes:

• Confusing Cloud Run with virtual machines
• Thinking Cloud Run only stores code
• Assuming manual scaling is needed

2. Which of the following is the correct gcloud command to deploy a container image to Cloud Run in region us-central1 with service name my-service?

easy

A. gcloud run deploy my-service --image=gcr.io/my-project/my-image --region=us-central1

B. gcloud deploy run --service=my-service --image=my-image --region=us-central1

C. gcloud run create --name my-service --image gcr.io/my-project/my-image --zone us-central1

D. gcloud container deploy my-service --image=gcr.io/my-project/my-image --region=us-central1

Solution

1. Step 1: Recall correct gcloud run deploy syntax

   The correct command uses 'gcloud run deploy SERVICE_NAME --image=IMAGE --region=REGION'.

2. Step 2: Match options to syntax

   gcloud run deploy my-service --image=gcr.io/my-project/my-image --region=us-central1 matches the correct syntax exactly. Others have wrong commands or flags.

3. Final Answer:

   gcloud run deploy my-service --image=gcr.io/my-project/my-image --region=us-central1 -> Option A

4. Quick Check:

   Correct gcloud run deploy syntax = gcloud run deploy my-service --image=gcr.io/my-project/my-image --region=us-central1 [OK]

Hint: Use 'gcloud run deploy SERVICE --image=IMAGE --region=REGION' [OK]

Common Mistakes:

• Using 'gcloud deploy run' instead of 'gcloud run deploy'
• Confusing --zone with --region
• Using 'gcloud container deploy' which is invalid

3. Given this command: gcloud run deploy my-app --image=gcr.io/project/app:v1 --region=us-east1, what happens after deployment?

medium

A. The app is uploaded but does not run until manually started

B. The app runs on Cloud Run and scales automatically with traffic

C. A virtual machine is created but the app is not deployed

D. The app runs only on your local machine

Solution

1. Step 1: Understand Cloud Run deployment behavior

   Deploying with gcloud run deploy starts the app on Cloud Run immediately with auto-scaling.

2. Step 2: Eliminate incorrect options

   Options B, C, and D describe behaviors not matching Cloud Run's managed service.

3. Final Answer:

   The app runs on Cloud Run and scales automatically with traffic -> Option B

4. Quick Check:

   Cloud Run deploy = app runs and scales automatically [OK]

Hint: Deploy starts app running with auto-scaling on Cloud Run [OK]

Common Mistakes:

• Thinking deployment only uploads code
• Assuming manual start is needed
• Confusing Cloud Run with VM creation

4. You run gcloud run deploy my-service --image=gcr.io/my-project/my-image but get an error about missing region. What is the fix?

medium

A. Remove the --image flag and try again

B. Deploy to Cloud Storage instead

C. Use --zone instead of --region

D. Add the flag --region=REGION with a valid region like us-central1

Solution

1. Step 1: Identify missing required flag

   The error indicates the region flag is missing, which is required for Cloud Run deployment.

2. Step 2: Correct the command by adding --region

   Adding --region=us-central1 (or another valid region) fixes the error.

3. Final Answer:

   Add the flag --region=REGION with a valid region like us-central1 -> Option D

4. Quick Check:

   Missing region error = add --region flag [OK]

Hint: Always specify --region when deploying to Cloud Run [OK]

Common Mistakes:

• Using --zone instead of --region
• Removing --image flag which is required
• Trying to deploy to wrong service like Cloud Storage

5. You want to deploy a new version of your app to Cloud Run but keep the old version running for testing. How can you achieve this?

hard

A. Deploy the new version with the same service name and region

B. Deploy to a different Google Cloud project

C. Use gcloud run update to replace the old version

D. Deploy the new version with a different service name

Solution

1. Step 1: Understand Cloud Run revisions

   Cloud Run automatically creates a new revision when deploying to an existing service, keeping previous revisions available for testing via revision-specific invocations or traffic splitting.

2. Step 2: Deploy new version with the same service name and region

   This leverages Cloud Run's built-in revision management to keep both versions accessible.

3. Final Answer:

   Deploy the new version with the same service name and region -> Option A

4. Quick Check:

   Same service = new revision, old available for testing [OK]

Hint: Deploy to same service name to use revisions for multi-version testing [OK]

Common Mistakes:

• Deploying to a different Google Cloud project unnecessarily
• Using 'gcloud run update' incorrectly for image changes
• Deploying with a different service name when revisions suffice