Ingress

Ingress Quiz

Quiz

Question 1 of 34 (0 answered)

Question 1

What problem does Ingress solve that multiple LoadBalancer Services cannot efficiently address?

Ingress provides faster routing than LoadBalancer Services Ingress consolidates multiple external endpoints into a single public IP with routing rules, avoiding the cost of multiple LoadBalancers Ingress provides better security than LoadBalancer Services LoadBalancer Services don’t support HTTP traffic

✓

Correct!

Ingress solves the problem of needing multiple public IPs/LoadBalancers for different services. Instead of one LoadBalancer per service (expensive and complex), Ingress provides a single entry point that routes to multiple services based on host or path rules.

✗

Incorrect

Think about cost and efficiency when exposing many services.

Question 2

Explain the difference between an Ingress Resource and an Ingress Controller. How do they work together?

Ingress Resource:

Kubernetes API object (YAML manifest)
Defines routing rules (host-based, path-based)
Declarative specification of desired routing
Example: ‘api.example.com → api-service’

Ingress Controller:

Implementation/software that reads Ingress Resources
Runs as pods in the cluster (nginx, AWS ALB, Traefik, etc.)
Configures actual reverse proxy/load balancer
Watches for Ingress Resources and implements their rules

How they work together:

You create an Ingress Resource (routing rules)
Ingress Controller watches for new/updated Ingress Resources
Controller configures its reverse proxy based on the rules
Controller routes external traffic to appropriate Services

Key Point: Ingress Resource is the ‘what’ (rules), Controller is the ‘how’ (implementation).

Did you get it right?

✓

Correct!

✗

Incorrect

Question 3

Which traffic patterns does Ingress handle?

North-South traffic (external clients → cluster services) East-West traffic (service-to-service within cluster) HTTP/HTTPS traffic routing TCP/UDP traffic routing TLS termination

✓

Correct!

Ingress handles north-south HTTP/HTTPS traffic from external clients to cluster services, including TLS termination. It does NOT handle east-west (service-to-service) traffic or general TCP/UDP routing. For east-west advanced features, use Service Mesh.

✗

Incorrect

Ingress is specifically for HTTP/HTTPS external access.

Question 4

Ingress handles both north-south traffic (external to internal) and east-west traffic (service to service within the cluster).

True False

✓

Correct!

False! Ingress only handles north-south traffic (external clients → cluster services). East-west traffic (service-to-service communication within the cluster) is handled by regular ClusterIP Services or Service Mesh for advanced features.

✗

Incorrect

Think about Ingress as the entry point from outside the cluster.

Question 5

How does an Ingress Controller receive external traffic?

It uses ClusterIP Services like backend applications It is exposed via LoadBalancer or NodePort Service It creates its own external IP automatically It bypasses Services entirely

✓

Correct!

The Ingress Controller itself must be exposed externally via a LoadBalancer or NodePort Service so it can receive incoming HTTP/HTTPS traffic. The backend application Services typically use ClusterIP (internal only), while the Ingress Controller’s Service needs external access.

✗

Incorrect

The Ingress Controller is just a pod that needs external access to receive traffic.

Question 6

Given this Ingress configuration, which URL pattern will route to the ‘api’ service?

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api
            port:
              number: 80

What will this code output?

http://example.com/api only http://example.com/api, http://example.com/api/v1, http://example.com/api/users All requests to example.com Any URL containing '/api' anywhere in the path

✓

Correct!

With pathType: Prefix and path: /api, the Ingress matches any path starting with ‘/api’, including /api/v1, /api/users, etc. This is a prefix match, not an exact match.

✗

Incorrect

With pathType: Prefix and path: /api, the Ingress matches any path starting with ‘/api’, including /api/v1, /api/users, etc. This is a prefix match, not an exact match.

Pay attention to pathType: Prefix - what does ‘prefix’ mean?

Question 7

List all three pathType options in Ingress (comma-separated):

✓

Correct!

The three pathType options are: Exact (exact path match), Prefix (matches path prefix), and ImplementationSpecific (controller-dependent behavior, e.g., nginx regex support).

✗

Incorrect

The three pathType options are: Exact (exact path match), Prefix (matches path prefix), and ImplementationSpecific (controller-dependent behavior, e.g., nginx regex support).

The three types are: one for exact matches, one for prefix matches, and one that’s controller-specific.

Question 8

Arrange the Ingress traffic flow in correct order:

Sequence from external client to pod

⋮⋮ External client makes HTTPS request

⋮⋮ Ingress Controller terminates TLS

