AWS認定の無料問題。
毎日5問、理解を積み重ねる。

DNSSEC署名はホストゾーン単位で有効化する機能であり、有効化するとそのゾーンの全ての応答が署名されると同時に、ゾーン内の全レコードのTTLも1週間に強制的に制限される。Aはアクセス制御の仕組みで署名やTTLの適用範囲を絞れると誤認しており、ゾーン単位での適用という前提に反する。Bは同じドメイン名で2つ目のホストゾーンを作成する案だが、実際に権威DNSとして機能するのはレジストラから委任された1つのゾーンのみであり、2つ目のゾーンに置いたレコードは通常の名前解決では参照されないため成立しない。Cは事業子会社のレコードを同じゾーンに残したままTTLを30日に設定する案だが、DNSSEC署名を有効化したゾーンではTTLが1週間に強制されるため、設定した30日のTTLは実際には適用されず契約上の要件を満たせない。Dは事業子会社のレコードをNSレコードによる委任で別のホストゾーンに物理的に分離するため、親ゾーンのDNSSEC署名・TTL制約は親ゾーンに残るチェックアウトシステムのレコードにしか及ばず、委任先の子ホストゾーンでは30日のTTLを維持したまま署名を無効の状態に保て、各社の体制が整い次第個別に署名を有効化できる。ゾーン単位の署名範囲とTTL強制という2つの制約、および委任による権威DNSの分離という3つの独立した要素をすべて満たすのはDのみである。

A：IAMポリシーはAPIやリソースへのアクセス許可を制御する仕組みであり、DNSSEC署名がホストゾーン内のどのレコードに適用されるかを制御する手段ではない。ホストゾーンでDNSSEC署名を有効化すれば、IAMポリシーの設定内容にかかわらずそのゾーンの全レコードの応答が署名され、TTLも一律に制限を受けるため、事業子会社のレコードを署名対象・TTL制約の両方から外すことができない。

B：実際にインターネットからの問い合わせに応答するのは、レジストラ側でネームサーバーとして委任された1つのホストゾーンだけである。同じ名前で2つ目のホストゾーンを作成しても権威DNSとして機能せず、そちらに置いた事業子会社のレコードは通常の名前解決経路では参照されないため、30日のTTLを維持する設定自体が意味を持たず、要件を満たせない。

C：DNSSEC署名を有効化したホストゾーンでは、レコードに設定したTTLの値にかかわらずRoute 53がTTLを1週間に強制する。エラーにはならないため一見TTLが30日のまま維持されているように見えるが、実際には1週間に短縮されて配信されるため、提携先リゾルバとの契約で必要な30日のTTLを維持できず、要件を満たせない。

D：NSレコードによる委任で事業子会社のレコードを別のホストゾーンへ物理的に分離すれば、親ゾーンでDNSSEC署名を有効化してもその効果は親ゾーン内のチェックアウトシステムのレコードとその1週間TTL制約にしか及ばない。委任先の子ホストゾーンは親ゾーンとは独立した設定を持つため、30日のTTLを維持したまま署名を無効の状態に保つことができ、各事業子会社は自社のKSK運用体制が整い次第、自身のホストゾーンで個別にDNSSEC署名を有効化できる。ゾーン単位でしか区切れない署名範囲とTTL制約の両方を同時に満たす唯一の構成である。

学習のポイント：DNSSEC署名はホストゾーン単位でしか有効化できず、有効化するとそのゾーンの全レコードのTTLも一律1週間に強制されるため、異なるTTL要件を持つレコード群を署名対象・TTL制約の両方から外すには、NSレコードによる委任で別のホストゾーンに物理的に分離するしかない。

公式ドキュメント

• dns-configuring-dnssec.html
• dns-configuring-dnssec-ksk.html

