【正解】B
【0からの解説】
①前提知識
・ネットワーク エンドポイント グループ（NEG）は、ロードバランサのバックエンドとして「IP アドレス（＋ポート）」の集合を登録する仕組みです。ゾーン NEG には、エンドポイントが「IP:ポート」の GCE_VM_IP_PORT 型と、「IP のみ」の GCE_VM_IP 型があります。
・GKE のコンテナ ネイティブ負荷分散では、GCE_VM_IP_PORT 型の NEG に Pod の IP アドレスとポートを直接登録します。ロードバランサからノードを経由せず Pod に直接届くため、余分なホップ（kube-proxy による再転送）がなく、ヘルスチェックも Pod 単位で正確になります。VPC ネイティブ クラスタでは Ingress／Gateway が NEG を既定で使い、Service の cloud.google.com/neg アノテーションによって NEG が自動作成・自動更新されます。
・Kubernetes の Service では、targetPort に数値ではなく名前付きポート（例: http-api）を指定でき、実際のコンテナ ポート番号は Pod 側の定義から解決されます。NEG のエンドポイントは、この名前付きポートが解決された Pod の IP:ポートとして GKE コントローラが自動で登録・更新します。
②要件と制約語の整理
・外部 HTTP(S) ロードバランサ（現在の外部アプリケーション ロードバランサ）で公開する
・構成を実際のポート番号から独立させる（名前付きポートを使う）
・ベスト プラクティスに従う
③正解の理由
Service 用に自動作成された GCE_VM_IP_PORT NEG をバックエンドとして参照し、名前付きポート http-api を指定すれば、ポート番号が変わっても GKE が NEG のエンドポイントを自動で更新するため、ロードバランサ側の構成を変える必要がありません。Google が推奨するコンテナ ネイティブ負荷分散の形でもあります。
【誤りの選択肢】
A：インスタンス グループ（ノード）をバックエンドにする方式は、NodePort 経由でノードに届いた後に kube-proxy が Pod に再転送するため、余分なホップと不正確なヘルスチェックが生じます。インスタンス グループの名前付きポートはノード側のポート番号（NodePort）への対応付けであり、Kubernetes Service の名前付きポートとは別物です。コンテナ ネイティブ負荷分散が推奨される現在では、ベスト プラクティスに劣ります。
C：GCE_VM_IP 型の NEG はポートを持たない「IP のみ」のエンドポイントで、内部パススルー ネットワーク ロードバランサ（GKE のサブセット化）などのレイヤ 4 用です。外部 HTTP(S) ロードバランサのバックエンドには使えず、名前付きポートによる指定もできません。
D：ポート番号を直接ハードコードしており、「構成が実際のポート番号に依存しない」という要件に真っ向から反します。ポートが変わるたびにマニフェストとバックエンドの修正が必要になります。
【参考】
スタンドアロン NEG によるコンテナ ネイティブのロード バランシング | GKE networkingゾーン ネットワーク エンドポイント グループの概要 | Cloud Load Balancingアプリケーション ロードバランサ用の GKE Ingress | GKE networking