⋮⋮ Request reaches Ingress Controller (via LoadBalancer/NodePort)

⋮⋮ Controller routes based on host/path rules

⋮⋮ Request forwarded to backend ClusterIP Service

⋮⋮ Service routes to Pod

⋮⋮ Pod processes HTTP request

✓

Correct!

Traffic flows: External request → Ingress Controller → TLS termination → Routing decision → Backend Service → Pod. The pod receives plain HTTP after TLS termination at the Ingress layer.

✗

Incorrect

Traffic flows: External request → Ingress Controller → TLS termination → Routing decision → Backend Service → Pod. The pod receives plain HTTP after TLS termination at the Ingress layer.

Question 9

Explain the difference between host-based routing and path-based routing in Ingress. Provide examples.

Host-Based Routing:

Routes based on the hostname (domain) in the request
Different domains → different services
Example:
- api.example.com → api-service
- web.example.com → web-service
- admin.example.com → admin-service
Use case: Multiple applications on different subdomains

Path-Based Routing:

Routes based on the URL path
Same domain, different paths → different services
Example:
- example.com/api → api-service
- example.com/web → web-service
- example.com/admin → admin-service
Use case: Microservices architecture on single domain

Both can be combined in a single Ingress — e.g., route by host first, then by path within that host.

Did you get it right?

✓

Correct!

✗

Incorrect

Question 10

In a TLS-enabled Ingress, where does TLS termination occur?

At the pod level At the Service level At the Ingress Controller level At the cloud load balancer level

✓

Correct!

TLS termination occurs at the Ingress Controller. The controller presents the certificate, terminates TLS, decrypts the request, and forwards plain HTTP to the backend Service/Pod. This means pods receive unencrypted HTTP traffic.

✗

Incorrect

Think about where the TLS secret is referenced in the Ingress manifest.

Question 11

Complete the Ingress configuration to enable TLS for ‘api.example.com’ using a secret named ‘api-tls’:

Fill in the TLS section

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-ingress
spec:
  ingressClassName: nginx
  _____:
  - hosts:
    - api.example.com
    secretName: api-tls
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api
            port:
              number: 80

Your answer:

✓

Correct!

The tls: section in the Ingress spec defines TLS configuration, including which hosts to secure and which Secret contains the certificate and key.

✗

Incorrect

The tls: section in the Ingress spec defines TLS configuration, including which hosts to secure and which Secret contains the certificate and key.

Question 12

When creating a TLS Secret for Ingress, the Secret type must be ‘kubernetes.io/tls’ with keys ’tls.crt’ and ’tls.key’.

True False

✓

Correct!

True! TLS Secrets for Ingress must have type kubernetes.io/tls and contain two data fields: tls.crt (the certificate) and tls.key (the private key), both base64-encoded.

✗

Incorrect

True! TLS Secrets for Ingress must have type kubernetes.io/tls and contain two data fields: tls.crt (the certificate) and tls.key (the private key), both base64-encoded.

There’s a specific Secret type for TLS certificates.

Question 13

What is an IngressClass and why is it important? How does it relate to Ingress Controllers?

IngressClass:

Kubernetes resource that identifies which Ingress Controller should handle an Ingress
Metadata layer between Ingress Resources and Controllers
Allows multiple Ingress Controllers to coexist in the same cluster

Relationship:

Ingress Resource
  ↓ (references via ingressClassName)
IngressClass
  ↓ (identifies via controller field)
Ingress Controller (nginx pod)
  ↓ (watches and implements)
Routing configuration

Why Important:

Multi-controller support: Run nginx AND AWS ALB in same cluster
Selective processing: Each Ingress specifies which controller handles it
Default behavior: Mark one IngressClass as default for Ingress without ingressClassName

Example:

IngressClass ’nginx’ → controller: k8s.io/ingress-nginx
IngressClass ‘aws-alb’ → controller: ingress.k8s.aws/alb
Ingress with ingressClassName: nginx → nginx controller handles it

Did you get it right?

✓

Correct!

✗

Incorrect

Question 14

What can you configure using nginx Ingress Controller annotations?

HTTP to HTTPS redirect (force-ssl-redirect) CORS settings (enable-cors, cors-allow-origin) Rate limiting (limit-rps) Pod resource limits Path rewriting (rewrite-target) Authentication (auth-type, auth-secret)

✓

Correct!

Ingress annotations control controller-specific features like SSL redirect, CORS, rate limiting, path rewriting, and authentication. They don’t control pod-level settings like resource limits - those are in the pod spec.

✗

Incorrect

Annotations control HTTP/routing behavior, not pod configuration.

