問題はIPAからご確認ください。
https://www.ipa.go.jp/shiken/mondai-kaiotu/index.html
答えはIPAの回答例となります。
設問１（１）
問題 本文中の「ア」～「エ」に入れる適切な字句又は数値を答えよ
仮想サーバを動かすための土台となるソフトウェアはハイパーバイザーです。
ハイパーバイザーとは、物理コンピュータ上で複数の仮想マシンを実行するためのソフトウェアです。
答え ア：ハイパーバイザー
********************************************************************************
仮想ルータID (VRID: Virtual Router Identifier)はVRRP グループを識別するための番号です。
同一LANセグメント上で、同じVRIDを持つものが一つのVRRPを構成します。
答え イ：VRID
********************************************************************************
VRRPは最大で255組を構成する事が出来ます。（規格上では）
VRID を格納するために 8ビットで、１～255となります。
答え ウ：255
********************************************************************************
DNSサーバに設定するレコードでFQDNとIPアドレスの紐付けるのはAレコードです。
答え エ：A
設問１（２）
問題 本文中の下線①について、2台のAP仮想サーバを同じホストサーバに収容した場合に起きる問題を可用性確保の観点から40字以内で述べよ。
可用性（Availability）は、システムやサービスがダウンしないで正常に使える状態を維持できているかですので、可用性を確保したい場合はダウンしたら困ります。
同じホストサーバaに2台のサーバを収容した場合、VRRPで冗長していても物理サーバ「ホストサーバa」がダウンしたら、アクセスできなくなってしまいます。
答え：ホストサーバが停止した場合、AP仮想サーバが2台とも停止する。
設問（３）
問題 本文中の下線②について、マスタが停止したとバックアップが判定する条件を50字以内で述べよ。
VRRPの切り替わりタイミングはVRRPはマルチキャストで通信します。
同じVRIDの識別子のマスタから連絡（アドバタイズ）が来なくなった場合、バックアップ側だったルータがマスタに切り替わります。
デフォルトでは大体３秒間この Advertisement を受信できないと、バックアップ側がMaster ルータに昇格します。
答え：バックアップが、VRRPアドバタイズメントを決められた時間内に受信しなくなる
設問２（１）
問題 本文中の下線③について、複数ある全ての仮想ブリッジセグメントで同じIPアドレスを利用して問題ない理由を40字以内で述べよ。
WebAPコンテナはPCや共有DBサーバとアクセスする際は、仮想ルータでNAPTされるとなっています。
なので、WebAPコンテナがPCや共有DBサーバへ通信する際は送信元IPアドレスは仮想ルータのアドレスとなります。
外部（PCや共有DBサーバなど）から見たら送信元IPアドレスは仮想ルータのアドレスとなり仮想ブリッジセグメント内のIPアドレスが何でも、NAPTされるので問題ありません。
答え：外部ではコンテナサーバに付与したIPアドレスが利用されることはないから
設問２（２）
問題 本文中の下線④について、共用リバースプロキシはどのヘッダフィールド情報からWebAPを識別するか。15字以内で答えよ。
WebAPコンテナにはAPごとに一つのFQDNが割り当てると書いてあります。
APごとに一つのFQDNなので一意の物となり、FQDNがWebAPコンテナを識別できる情報だと推測できます。
FQDNの情報は、HTTPヘッダのホストヘッダフィールドに入ってます。
答え：ホストヘッダフィールド
表２・３・４ 図４
設問２（３）
問題 本文中の「オ」に入る適切なIPアドレス、および「カ」に入れる適切なポートを答えよ
オ 共用リバースプロキシはクライアントからのHTTPリクエストを受けWebAPコンテナへ振り分けるので、クライアントからのWebAPへのアクセスは共有リバースプロキシが受け取ります。
ですので、PCがDNSサーバから受け取る「ap0.u-sha.com」のIPアドレスは表２に記載されている共有リバースプロキシ「192.168.0.98」のアドレスとなります。
※192.168.0.112と間違えないように注意
答え オ：192.168.0.98
カ 表４を見るとap0.u-sha.com＝192.168.0.112：8000となっています。
IPアドレスの後の「:XXX」は、ポート番号を示しています。
答え カ：8000
設問２（４）
問題 本文中の下線⑤について、変換後の宛先IPアドレスと宛先ポート番号を答えよ。
表４の振り分けルールを見ると192.168.0.112:8000＝AP0a です。
AP0a＝172.16.0.16 ですので、宛先IPは左記になります。
図４を見ると192.168.0.112:8000で受けた通信は172.16.0.16へポート：80で転送してます。
答え 宛先IPアドレス：172.16.0.16
宛先ポート番号：80
設問３（１）
問題 本文中の下線⑥について、専用APごとに確認が必要な仮想ルータのネットワーク機能を二つ答えよ。
「WebAPコンテナは、仮想ルータの上で動作するNAPT機能とTCPやUDPのポートフォワード機能を利用して、PCや共用DBサーバなどといった外部のホストと通信する。」とあるように仮想ルータはNAPT機能とポートフォワード機能を使用しています。
「専用APはTCP/IPを使った独自のプロトコルを利用する」とあるので、仮想ルータの機能と合わせると、独自のプロトコルなのでNAPTやポートフォワーディングのようなポート変換などで懸念がありそうなので、事前に動作確認が必要であると考えていると想定できます。
答え １：NAPT機能
２：ポートフォワーディング機能
設問３（２）
問題 下線⑦について、どのような仕組みが必要か。40字以内で答えよ
コンテナ仮想化は1つのOS上で仮想的に分離して複数のアプリを実行する環境です。
各専用APは、ポート番号も同じ物を使用するようなので、ポート番号で専用APを識別するのは難しそうです。
各コンテナ（専用AP）は一般的には、個別のIPアドレスが割り当てられることが多いので、コンテナ毎にIPアドレスは振られていると考えられます。
なので負荷分散装置で「専用AP＝対象のIPアドレス」と識別できれば良いですね。
答え：複数のIPアドレスを設定し、IPアドレスごとに専用APを識別する仕組み
私のイメージでは下記の様になる想定です
同じポートを使用しない場合は専用APはポート番号で認識が可能ですが、今回はポートも同じです
WebAPの場合はホストヘッダーのFQDNで区別してますので、FQDNがアドレスになった感じですかね
設問４（１）
問題 本文中の「キ」～「ケ」に入る適切な字句を答えよ。
キ ICMPのエコー要求の返答はエコー応答（Echo Reply）ですね
ク TCPのSYNパケットの返答はSYN/ACTですね
ケ HTTP監視でサーバーからリソースを取得して、サーバーが正常に動作しいるかを確認するメソッドは「GET」になります。
答え キ：エコー応答
答え ク：SYN/ACT
答え ケ：GET
設問４（２）
問題 本文中の下線⑧について、表5中の項番2、項番4、項番7で障害検知し、それ以外は正常の場合、どこに障害が発生していると考えられるか。表5中の字句を用いて障害箇所を答えよ。
項番2のコンテナサーバaへのping監視で障害検知していて、コンテナサーバa内のWebAPコンテナ（AP0a）への項番４のTCP監視・項番７のURL監視も障害検知しているので、障害箇所としてはコンテナサーバaが考えられます。
WebAPコンテナ（AP1a）へのTCP監視・URL監視の成否は不明で、コンテナサーバaのPingだけ失敗の可能性もありますが、WebAPコンテナ（AP1a）も障害の可能性の方が高いと思えます。
なので障害発生はコンテナサーバa全体が考えられます
答え：コンテナサーバa
設問４（３）
問題 本文中の下線⑧について、表5中の項番4、項番7で障害検知し、それ以外は正常の場合、どこに障害が発生していると考えられるか。表5中の字句を用いて障害箇所を答えよ。
設問４（２）と違い、コンテナサーバaのPing監視は正常となりました。
なので、表5でわかる障害ポイントはWebAPコンテナ(AP0a）のみとなります
答え：WebAPコンテナ(AP0a）
設問５（１）
問題 表６中の下線⑨について、WebAPコンテナで動作するAPの動作確認を行うために必要になる、テスト用のPCの設定内容を、DNS切替えに着目して40字以内で述べよ。
項番５でDNSレコードを既存のAPサーバから新規の共有リバースプロキシに振り替えています。
なので、項番4の段階では何もしない場合は、既存APサーバにアクセスしてしまいます。
DNSサーバは変更できないのでPC側で名前解決をAPサーバの名前解決を共有リバースプロキシにする必要があります。
テスト用PCで名前解決する為、hostsファイルを利用します。
PCはDNS解決をする際の優先度としてはhostsファイルを参照して、解決できない場合は設定しているDNSサーバに問い合わせを行います。
(Windows)C:\Windows\System32\drivers\etc\hosts はこちらにあります。（基本はコメントアウトされているので使われていないはずです）
答え：APのFQDNとIPアドレスをPCのhostsファイルに記載する。
設問５（２）
問題 表６中の下線⑩について、APサーバ停止前に確認する内容を40字以内で述べよ。
DNS書き換え済みなので、新規ユーザなどは新WebAPにアクセスするのですが、キャッシュが残っているPCやDNSサーバの場合はキャッシュ期間中は古い方のAPサーバへアクセスしてしまいます。
なので、切り替え後にAPサーバへアクセスが無いことを確認する必要があります。
答え：APサーバに対するPCからのアクセスがなくなっていることを確認する。
設問５（３）
問題 本文中の下線⑪について、TTLを短くすることによって何がどのように変化するか。40字以内で述べよ。
TTL（Time To Live）はDNSのレコード情報をキャッシュする時間です
キャッシュDNSサーバは対象のレコード情報を取得したら、TTLの指定されている時間はその情報を保持するので再問合わせを行いません。
なので、今回の内容だとTTLを短くすることで、既存APサーバのDNSレコード情報を保持する時間が短くなり、キャッシュDNSサーバは再問合せを行い、新WebAPコンテナの情報をすぐに反映することができます。
コマンドプロンプトで
nslookup -debug FQDN名
を打つと対象のTTLが確認できます。
右記はこのサイトのTTLです
答え：キャッシュDNSサーバのDNSキャッシュを保持する時間が短くなる。
設問５（４）
問題 本文中の下線⑫について、3パターンそれぞれでAPの動作確認を行う目的を二つ挙げ、それぞれ35字以内で述べよ。
動作確認とは表6の項番4なので、項番1～３は完了後の正常性確認となるはずです。
項番１はWebAPコンテナの構築なので、ここでの確認は正常に構築できたか確認する必要があります。
２台のうち１台目を停止でコンテナサーバａが正常に稼働することを確認、
２台のうち２台目を停止でコンテナサーバｂが正常に稼働することを確認する事で2台が正しく構築されたことを確認できます。
項番２は共有リバースプロキシの振り分けルール設定です。
全てのWebAPコンテナを正常に稼働させることにより、共有リバースプロキシが振分ルール通りに動作しているか確認して設定が正しいか確認できます。
項番３は監視登録となります。
こちらは下線⑫の3パターンではなく、別のパターンになってますので除外です。
答え ①：WebAPコンテナ2台が正しく構築されたことを確認するため
②：共用リバースプロキシの設定が正しく行われたことを確認するため
コメント