正解はAとBである。Aは、注文イベントを SNS トピックへ発行し、在庫・通知・請求の各サービスが専用の SQS キューで受け取る構成であり、受付を後続処理から切り離して急増をキューで吸収でき(要件1)、各サービスがすべての注文イベントを独立して処理できる(要件2)ため正しい。Bは、1注文ごとの支払い確認から出荷指示までの順序と進行状況を AWS Step Functions のステートマシンで管理でき(要件3)、受付のバッファやイベント配信はAに任せられるため、Aと役割が重ならず両立する。Cは、同期呼び出しで受付が下流の応答を待つため、下流の遅延が受付に波及し、急増も吸収できず、要件1・2を満たさない。Dは、夜間にまとめて処理するため、各サービスが個々のイベントを独立して受け取る要件2と、注文ごとの進行を把握する要件3を満たさない。Eは、全手順を単一のプロセスに実装するため、受付と後続処理を切り離せず要件1・2を満たさず、イベントベースの構成と比べてスケーラビリティと冗長性の面でも劣る。

A：注文受付は SNS トピックへイベントを発行するだけで済み、在庫・通知・請求の処理を待たないため、後続処理の速度に影響されない。急増したイベントはサービスごとの SQS キューが弾力的なバッファとして受け止め、各サービスは自分のペースでキューから取り出して処理できるので要件1を満たす。また、1つのトピックを複数のキューが購読する構成では、各キューが同じ注文イベントを受け取るため、各サービスがすべての注文イベントを独立して処理でき、要件2も満たす。なお、急増を実際に溜めて吸収するのは SQS キューであり、SNS はイベントを各キューへ配信する役割を担う。この構成は要件3の手順の順序管理までは担わないため、Bと組み合わせる。

B：イベント駆動のワークフローは、複数のイベントをまとめて扱うのではなく、個々のイベントや実行フローの手順を管理するように設計される。AWS Step Functions のステートマシンは、1注文ごとに支払い確認の次に出荷指示を実行する順序を定義でき、実行単位で進行状況を確認できるため、要件3を満たす。一方、Step Functions 自体は受付のバッファや、複数サービスへのイベント配信の役割を持たない。要件1・2はAのSNS/SQSが担い、BはAと役割が重ならない補完関係にあるため、両方を採用しても矛盾しない。

C：同期呼び出しでは、受付側が各下流サービスの応答を待つため、下流の遅延が注文受付に直接影響する。これは現行システムで注文画面が応答しなくなっている原因と同じ構造であり、要件1を満たさない。受付と処理の間に SNS や SQS のような弾力的なバッファがないため、セール開始時の急増も吸収できない。さらに、受付が各サービスを順番に呼び出すため、各サービスが注文イベントを独立して受け取る要件2にも合わない。

D：夜間のバッチジョブは当日分の注文を一括で処理する方式であり、各サービスが個々の注文イベントを独立して受け取る要件2を満たさない。また、1注文ごとの手順の進行ではなく複数の注文をまとめて扱うため、各注文の進行状況を把握する要件3にも沿わない。サーバーレスのイベント駆動設計では、バッチ処理よりも小さな増分更新によるリアルタイム処理が好まれるが、この選択肢が誤りである決定的な理由は、上記の要件2・3を満たさない点にある。

E：全手順を単一のプロセスで実行する一体型アプリケーションでは、在庫・通知・請求を独立したイベントの受け手として分離できないため、要件2を満たさない。受付と後続処理が同じプロセス内で結び付くので、後続処理の遅れが受付に及び、急増を切り離して吸収できず要件1にも合わない。イベントベースの構成は一体型アプリケーションよりもスケーラビリティと冗長性を高めやすく、この点でも劣る。

学習のポイント：受付側を後続処理から切り離して急増を吸収し各サービスへ配るには SNS と SQS を使い、1注文単位の手順の順序管理と進行把握は AWS Step Functions に任せる、という役割の分担を見抜けるかどうか。

公式ドキュメント

• concepts-event-driven-architectures.html

正解は A である。Amazon Bedrock のオンデマンド呼び出しにより、常時稼働の基盤や処理能力の事前購入なしで、短期間に実現可能性と品質を検証できる。評価用モデルのスコアが閾値未満の出力だけを Amazon Augmented AI に回せば、少人数の査読者でも対応でき、査読画面や割り当ての独自開発も不要になる。査読結果は品質の定量評価に使える。検証後は AWS CDK のコンストラクトとして共有することで、複数部門が同じ構成を再利用できる。B は、Amazon Augmented AI と AWS CloudFormation による標準化は合っているが、プロビジョンドスループットが処理能力の事前購入にあたり、方針に反する。C は、固定費の回避と AWS Service Catalog による標準化は合っているが、査読機能の独自開発が必要で、検証期間内の工数が確保できない。D は、A とほぼ同じ構成だが、スコアに関係なく全件を査読に回すため、少人数で全件は査読できないという制約に反する。A は、短期の検証、固定費なし、閾値未満のみの査読、査読機能を独自開発しないこと、構成の再利用という5つの条件を同時に満たす。