Question 15

What is the purpose of the ‘defaultBackend’ in an Ingress?

It’s the primary backend for all traffic It handles requests that don’t match any rules (404 handling) It’s a backup when primary backends fail It’s required for all Ingress resources

✓

Correct!

The defaultBackend handles requests that don’t match any defined rules, typically serving custom 404 pages or error responses. It’s optional and provides a catch-all for unmatched traffic.

✗

Incorrect

The defaultBackend handles requests that don’t match any defined rules, typically serving custom 404 pages or error responses. It’s optional and provides a catch-all for unmatched traffic.

Think about what happens when a request doesn’t match any routing rule.

Question 16

What percentage of traffic goes to ‘api-v2’ service with this canary configuration?

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  ingressClassName: nginx
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-v2
            port:
              number: 80

What will this code output?

100% (canary replaces main) 10% (canary-weight: 10) 90% (inverse of weight) 50% (equal split)

✓

Correct!

With canary: true and canary-weight: 10, this Ingress receives 10% of traffic to api.example.com. The main (non-canary) Ingress for the same host receives the remaining 90%.

✗

Incorrect

With canary: true and canary-weight: 10, this Ingress receives 10% of traffic to api.example.com. The main (non-canary) Ingress for the same host receives the remaining 90%.

The weight directly specifies the percentage to this backend.

Question 17

An Ingress Controller requires at least one Ingress Resource to function properly.

True False

✓

Correct!

False! An Ingress Controller can run without any Ingress Resources. It simply won’t route any traffic until Ingress Resources are created. The controller watches for Ingress Resources and configures routing accordingly.

✗

Incorrect

Think about the controller as software waiting for configuration.

Question 18

What are the benefits of using Ingress over multiple LoadBalancer Services?

Single public IP instead of one per service Centralized routing configuration Built-in TLS termination Better performance than LoadBalancer Native Kubernetes integration Automatic DNS management

✓

Correct!

Ingress provides: single IP (cost savings), centralized config, TLS termination, and Kubernetes-native management. Performance isn’t inherently better, and DNS management is separate (requires external DNS or manual configuration).

✗

Incorrect

Focus on cost, management, and integration benefits.

Question 19

Which Service type is typically used for backend application services that Ingress routes to?

LoadBalancer NodePort ClusterIP ExternalName

✓

Correct!

Backend services typically use ClusterIP (internal-only) since the Ingress Controller handles external access. Only the Ingress Controller itself needs a LoadBalancer/NodePort Service for external reachability.

✗

Incorrect

Backend services don’t need external access - only internal cluster access.

Question 20

To mark an IngressClass as the default, use the annotation: ingressclass.kubernetes.io/is-default-class: “_____”

✓

Correct!

The annotation ingressclass.kubernetes.io/is-default-class: "true" marks an IngressClass as default. Ingress Resources without an ingressClassName will automatically use this default class.

✗

Incorrect

The annotation ingressclass.kubernetes.io/is-default-class: "true" marks an IngressClass as default. Ingress Resources without an ingressClassName will automatically use this default class.

It’s a boolean value as a string.

Question 21

Compare nginx Ingress Controller, AWS ALB Controller, and Istio Gateway. When would you use each?

nginx Ingress Controller:

Pros: Lightweight, flexible, works anywhere, large community, regex routing
Cons: Not cloud-native, manual management, requires an external LB
Use when: Cloud-agnostic deployment, on-premises, need flexibility

AWS ALB Ingress Controller:

Pros: Native AWS integration, auto-scaling, security groups
Cons: AWS-specific, requires IAM setup
Use when: AWS-only deployment, want native AWS features, cost optimization

Istio Ingress Gateway:

Pros: Advanced traffic management, mTLS, circuit breaking, unified with service mesh
Cons: Complex setup, higher resource overhead, steep learning curve
Use when: Need advanced features, already using Istio, require mTLS

Decision Matrix:

Cloud-agnostic or hybrid → nginx
EKS + want AWS-native integrations (WAF, ACM, Shield) → AWS ALB
Need mTLS, traffic shifting, mesh policies → Istio

Did you get it right?

✓

Correct!

✗

Incorrect

Question 22

Given this Ingress with multiple paths, which request matches the ‘/admin’ path?

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-path
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /admin
        pathType: Exact
        backend:
          service:
            name: admin-service
            port:
              number: 80

What will this code output?

http://example.com/admin only http://example.com/admin and http://example.com/admin/users http://example.com/admin, http://example.com/administrator Any URL containing 'admin'

✓

Correct!

