SRE転職の技術面接で、「Auto ScalingとKubernetesのHPAはどう使い分けますか？」「TerraformのtfstateはどうやってチームでS3管理しますか？」と聞かれて、うまく答えられなかった経験はないでしょうか。
AWS・Kubernetes・IaCに関する面接質問は、「知識を問う」のではなく 実際に設計・運用できるかどうかを見極めるため に出題されます。公式ドキュメントを丸暗記しても、面接官が期待する「現場での実践力」は伝わりません。
本記事では、AWS・Kubernetes・IaC（Terraform）に関してよく出る質問を15問ピックアップし、面接官が期待する答え方のポイントと模範解答例を解説します。
この記事でわかること
– AWSのAuto Scaling・VPC・IAM・EKSについて面接で正確に答える方法
– KubernetesのリソースRequest/Limit・HPA・CrashLoopBackOff対処を体系的に説明する構成
– TerraformのtfstateS3管理・モジュール設計・CI/CD統合を実務ベースで説明する方法
– 「経験がない技術」を聞かれた時の答え方と準備のしかた
– 面接官が実際に見ているポイント（設定方法の知識 vs 設計判断力）
前提条件
SRE転職を目指しているインフラ・バックエンドエンジニアを対象にしています。AWS・Kubernetes・Terraformの基礎（サービスの概要・基本コマンド）については既知のものとして解説します。SLO・インシデント対応の面接対策は前編の記事をご参照ください。
AWSに関する面接質問
Q1：Auto Scalingを設計する際に意識していることを教えてください
面接官が見ているポイント： スケールアウト・インの設定値を機械的に覚えているだけでなく、ビジネス影響とトレードオフを考慮した設計判断ができるか。
模範解答例：
Auto Scalingの設計では、まず「どのメトリクスでスケールするか」を決めます。CPU使用率はWebアプリの負荷指標として一般的ですが、バッチ処理やキュー消費のワークロードではSQSのキュー深度やカスタムメトリクスの方が実態に近いことがあります。
次に「スケールアウトはアグレッシブに、スケールインは保守的に」設計します。スケールアウトのクールダウンは60〜120秒に抑えてスパイクに素早く対応し、スケールインは300〜600秒に設定して頻繁な増減によるコスト増とインスタンス起動コストを避けます。
最後にウォームアップ期間を確認します。アプリ起動に時間がかかる場合（JVMのウォームアップなど）、インスタンスが追加されてもすぐにトラフィックを捌けないため、CloudWatchのメトリクス収集除外期間（ウォームアップ設定）を適切に入れることが重要です。
差がつくポイント：
– 「スパイクが予測できる場合はScheduled Scaling、予測困難な場合はDynamic Scalingを組み合わせた」という実践経験を話せると高評価
– インスタンスタイプのコスト対パフォーマンスの観点（Spot + On-Demandの混在設計）まで触れると応用力が伝わる
Q2：VPCのサブネット設計でどのような点を意識しますか？
面接官が見ているポイント： セキュリティ・高可用性・運用コストのバランスを取った設計判断ができるか。
模範解答例：
VPC設計の基本は「Publicサブネット・Privateサブネット・Isolatedサブネット（DBレイヤー）」の3層分離です。インターネットからのアクセスはPublicのALBで受け、アプリケーション層のEC2・ECSはPrivateに置き、RDS・ElastiCacheはIsolatedサブネットに閉じます。
高可用性のために各サブネットは最低2つのAZにまたがって作ります。たとえば ap-northeast-1a と ap-northeast-1c に同じ構成を置いてAZ障害に備えます。
CIDRブロックの設計では、将来の拡張を考えて余裕を持たせます。/16（65,536アドレス）をVPCに割り当て、サブネットは/24（254アドレス）単位で切っておくと、増設時にIPアドレス不足が起きにくくなります。VPCピアリングや Transit Gateway で複数VPCをつなぐ可能性があるなら、CIDRが重複しないよう組織全体でアドレス管理ルールを決めておくことも重要です。
差がつくポイント：
-「PrivateサブネットからインターネットへのアウトバウンドはNAT Gateway経由にしたが、コスト最適化のためにNAT Instance（小規模）やVPCエンドポイント（S3・DynamoDBへのアクセス）を使い分けた」という経験を話せると実務力が伝わる
Q3：IAMのベストプラクティスを説明してください
面接官が見ているポイント： セキュリティ設計の最小権限原則を理解しているか。インシデント発生時の影響範囲を意識した設計ができるか。
模範解答例：
IAM設計の基本は「最小権限の原則（Principle of Least Privilege）」です。ユーザー・ロール・サービスアカウントそれぞれに、必要最小限の権限のみを付与します。
具体的には、まずIAMユーザーを直接使わずIAMロールを中心に設計します。EC2・Lambda・ECSタスクにはロールをアタッチし、アクセスキーをコード内にハードコードすることを禁止します。次にポリシーは管理ポリシー（AWS管理・カスタム管理）を使い、インラインポリシーは避けます。インラインポリシーは後から権限の棚卸しが困難になるためです。
運用面では、CloudTrailで全API呼び出しを記録し、権限違反のアクセスをアラートで検知できるようにします。定期的なアクセスキーのローテーション（90日以内）とIAM Access Analyzerによる過剰権限の検出も組み合わせると堅牢になります。
差がつくポイント：
– 「本番・ステージング・開発環境でAWSアカウントを分離し、OrganizationsのSCPで制御した」という設計経験があれば触れると環境設計の視野の広さが伝わる
Q4：ECSとEKSはどう使い分けますか？
面接官が見ているポイント： 技術の特性だけでなく、チームのスキルセット・運用コスト・スケール要件を総合して判断できるか。
模範解答例：
大きな判断軸は3つです。「チームのKubernetesスキル」「必要なオーケストレーション機能の複雑さ」「運用オーバーヘッドの許容度」です。
ECSはAWS特有のサービスで、Kubernetesの知識が不要です。小〜中規模でシンプルなマイクロサービス構成であれば、ECS Fargateが最も運用コストが低い選択肢になります。IAMとの統合もネイティブで扱いやすく、デプロイパイプラインもシンプルに保てます。
EKSが向いているのは、チームにKubernetesの知識があり、Helm・ArgoCD・カスタムコントローラーなどKubernetesエコシステムを活用したい場合です。マルチクラウドや本番規模のオートスケーリング（KEDA・HPA）が必要な場合も、EKSの方が柔軟に対応できます。
結論として「KubernetesをAWSに最適化して使いたい・エコシステムを活用したい」→ EKS、「AWSに閉じたシンプルなコンテナ運用をしたい」→ ECS Fargate、という使い分けになります。
差がつくポイント：
– 「既存のECS環境をEKSに移行した経験」や「ECS vs EKSをチームで評価した際の基準と結論」を話せると意思決定力が伝わる
Kubernetesに関する面接質問
Q5：KubernetesのリソースRequest・Limitを正しく設定する方法を教えてください
面接官が見ているポイント： リソース設定の目的と、設定ミスが引き起こす問題（OOMKill・ノード過負荷）を理解しているか。
模範解答例：
RequestはPodが「必ず確保したいリソース量」、LimitはPodが「使えるリソースの上限」です。KubernetesのスケジューラーはRequestを元にPodをノードに配置するため、Requestが適切でないとリソースが偏り、ノードが過負荷になります。
設定の進め方は、まず本番または負荷テスト環境でアプリを稼働させ、実際のCPU・メモリ使用量をPrometheus・CloudWatchで観測します。その実績値の中央値 × 1.2〜1.5倍をRequestに、ピーク値 × 1.5〜2倍をLimitに設定するのが基本です。
Limitを設定しない（or 極端に大きく設定する）とノイジーネイバー問題が起きます。一方でLimitを低くしすぎるとメモリ超過でOOMKillが頻発します。最初はRequestとLimitを同値（Guaranteed QoSクラス）で設定し、観測データを元に徐々に調整するのが安全です。
差がつくポイント：
– 「VPA（Vertical Pod Autoscaler）を使ってRequest値の推奨値を自動算出した」経験を話せると実践力が伝わる
Q6：DeploymentとStatefulSetの違いと、使い分けの基準を教えてください
面接官が見ているポイント： ステートレス・ステートフルアプリの特性を理解して、正しいKubernetesリソースを選択できるか。
模範解答例：
Deploymentはステートレスアプリ向けです。Podはどれも同一で、順不同に起動・削除されます。WebアプリやAPIサーバーなど「どのPodが応答しても同じ結果を返せる」アプリに使います。
StatefulSetはステートフルアプリ向けです。Podに固定の識別子（pod-0、pod-1…）と永続ストレージ（PersistentVolumeClaim）が付き、スケールアウト・インの順序が保証されます。ZookeeperやKafka、MySQLのレプリカセットなど「Podに状態・役割の違いがある」アプリに使います。
判断基準は「Podの再起動・再配置後に、アプリが正しく動くかどうか」です。データをローカルに持ったり、Pod間でリーダー選出を行うアプリはStatefulSet一択です。マネージドサービス（RDS・ElastiCache）を使う場合はKubernetes側ではDeploymentで十分なことが多いです。
差がつくポイント：
– 「StatefulSetのrollingUpdateがうまく行かずに詰まった経験・解決策」などの具体的なトラブルシュート経験を話せると実務ベースの理解が伝わる
Q7：PodがCrashLoopBackOffになった時の調査手順を教えてください
面接官が見ているポイント： トラブルシューティングを体系的・論理的に進められるか。コマンドの使い方だけでなく、原因の切り分け方を知っているか。
模範解答例：
CrashLoopBackOffはPodが起動しては落ちるを繰り返している状態です。まず
kubectl describe pod <pod名>でイベントを確認します。OOMKill（メモリ超過）、Liveness Probe失敗、Init Container失敗などの直接原因が出ることが多いです。次に
kubectl logs <pod名> --previousで前回クラッシュした時のログを取得します。アプリの起動エラー・設定ファイルの読み込みエラー・依存サービスへの接続エラーなどがここで確認できます。原因別の対処方針は以下のとおりです。OOMKillなら Limitを引き上げるかメモリリークを修正します。設定ファイルエラーならConfigMapやSecretの内容を確認します。依存サービス接続失敗なら NetworkPolicy やServiceの設定を確認し、init container でリトライ待機するか検討します。Liveness Probe失敗なら probe のタイムアウト・周期・失敗閾値の設定を見直します。
差がつくポイント：
– kubectl exec -it でコンテナ内に入って直接確認する手順、kubectl get events --sort-by=.lastTimestamp でクラスター全体のイベントを時系列で追う手順まで言及できると調査の深さが伝わる
Q8：HPAとVPAの違いと、使い分けを教えてください
面接官が見ているポイント： Kubernetesのオートスケーリング戦略を理解し、ワークロードの特性に合わせた選択ができるか。
模範解答例：
HPA（Horizontal Pod Autoscaler）はPodの数を増減させるオートスケーリングです。VPA（Vertical Pod Autoscaler）はPodのCPU・メモリのRequest/Limitを自動調整します。
HPAが向いているのは、負荷が予測しにくくリクエスト量に応じてPod数を増やしたいステートレスアプリです。CPU使用率や外部メトリクス（SQSキュー深度など）をトリガーにスケールできます。
VPAが向いているのは、水平スケールが難しいステートフルアプリや、Request/Limitの最適値がわからない段階でアプリを運用する場合です。VPAが推奨値を自動計算してくれるため、初期設定の精度を高めるのに使います。
注意点として、HPAとVPAを同じPodに同時に使うのは基本的にNGです（互いの設定が競合するため）。Cluster Autoscaler（ノード自体の増減）はHPAと組み合わせて使い、「Podが増えたらノードも増える」構成にするのが標準です。
差がつくポイント：
– KEDA（Kubernetes Event-driven Autoscaling）を使ってSQS・Kafkaのメッセージ数ベースでスケールした経験があれば話すと先進的な実践力が伝わる
IaC（Terraform）に関する面接質問
Q9：TerraformのtfstateをS3で管理する方法と、その理由を教えてください
面接官が見ているポイント： tfstateの役割とローカル管理のリスクを理解した上で、チーム開発に適した管理設計ができるか。
模範解答例：
tfstateはTerraformが管理するインフラの「現在の状態」を記録したファイルです。ローカルに置くと複数人で同時にapplyした時に状態が競合し、リソースの二重作成・意図しない削除が起きるリスクがあります。
S3をbackendとして指定すると、tfstateがS3バケットに保存されチームで共有できます。さらにDynamoDBをstate lockingに使うことで、複数人が同時にterraform planやapplyを実行しても排他制御がかかり、競合を防げます。
設定例として、
backend "s3"ブロックにbucket（バケット名）・key（ファイルパス）・region・dynamodb_table（ロック用テーブル名）・encrypt = true（暗号化）を指定します。バケットにはバージョニングを有効にして、万が一のtfstate破損時にロールバックできるようにしておくことも重要です。
差がつくポイント：
– 「環境ごと（dev/stg/prod）にS3のkeyパスを分けて、異なるAWSアカウントにstateを置いた」という設計経験を話せると環境分離設計の理解が伝わる
Q10：Terraformのモジュール設計で意識していることを教えてください
面接官が見ているポイント： DRY（Don’t Repeat Yourself）原則を実践し、再利用性・保守性の高いIaC設計ができるか。
模範解答例：
モジュール設計で意識するのは「凝集性」と「再利用可能な粒度」です。VPC・EC2・RDSなど、変更理由が同じリソース群をモジュールにまとめます。粒度が大きすぎると変更の影響範囲が広くなり、小さすぎると管理するモジュール数が増えすぎて逆に複雑になります。
モジュールのインターフェース設計では
variables.tfで必須変数と省略可能変数（デフォルト値付き）を明示します。呼び出し側はモジュールに渡す値を環境ごとにterraform.tfvarsや*.auto.tfvarsで上書きすることで、dev/stg/prodで同じモジュールを使い回せます。公式のモジュールレジストリ（Terraform Registry）に公開されているAWSモジュール（vpc・eks・rdsなど）は品質が高く、社内モジュールの参考にもなります。ゼロから作る前に既存モジュールの実装を読むと設計パターンが身につきます。
差がつくポイント：
– 「モジュールのバージョン管理をGitのtagで行い、breaking changeを安全に展開するプロセスを作った」経験を話すと組織的なIaC運用の視野が伝わる
Q11：TerraformをCI/CDパイプラインに組み込む場合、どのように設計しますか？
面接官が見ているポイント： セキュリティ（クレデンシャル管理）と安全性（誤ったapplyの防止）を考慮した自動化設計ができるか。
模範解答例：
CI/CDへのTerraform統合では、大きく「plan確認フロー」と「apply実行フロー」を分けて設計します。
プルリクエスト時に
terraform planを自動実行して結果をPRコメントに投稿します（Atlantis・GitHub Actionsで実現可能）。変更内容をコードレビューと同時に確認でき、意図しないリソース変更を事前に防げます。mainブランチへのマージ後に
terraform applyを実行します。この時、AWSの認証情報はIAMロール + OIDC（GitHub ActionsのOpenID Connect）で動的に取得し、長期的なシークレット（アクセスキー）をCI環境に置かないようにします。さらに安全性を高めるために、
-targetによる部分的なapplyは緊急時以外禁止し、常に全体のplan→applyサイクルを守ります。terraform planの出力にdestroyや大規模変更が含まれる場合は、人間のapprovalステップを必須にする設計も有効です。
差がつくポイント：
– AtlantisやSpaceLift、Terraform Cloudなど専用ツールの採用経験があれば話すと、IaC自動化の実用知識が伝わる
面接で差がつく「実践力を示す」答え方
経験がない技術を聞かれた時の対処法
面接でAWS・Kubernetes・Terraformのいずれかに深い経験がない場合、「わかりません」で終わるのは最もNGです。以下の構成で答えると「学習意欲と基礎理解がある候補者」と評価されます。
「実務で深くは使ったことはありませんが、〇〇という仕組みは理解しています。実際の設計では△△のような課題があると想定しており、自学では□□まで手を動かしています。御社での業務では早期にキャッチアップできる自信があります。」
具体的には「手を動かした事実」（Udemyでハンズオン・自宅のk3sクラスターで試した・Terraformでパーソナルプロジェクトのインフラを管理した）があると説得力が格段に上がります。
失敗経験を面接でプラスに変える方法
技術面接では「うまくいった経験」だけでなく、「失敗と学びの経験」を聞かれることがあります。たとえば「障害を出したことがありますか？」「IaCの導入で苦労したことは？」といった質問です。
失敗経験を答える時は STAR形式（Situation・Task・Action・Result）で構成し、必ず「学びと次のアクション」で締めることが重要です。
S（状況）: Terraformのtfstateをローカルで管理していた時期に、チームメンバーが同時にapplyしてstateが壊れた
T（課題）: 本番環境のEC2インスタンスが2重作成されてしまった
A（行動）: S3 + DynamoDBへのbackend移行を即日実施し、手順書を作ってチームに展開した
R（結果）: 以降は競合ゼロ。他のプロジェクトにも同じ構成を横展開した
この構成で答えると「問題を解決して学びを組織に還元できるSRE」として高評価を得やすくなります。
まとめ
本記事ではSRE技術面接のAWS・Kubernetes・IaC編として15問を解説しました。
この記事のポイント
– AWS（Auto Scaling・VPC・IAM・ECS vs EKS）は「設計判断の理由」まで答えられると差がつく
– Kubernetes（Request/Limit・StatefulSet・CrashLoopBackOff・HPA）は「トラブルシュート手順」と「設計トレードオフ」を体系的に説明する
– Terraform（S3 backend・モジュール・CI/CD）は「チーム運用の安全設計」の観点を含めて答える
– 経験がない技術は「仕組みの理解 + 手を動かした事実 + キャッチアップ意欲」で補う
– 失敗経験はSTAR形式で「学びと組織への還元」まで話すと評価が上がる
SLO・インシデント対応の面接対策については前編の記事で詳しく解説しています。両編を合わせて準備することで、技術面接全体をカバーできます。
SRE転職に必要なAWS・Kubernetes・Terraformのスキルを体系的に身につけたい場合は、Udemyのハンズオン講座が効率的です。手を動かしながら学ぶことで、面接で語れる「実経験」を短期間で積むことができます。
コメント