For CKAD-level portable Ingress design, which approach should the developer prefer when routing host and path traffic to Services?
Select an answer to reveal the explanation.
Short Explanation
Stick to the portable map—host, path, backend—before leaning on brand-specific sticky notes. Annotations for rewrites can help, but they are controller-specific extras, not the core CKAD rule set.
Full Explanation
For CKAD-level portable Ingress design, prefer standard Ingress rules for host, path, pathType, and backends; treat rewrite annotations as controller-specific extras. Portable manifests that express routing in the core fields travel better across controllers and match what exams emphasize for municipal HTTP entrypoints. Annotations for rewrites, canaries, or configuration snippets can help on particular controllers but should not replace missing host and path rules.
Relying only on proprietary rewrite annotations and omitting host and path rules entirely is non-portable and fragile. Encoding routing exclusively in Pod environment variables and skipping Ingress objects abandons the platform HTTP entrypoint. Replacing Ingress with a DaemonSet that binds hostPort 80 on every node for each app does not scale as a city-wide HTTP routing strategy and fights node isolation and port conflicts.
Exam caveat: if a task needs a rewrite, use the annotation your exam environment documents—but still define proper rules and backends in the Ingress spec. Operational check: write Ingress with clear host/path/backends first, validate with curls using the correct Host header, only then add controller annotations if required. City platform standards should list approved annotations versus routing that must stay in core Ingress fields for portability.