With pathType: Exact on the ‘/admin’ path, only exactly ‘http://example.com/admin' matches. Requests like ‘/admin/users’ would not match because Exact requires an exact path match, not a prefix.

✗

Incorrect

Exact means EXACT - nothing more, nothing less.

Question 23

What command creates a TLS Secret named ‘my-tls’ from certificate files tls.crt and tls.key for use with Ingress?

✓

Correct!

The correct command is kubectl create secret tls <name> --cert=<cert-file> --key=<key-file>. This creates a Secret with type ‘kubernetes.io/tls’ containing the properly named keys ’tls.crt’ and ’tls.key’.

✗

Incorrect

There’s a specific secret subcommand for TLS certificates.

Question 24

Which statements about Ingress pathType are TRUE?

Prefix matches any path starting with the specified prefix Exact matches only the exact path specified ImplementationSpecific behavior depends on the Ingress Controller Prefix is case-insensitive nginx supports regex patterns with ImplementationSpecific

✓

Correct!

Prefix matches path prefixes, Exact requires exact match, ImplementationSpecific is controller-dependent (nginx supports regex), and path matching is case-sensitive by default.

✗

Incorrect

Prefix matches path prefixes, Exact requires exact match, ImplementationSpecific is controller-dependent (nginx supports regex), and path matching is case-sensitive by default.

Path matching is case-sensitive unless specified otherwise.

Question 25

After TLS termination at the Ingress Controller, traffic between the Ingress Controller and backend pods is encrypted by default.

True False

✓

Correct!

False! After TLS termination at the Ingress Controller, traffic to backend Services/Pods is typically plain HTTP unless you explicitly configure end-to-end encryption. This is why TLS termination can simplify certificate management.

✗

Incorrect

Think about where ’termination’ happens - what happens after that point?

Question 26

Complete this Ingress to route ’example.com/users’ to ‘users-service’ and ’example.com/products’ to ‘products-service’:

Fill in the missing path and service name

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: microservices
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: users-service
            port:
              number: 80
      - path: _____
        pathType: Prefix
        backend:
          service:
            name: _____
            port:
              number: 80

Your answer:

✓

Correct!

To route ’example.com/products’ to ‘products-service’, the path should be ‘/products’ and the service name should be ‘products-service’.

✗

Incorrect

To route ’example.com/products’ to ‘products-service’, the path should be ‘/products’ and the service name should be ‘products-service’.

Question 27

What happens if you create an Ingress Resource but no Ingress Controller is installed in the cluster?

The Ingress Resource is rejected and fails to create The Ingress Resource is created but does nothing (no routing occurs) Kubernetes automatically installs a default Ingress Controller The API server handles routing automatically

✓

Correct!

The Ingress Resource will be created successfully but remain non-functional. Without an Ingress Controller to read and implement the routing rules, no traffic routing occurs. The resource just sits in etcd waiting for a controller.

✗

Incorrect

Ingress Resources are just declarations - they need a controller to implement them.

Question 28

What are the key Ingress components and their responsibilities?

Ingress Resource:

Defines routing rules (declarative config)
Specifies hosts, paths, and backend services
Role: What to route

IngressClass:

Links Ingress Resources to specific Controllers
Allows multiple controllers in one cluster
Role: Which controller handles this Ingress

Ingress Controller:

Implements the actual routing (runs nginx/ALB/Istio/etc.)
Watches Ingress resources and configures load balancer
Role: How to route (the implementation)

TLS Secret:

Stores certificates and private keys
Referenced by Ingress for HTTPS termination
Role: Enables secure connections

Backend Service:

Receives routed traffic from Ingress
ClusterIP service that forwards to Pods
Role: Final destination for requests

[CONTROL PLANE]

Ingress Resource
   ↓ (ingressClassName)
IngressClass
   ↓ (controller field)
Ingress Controller (control loop)
   ↓
Generates proxy config (NGINX / Envoy)

[DATA PLANE]

External Client
   ↓
LoadBalancer / NodePort Service
   ↓
Ingress Controller Pod (NGINX data plane)
   ↓ (TLS termination + routing)
ClusterIP Service
   ↓
Pod

Did you get it right?

✓

Correct!

✗

Incorrect

Question 29

Which kubectl command shows the external IP assigned to an Ingress?

kubectl get pods kubectl get services kubectl get ingress kubectl get endpoints

✓

Correct!

kubectl get ingress (or kubectl get ing) shows Ingress resources including their assigned ADDRESS/external IP. Use -w flag to watch for IP assignment: kubectl get ingress -w.

