A public-health symptom triage model will run on Kubernetes. How should its network exposure be deployed?
Select an answer to reveal the explanation.
Short Explanation
You’ll keep the symptom triage model on the civic health network by using a Service and Ingress with a locked perimeter. That scoping helps protect PHI; open internet exposure, SSH to pod IPs, or mirroring endpoints into the open 311 namespace would weaken that boundary.
Full Explanation
Expose the public-health symptom triage model through a Service and Ingress scoped only to the civic health network. This provides stable in-cluster DNS and TLS termination at an approved ingress, while NetworkPolicies, private load balancers, and firewall allowlists let clinicians reach inference without sending PHI-bearing traffic over the open internet or into the open 311 namespace. Publishing the Service on the open internet without network scoping invites scraping, abuse, and compliance findings because triage models can expose sensitive inputs or outputs. Skipping Services and having clinicians SSH directly to pod IPs is brittle because pod IPs change, is unauditable at scale, and bypasses zero-trust ingress patterns. Mirroring every health inference endpoint into the open 311 namespace bridges trust domains and undermines namespace isolation. Exam caveat: an Ingress described as being on the health network must have its controller and load balancer actually attached to that network segment; a name in YAML does not establish isolation. Apply NetworkPolicies and required edge authentication or mTLS, and handle secrets in Ingress annotations carefully. Practical check: resolve the Service from health-network clients, confirm public clients time out or are refused, verify required TLS and authentication, and review that logs and traces containing PHI remain in approved stores.