A：Amazon Bedrock のオンデマンド呼び出しは、常時稼働の基盤や処理能力の事前購入を必要とせず、固定費を避ける方針に合う。評価用モデルのスコアで閾値未満の出力だけを Amazon Augmented AI に回せば、少人数の査読者でも対応できる。Amazon Augmented AI は査読画面、タスク割り当て、結果の出力を提供するため、独自開発の工数も不要になる。AWS Step Functions は生成、スコア付与、分岐、人間レビューまでの流れを一つのワークフローにまとめる。AWS CDK のコンストラクトとして共有すれば、複数部門が同じ構成を再利用でき、実装の分散も避けられる。検証期間の固定費、閾値未満のみの査読、査読機能の独自開発の回避、再利用性という条件をすべて満たす。

B：閾値未満のみを Amazon Augmented AI で査読する流れと、AWS CloudFormation テンプレートによる再利用の手段は要件に合う。しかしプロビジョンドスループットは、モデルの処理能力を事前に購入して確保する構成である。問題文はこの構成を使わない方針としており、固定費を避ける条件に反する。短期の検証では利用量も確定しておらず、この点で A より劣る。

C：オンデマンド呼び出しで固定費を避け、閾値未満だけを査読に回し、AWS Service Catalog の製品で構成を標準化する点は要件に合う。しかし査読画面、タスク割り当て、結果集計を独自に開発する必要がある。問題文は、検証期間内にそれらを独自開発する工数を確保できないと明示している。Amazon Augmented AI を使えば、この独自開発を避けられる。

D：固定費を避ける点、査読機能を独自開発しない点、AWS CDK による再利用の点は A と同じで、要件に合う。しかしスコアに関係なく全件を査読に回すため、少人数で全件の査読はできないという制約に反する。スコアによる絞り込みを使っておらず、評価用モデルを導入した意味も失われる。閾値未満の出力だけを人間レビューに回す必要がある。

学習のポイント：固定費を避けるオンデマンド呼び出しと、閾値未満のみを人間レビューに回す Amazon Augmented AI を組み合わせる。検証後は共有可能な部品にする。

公式ドキュメント

• ai-professional-01-domain1.md

正解は A。要件の 4 項目を、起点・終点・方向・通信条件に対応させた 5 つの分析に分けている。遮断を求める経路は TCP 443 と TCP 80 の両方を分析し、終点はすべて Reachability Analyzer が分析できるリソースである。Reachability Analyzer は静的な構成分析ツールなので、実際の通信を発生させずに確認でき、到達できない経路では遮断している構成要素が示される。B は要件 (4) の終点にオンプレミスの管理サーバーの IP アドレスを指定しているが、これは分析できるリソースの一覧に含まれず、VPN Gateway を終点にする必要がある。C は要件 (3) と逆の向き(pub-01 から iso-01)で分析しており、求められた経路を確認できない。D は要件 (2) が求める TCP 80 の遮断を分析しておらず、確認が不足している。

A：要件 (1)〜(4) の起点・終点・方向・通信条件をそのまま 5 つの分析に対応させている。要件 (2) が求める TCP 443 と TCP 80 の両方の遮断を別々に分析し、終点にはインターネットゲートウェイ、インスタンス、VPN Gateway という Reachability Analyzer が分析できるリソースだけを指定している。Reachability Analyzer は静的な構成分析を行うため、実際の通信を発生させずに確認でき、到達できない経路では遮断している構成要素が示されるので原因の特定にも使える。

B：前半 4 つの分析は要件に沿っているが、要件 (4) の終点が誤っている。Reachability Analyzer が分析できるのはインスタンス、インターネットゲートウェイ、ネットワークインターフェイス、Transit Gateway とそのアタッチメント、VPC エンドポイントサービス、VPC エンドポイント、VPC ピアリング接続、VPN Gateway であり、オンプレミス側サーバーの IP アドレスはこの一覧に含まれない。終点には要件のとおり VPN Gateway を指定する必要がある。