✗

Incorrect

kubectl get ingress (or kubectl get ing) shows Ingress resources including their assigned ADDRESS/external IP. Use -w flag to watch for IP assignment: kubectl get ingress -w.

You want to see the Ingress resource itself.

Question 30

The annotation to force HTTP to HTTPS redirect in nginx Ingress is: nginx.ingress.kubernetes.io/_____: “true”

✓

Correct!

The annotation nginx.ingress.kubernetes.io/force-ssl-redirect: "true" forces all HTTP requests to redirect to HTTPS, a common security practice.

✗

Incorrect

The annotation nginx.ingress.kubernetes.io/force-ssl-redirect: "true" forces all HTTP requests to redirect to HTTPS, a common security practice.

It’s about forcing SSL redirect.

Question 31

Explain how to troubleshoot an Ingress that isn’t routing traffic correctly. What should you check?

Mental Model:

1. Check DNS                 ← Can the client even reach the Ingress?
2. Check Ingress Controller  ← Is the implementation running?
3. Verify IngressClass       ← Is the right controller selected?
4. Verify Ingress Status     ← Are the rules configured correctly?
5. Test Routing (curl)       ← Do the Ingress rules route correctly?
6. Check TLS                 ← Are certificates valid and referenced?
7. Verify Backend Service    ← Does the destination exist?
8. Check Pods                ← Are there healthy backends?

Ingress Troubleshooting Checklist:

1. Check DNS:

nslookup api.example.com
# Does domain resolve to Ingress IP?

2. Check Ingress Controller:

kubectl get pods -n ingress-nginx
# Is controller running? Check logs for errors
kubectl logs -n ingress-nginx <controller-pod>

3. Verify IngressClass:

kubectl get ingressclass
# Does the IngressClass exist?
kubectl get ingress <name> -o yaml | grep ingressClassName
# Does Ingress reference the correct IngressClass?

4. Verify Ingress Status:

kubectl describe ingress <name>
# Check: Address assigned? Rules correct? Backends listed?

5. Test Routing:

curl http://api.example.com
# Test host-based routing
curl http://api.example.com/api
# Test path-based routing

6. Check TLS (if using HTTPS):

kubectl get secret <tls-secret-name>
# Does the Secret exist?
kubectl get ingress <name> -o yaml | grep -A2 tls
# Is it referenced correctly in the Ingress spec?

7. Verify Backend Service:

kubectl get svc <backend-service>
kubectl get endpoints <backend-service>
# Service exists? Has endpoints (pods)?

8. Check Pods:

kubectl get pods -l app=<backend>
# Pods running? Ready?

Common Issues:

No Ingress Controller installed
IngressClass doesn’t exist or wrong ingressClassName
Backend Service doesn’t exist
No pods matching Service selector
DNS not pointing to Ingress IP
TLS Secret missing or incorrectly referenced

Did you get it right?

✓

Correct!

✗

Incorrect

Question 32

Istio is an Ingress Controller that replaces nginx or other traditional Ingress Controllers.

True False

✓

Correct!

False! Istio itself is not an Ingress Controller - it’s a service mesh. However, Istio includes an ‘Ingress Gateway’ component that acts like an Ingress Controller for north-south traffic while providing service mesh features.

✗

Incorrect

Istio is more than just an Ingress Controller.

Question 33

When should you use Service Mesh instead of Ingress?

When you need HTTP/HTTPS routing from external clients When you need east-west traffic management (service-to-service) When you require mTLS between services When you need advanced observability and traffic splitting internally When you want a simple external entry point

✓

Correct!

Service Mesh (like Istio, Linkerd) is for east-west traffic management, mTLS between services, and advanced internal features. Ingress is for north-south HTTP/HTTPS external access. They serve different purposes and often work together.

✗

Incorrect

Service Mesh is about internal service communication, not external access.

Question 34

With this configuration, what happens when a request to ‘http://example.com/users' is made?

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  ingressClassName: nginx
  defaultBackend:
    service:
      name: default-404
      port:
        number: 80
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

What will this code output?

Routes to api-service Routes to default-404 service (no matching path) Returns 404 error Routes to the first available service

✓

Correct!

The request to ‘/users’ doesn’t match the defined path ‘/api’, so it falls through to the defaultBackend which routes to the ‘default-404’ service. This is the purpose of defaultBackend - catching unmatched requests.

✗

Incorrect

What happens when no rule matches? Check the defaultBackend.

Quiz Results

Score

0/0

Accuracy

Right

Wrong

Skipped

Last updated on March 28, 2026

Services Storage