【正解】C
【0からの解説】
①前提知識：kubectl は Kubernetes クラスタを操作するコマンドライン ツールで、接続先の情報を kubeconfig ファイル（通常 ~/.kube/config）から読みます。kubeconfig には「cluster（API サーバーのエンドポイントと CA 証明書）」「user（認証方法）」「context（cluster と user の組み合わせ）」が登録され、kubectl config use-context で接続先を切り替えられます。
GKE では、gcloud container clusters get-credentials コマンドを実行すると、そのクラスタのエンドポイント・証明書と、gke-gcloud-auth-plugin を使った認証設定が kubeconfig に自動で追加され、現在のコンテキストがそのクラスタに切り替わります。認証は開発者本人の Google アカウント（gcloud auth login でログインした ID）で行われ、有効期間の短いアクセス トークンが都度取得されます。つまり、パスワードや長期間有効な秘密情報を kubeconfig に書き込まずに、開発者ごとに個別の ID で IAM／RBAC に基づくアクセス制御が効きます。
②要件の整理：「同じワークステーション上で」「3 クラスタを定期的に切り替える」「個別のアクセス（開発者ごとの ID）」「安全に」「Google 推奨のプラクティス」。
③正解の理由：C は、各開発者のワークステーションに gcloud CLI を入れ、本人の ID でログインした上で get-credentials を使う方法です。3 クラスタ分のエントリが kubeconfig に正しく作られ、以後は get-credentials の再実行や kubectl config use-context で簡単に切り替えられます。認証情報は本人の Google ID に紐づく短期トークンなので安全で、これが GKE ドキュメントで案内されている標準的な kubectl のアクセス構成方法です。
【誤りの選択肢】
A：Cloud Shell でも get-credentials は使えますが、Cloud Shell はブラウザから使う Google Cloud 上の一時的な VM であり、「同じワークステーション上で」切り替えるという要件を満たしません。開発者のローカルのツールやエディタ、ソースコードとも分かれてしまい、日常的な開発環境としての要件に合致しません。
B：ターミナルを 3 つ開いても kubeconfig は同じファイルを共有するため、ターミナルごとに接続先が分かれるわけではありません。また kubectl config set で cluster・user・認証情報を手作業で組み立てると、証明書やトークンを手で扱うことになり、誤設定や認証情報の漏えいのリスクが増えます。gcloud が自動で正しく構成してくれる方法に比べ、手間と安全性の両面で劣ります。
D：クラスタ・ユーザー・コンテキスト（認証情報を含み得る）をテキスト ファイルにまとめてメールで配布するのは、認証情報の共有・平文送信にあたり、安全ではありません。共通のファイルを配ると「個別のアクセス」にもならず、Google が推奨するやり方とは正反対です。
【参考】
クイックスタート: Google Cloud CLI をインストールする SDKクラスタ管理の概要 | Google Kubernetes Engine (GKE)Cloud Code for VS Code で kubeconfig ファイルを操作する