C：インターネットゲートウェイ向けの 3 つの分析と VPN Gateway 向けの分析は要件に合っているが、インスタンス間の分析の向きが逆になっている。要件 (3) が求めているのは iso-01 から pub-01 への経路であり、pub-01 から iso-01 への分析はその経路そのものを対象にしていないため、要件 (3) を確認したことにならない。

D：要件 (2) は iso-01 からインターネットゲートウェイへの TCP 443 と TCP 80 の両方の遮断を求めているが、この選択肢には TCP 80 の分析がない。TCP 443 が遮断されていても TCP 80 の遮断を確認したことにはならず、要件 (2) を満たしているかどうかを判断できない。

学習のポイント：要件が挙げる経路・方向・通信条件を漏れなく分析に対応させ、終点には Reachability Analyzer が分析できるリソース(オンプレミス側は VPN Gateway)を指定する点が鍵となる。

公式ドキュメント

• reachability-analyzer.html

問題文の条件は、(1)回答が提出された契約書の記載だけから導かれていること、(2)基本条項の初回期間に付帯条項の自動更新の条件をどう適用して結論に至ったかが回答文の中に順に書かれていること、の2つである。モデルが内部で演繹を行うだけでは(2)は満たされない。(1)は、入力された文章の情報に基づいて答えさせるコンテキストありの質問応答に対応する。(2)は、回答がどのように導かれたかを段階的に示させる思考の連鎖に対応する。Aは(1)には合うが、推論または論理的思考は一連の論理的な演繹を行うことを求めるタスクで、その経過を回答文に書くことまでは求められておらず、(2)を満たすとは言えないため誤りである。Bは(2)には合うが、コンテキストなしの質問応答は内部知識で答えさせるタスクであり(1)に反するため誤りである。Dはコンテキストなしの質問応答が(1)に反し、さらに推論または論理的思考が回答文への経過の記載を求めない点でも(2)を満たすとは言えないため誤りである。Cは(1)と(2)の両方に対応するため正解である。

A：コンテキストありの質問応答は、入力された文章の情報に基づいて質問に答えさせるタスクなので、問題(1)の解消には合う。しかし推論または論理的思考は、モデルが一連の論理的な演繹を行うことを求めるタスクとして位置づけられており、その経過を回答文に段階ごとに書くことは求められていない。問題文の条件は、演繹を行うことではなく、結論へ至る経過を回答文に順に示すことである。回答文に段階的な推論を示させるタスクは思考の連鎖(Chain-of-thought reasoning)であり、Aは問題(2)の条件を満たすとは言えないため誤りである。

B：思考の連鎖は、回答がどのように導かれたかを段階的に示させるタスクなので、問題(2)の解消には合う。しかしコンテキストなしの質問応答は、文脈や資料を与えずモデルの内部知識で質問に答えさせるタスクである。契約書の記載だけから回答を導くという条件に反し、契約書にない一般的な期間が使われる問題(1)を解消できないため、Bは誤りである。

C：コンテキストありの質問応答は、入力された文章の情報に基づいて質問に答えさせるタスクなので、契約書の記載だけから回答を導くという問題(1)の条件に合う。思考の連鎖は、回答がどのように導かれたかを段階的に示させるタスクなので、基本条項の初回期間に付帯条項の自動更新の条件をどう適用して結論になったかを回答文から追えるようにする問題(2)の条件に合う。2つの条件それぞれに対応するタスクを組み合わせたCが正解である。

D：コンテキストなしの質問応答は、文脈や資料を与えずモデルの内部知識で答えさせるタスクであり、契約書の記載だけから回答を導くという条件に反するため、問題(1)を解消できない。この点だけでDは誤りと判断できる。さらに推論または論理的思考も、一連の論理的な演繹を行うことを求めるタスクであって、その経過を回答文に書くことは求められていないため、問題(2)の条件を満たすとは言えない。

学習のポイント：『契約書の記載だけから答える』という要件がコンテキストありの質問応答に、『結論に至る経過を回答文に順に示す』という要件が、演繹を行わせるだけの推論または論理的思考ではなく思考の連鎖に対応することを、両方結び付けられるかが鍵である。

公式ドキュメント

• what-is-prompt-engineering.html