理解確認：AWS Transit Gatewayによる大規模ネットワーク設計

答え：D

標準方式ではTGWへ入ったトラフィックは、送信元アタッチメントに関連付けされたTGW ルートテーブルを参照して次のアタッチメントを判断します。PBRを使う場合はポリシーテーブルが先に評価されます。

答え：A / D / E

標準のルートテーブル方式では、関連付けは送信元が参照するルートテーブル、伝播は到達可能プレフィックスを知らせるルートテーブルを決めます。PBR方式ではアタッチメントへポリシーテーブルを関連付けるため、この関連付けモデルと区別します。

答え：C

VPC アタッチメントでTGWを利用するAZごとに、そのAZからサブネットを1つ選択する必要があります。

答え：D

送信元ごとのルーティングドメインを分け、必要な共有プレフィックスだけを見せることでネットワーク 分離を実現します。

答え：A

VPC ルートテーブルとTGW ルートテーブルは別のルーティングレイヤーです。VPCからTGWへ送るルートも必要です。

答え：D

より具体的な /16 が最長プレフィックス一致で選択されます。

答え：C

同一宛先 CIDRでは静的ルートが伝播ルートより優先されます。

答え：B

往路と共有 VPC側のVPC ルートが正しいため、復路で共有側アタッチメントが参照するTGW ルートテーブルに本番向けルートがあるか確認します。

答え：A

関連付けはどのTGW ルートテーブルを見るかを決める仕組みで、宛先ルートは伝播または静的ルートで用意します。

答え：A

集中型の外向き通信や検査のように明示した次 ホップへトラフィックを送る場合、TGW ルートテーブルへデフォルト静的ルートなどを設定できます。

答え：B

Transit Gateway ピアリングアタッチメントへのルーティングは静的ルートとして設定します。リモート TGW配下のルートが通常のVPC アタッチメントのように自動伝播されるとは考えません。

答え：A

TGWのブラックホールルートは指定プレフィックスへのトラフィックを明示的に破棄するために利用できます。一方、通常の分離は関連付け / 伝播で必要なルートだけを見せる設計が基本です。

答え：B

全アタッチメントが同じルーティングポリシーでよい単純構成では1つのTGW ルートテーブルでも成立します。複数ルートテーブルは異なるネットワークドメインや分離 ポリシーが必要な場合に使います。

答え：B / C / E / G

Transit GatewayはVPC、Site-to-Site VPN、Direct Connect ゲートウェイとの連携、Transit Gateway ピアリングなどで接続性を中央化できます。インターフェイスエンドポイント、インターネットゲートウェイ、S3 バケットをTGWへ直接アタッチメントする仕組みではありません。

答え：B / C / D

現在 Transit GatewayではVPN Concentrator、クライアント VPN、ネットワーク関数などのアタッチメントタイプも利用できます。本文のアタッチメント一覧を古いVPC/VPNだけに限定して理解しません。

答え：B

VPC アタッチメントではAZごとに1つのサブネットを選択してTGWのネットワークインターフェイスを配置しますが、そのサブネットだけがTGW利用対象になるわけではありません。同じAZの他サブネットも適切なVPC ルートでTGWへ送れます。

答え：A / C / E / F

PBRは宛先だけでなくパケット属性を使ってトラフィックを分類し、カスタマーマネージドルールは番号順に評価され、最初に一致したルールが使用するTGW ルートテーブルを選びます。ポリシーテーブルと標準ルートテーブルを同一アタッチメントへ同時関連付けせず、一致なしは暗黙的な拒否です。ポート条件はTCP / UDPで利用します。

答え：B

要件は「同じ宛先でもトラフィック属性によって経路を変える」ことです。宛先プレフィックス中心の標準ルートテーブルだけではポート単位で分岐できないため、PBRのポリシールールでトラフィックを分類し、ルールごとに対象 TGW ルートテーブルを選ぶ設計が適切です。