理解確認：Wired Client Connectivity

答え：B

`Media disconnected`はEthernet Linkが成立していないことを示すため、リモート側へ進む前にクライアントに近いリンク側から確認する。

答え：A / C

Link Upは次の確認へ進めるためのEvidenceであり、接続性全体の正常を証明しない。Page033のClient設定を再利用し、その後の到達性と分けて評価する。

答え：D

Gatewayへのping成功は、その試験についてClientからGatewayまでの到達と応答を確認するEvidenceである。Remote IPやDNS、ローカル側の完全正常まで証明しない。

答え：B / D

最初の失敗がGateway到達性ならGatewayより手前側を優先する。ただしping失敗だけでGateway故障を確定せず、ICMPの制限なども考慮して追加Evidenceを取る。

答え：C

Gatewayまで成功しているため、そのEvidenceを使って調査優先度をGatewayより先へ移す。Gateway成功はローカル側の完全正常証明ではないが、障害範囲を絞る重要な境界になる。

答え：A / D

pingは主にIPレベルの到達性を確認する。成功してもWeb、SSH、DB、DNSなど別の機能が正常であることまでは証明しない。

答え：B

Remote ping失敗には経路上の問題、宛先側の問題、ICMP Filteringや応答制限など複数候補がある。単一結果でRoot Causeを決めず、追加Evidenceで絞る。

答え：A / C / E

Windowsは`tracert`、macOS/Linuxは`traceroute`系Toolを使える。これらはRouting Table一覧ではなく、試験した宛先までの経路上で観測されたHopを確認するために使う。

答え：C

途中の`*`はそのProbeに対して期待した応答をTimeoutまでに得られなかったことを示す。後続Hopと宛先が応答しているなら、中間機器の停止とは断定できない。

答え：D

連続Timeoutと宛先未到達は、最後に応答した地点より先へ障害範囲を絞るEvidenceになる。ただし最初のTimeout地点そのものをRoot Causeとは断定しない。

答え：B

Remote IPには到達できている一方でDNS Queryが失敗しているため、IP到達性と名前解決を分離し、DNS側へ障害範囲を絞る。

答え：A

設定されたDNS Server Addressが正しくても名前解決は失敗し得る。Page034ではClient設定と実際のDNS Queryを分け、名前解決側へ切り分けるところまでを扱う。

答え：C

明確な不一致がDefault Gatewayだけなら、その設定だけを修正する。原因と関係のない正常なIP Address、Prefix、DNSを根拠なく同時変更しない。

答え：B / C / E

Client側Evidenceが正常で上流側が疑われるなら、Client設定を根拠なく変更せずInfrastructure側へ切り分ける。具体的なRouting Protocolや経路選択の修正はPage034の範囲外である。

答え：A / C / D / F

修正後は、修正した設定→その設定に近い到達性→より遠い到達性→必要なら名前解決の順で確認する。設定変更だけで完了とはせず、不要な設定変更もしない。