Services and Networking →mediumMultiple ChoiceObjective-mapped

CKAD Ingress pathType: Prefix Practice Question

An Ingress resource is created with the following YAML:

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

Which of the following requests will be routed to the api-svc Service? (Select all that apply.)

⚠ Common exam trap

The common trap is thinking that Prefix matching works as a simple string prefix. In Kubernetes, Prefix matching for Ingress requires that the prefix ends at a path element boundary. For example, the prefix /api matches /api/ and /api/users, but not /apix because 'apix' is not a path element that starts with 'api'.

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

✓

GET http://example.com/api/

Based on the Ingress YAML, the host must be 'example.com' and the path must match the prefix '/api' according to pathType: Prefix, which matches based on URL path elements split by '/'. /api/ and /api/users are valid matches because the first path element 'api' matches and then the prefix ends. /apix does not match because 'apix' is not an element-wise prefix of 'api'. Option A fails due to path '/other'. Option C fails due to host 'example.org'. Therefore, only options B and E are correct.

Answer analysis

Option-by-option breakdown

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

✗
GET http://example.com/other
Why it's wrong here
Despite the correct Host header, this request cannot match the /api prefix rule because its path /other does not contain api as a path element at all. Prefix matching is element-based: the first element of the request path must exactly equal the first element of the configured path, so /other fails immediately. As with other unmatched requests, the Ingress controller will not route it to this rule's backend and will return a 404 or default backend response.
✓
GET http://example.com/api/
Why this is correct
This request is valid because Kubernetes Prefix path matching treats /api/ as having the path element api as its first element, and the trailing slash is simply a separator after that element. The configured path /api is exactly matched by the first path element of /api/, so the rule applies even though the URL ends with a slash. Thus the request is correctly forwarded to the backend service, just like /api/users.
✗
GET http://example.org/api
Why it's wrong here
This request fails because the Ingress rule declares the host 'example.com', and Kubernetes performs exact host-header matching. Requesting http://example.org/api sends a Host header of 'example.org', which does not satisfy the rule's host condition, so the path /api is never evaluated against the backend. Even though the path would match the prefix rule, the unmatched host means the Ingress controller will either fall through to another rule or return a default response such as 404.
✗
GET http://example.com/apix
Why it's wrong here
The host is correct, but the path '/apix' does not match because the prefix '/api' requires that the next character is '/' or end of string. 'apix' is not a path element prefix of 'api'.
✓
GET http://example.com/api/users
Why this is correct
This is the expected successful match: the Host header is 'example.com', matching the rule exactly, and the path /api/users satisfies a Prefix pathType for /api. Kubernetes compares path elements split by '/', so the first element api is identical, and the following /users appears after a slash, making the request match the specified prefix. The Ingress controller therefore routes this request to the configured backend service as intended.

Go deeper

CKAD Ingress pathType: Prefix Practice Question

Why each option matters

Option-by-option breakdown

Related to this question