GKE Ingress with Load Balancer in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of kubectl get ingress command

You have deployed an Ingress resource in GKE with a Load Balancer. What is the output of kubectl get ingress after the Load Balancer IP is assigned?

GCP

kubectl get ingress my-ingress

A

NAME        CLASS    HOSTS   ADDRESS          PORTS   AGE
my-ingress  <none>   *       192.168.1.1      80      5m

B

NAME        CLASS    HOSTS   ADDRESS          PORTS   AGE
my-ingress  <none>   *       34.68.123.45     80      5m

C

NAME        CLASS    HOSTS   ADDRESS          PORTS   AGE
my-ingress  <none>   *       10.0.0.1         80      5m

D

NAME        CLASS    HOSTS   ADDRESS   PORTS   AGE
my-ingress  <none>   *       <pending> 80      5m

💡 Hint

The external IP address assigned by the GCP Load Balancer is a public IP, not a private IP.

When the Load Balancer is ready, the ADDRESS field shows the external public IP assigned by GCP, such as 34.68.123.45. Pending means the IP is not assigned yet. Private IPs like 10.x.x.x or 192.168.x.x are not used for external Load Balancers.

🧠 Conceptual

intermediate

Purpose of BackendConfig in GKE Ingress

What is the main purpose of using a BackendConfig resource in GKE Ingress with Load Balancer?

A To configure advanced settings like connection draining, timeouts, and health checks for backend services.

B To define the frontend IP address of the Load Balancer.

C To specify the DNS name for the Ingress resource.

D To create firewall rules for the Load Balancer.

💡 Hint

BackendConfig customizes backend service behavior beyond default settings.

BackendConfig allows you to set advanced Load Balancer backend options such as connection draining duration, timeout settings, and health check parameters for your services.

❓ Troubleshoot

advanced

Troubleshooting Ingress Not Getting External IP

You created an Ingress resource in GKE but the ADDRESS field remains <pending> for over 10 minutes. What is the most likely cause?

A The Ingress resource is missing the <code>spec.rules</code> section.

B The Kubernetes API server is down.

C The backend Pods are not running any containers.

D The cluster does not have the required cloud permissions to create a Load Balancer.

💡 Hint

Check if the GKE cluster has permissions to create cloud resources like Load Balancers.

If the cluster lacks permissions, GKE cannot provision the external Load Balancer, so the ADDRESS stays pending. Missing rules or backend Pods affect routing but do not block IP assignment. API server down would prevent any kubectl commands.

🔀 Workflow

advanced

Steps to Enable HTTPS on GKE Ingress with Load Balancer

Which sequence correctly describes the steps to enable HTTPS on a GKE Ingress with a Load Balancer?

A 1,3,2,4

B 3,2,1,4

C 3,1,2,4

D 1,2,3,4

💡 Hint

You must deploy your app and service before configuring certificates and Ingress annotations.

First deploy your app and expose it with a Service (3). Then create the ManagedCertificate (1). Next, annotate the Ingress to use the certificate (2). Finally, verify the certificate status and HTTPS (4).

✅ Best Practice

expert

Best Practice for Securing GKE Ingress with Load Balancer

Which option is the best practice to secure your GKE Ingress with a Load Balancer for production use?

A Use HTTPS with ManagedCertificate, enable HTTP to HTTPS redirect, and restrict backend access with firewall rules.

B Use HTTP only to reduce latency and avoid certificate management complexity.

C Disable health checks to improve backend performance.

D Expose backend Pods directly without a Service to reduce network hops.

💡 Hint

Security best practices include encryption and access control.

Using HTTPS with ManagedCertificate ensures encrypted traffic. Redirecting HTTP to HTTPS improves security. Firewall rules restrict backend access to trusted sources. Other options reduce security or break Kubernetes networking.