AZ-305のサンプル問題（本番形式・解説付き）

AZ-305（Microsoft・Azure Solutions Architect Expert）の出題形式を、実際の問題で確かめられます。ここに掲載する5問は、無料の会員登録で解ける模試第1回（50問）の冒頭から抜粋したオリジナル問題です。当サイトは全650問を本番CBT準拠の形式で収録しており、この5問はそのごく一部にあたります。

設問1

IoTデバイスから送信されるテレメトリをEvent Hubsで受信する設計で、同一デバイスから送られたイベントは、そのデバイス内では送信順序を保って処理したい(異なるデバイス間の順序は問わない)。最も適した設計はどれか。

イベントを単一のパーティションにまとめて格納し、パーティションを複数に分散させたスケールアウトは行わない
Event Hubsのコンシューマーグループをデバイスごとに作成し、デバイス単位で順序を保って読み取る
パーティションキーを指定せず、Event Hubsによるパーティションへの自動的な振り分けに任せる
デバイスIDをパーティションキーとして使用し、同一デバイスのイベントが同一パーティションに格納されるようにする（正解）

解説

Event Hubsでは、パーティションキーに基づいてイベントが特定のパーティションへ割り当てられ、同一パーティション内では送信順序が保たれます。デバイスIDをパーティションキーとすることで、同一デバイスのイベント順序を保ちながら、全体としては複数パーティションに分散させてスループットを確保できます。単一のパーティションにまとめると、順序は保てても分散させたスケールアウトができません。コンシューマーグループは読み手を分ける仕組みで、格納先のパーティションは変わりません。パーティションキーを指定しない自動的な振り分けでは、同じデバイスのイベントが別々のパーティションに入ります。

他の選択肢が誤りである理由

「イベントを単一のパーティションにまとめて格納し、パーティションを複数に分散させたスケールアウトは行わない」単一パーティションにまとめると順序は保たれますが、パーティションを分散できずスループットのスケールアウトができなくなります。
「Event Hubsのコンシューマーグループをデバイスごとに作成し、デバイス単位で順序を保って読み取る」コンシューマーグループは同じイベントを別々の読み手が独立に読むための仕組みで、イベントがどのパーティションに入るかは変わらず、同一デバイスのイベントの順序は保てません。
「パーティションキーを指定せず、Event Hubsによるパーティションへの自動的な振り分けに任せる」パーティションキーを指定しないと、同一デバイスのイベントが複数のパーティションに分散して格納され、デバイス内での順序を保てなくなります。

設問2

ストレージアカウントの保管時暗号化に使う鍵を保持するキーコンテナーを新規に設計している。侵害された管理者アカウントによってコンテナーごと消去された場合でも、一定の期間は鍵を取り戻せる状態にしたい。運用チームからは、その保護は誰の権限でも解除できない形にしてほしいという要望が出ている。最も適切な設計はどれか。

キーコンテナーの論理削除を有効なままにし、保持の期間を最長の日数へ設定したうえで、鍵のバックアップを別のサブスクリプションへ日次で取得するよう構成する
キーコンテナーの論理削除を有効なままにしたうえで消去保護を有効にし、保持の期間を作成のときに定めて回復できる期間を確保するよう構成する（正解）
キーコンテナーのアクセス許可のモデルをアクセスポリシーからAzure RBACへ切り替え、消去の操作を含むロールを運用の担当者の誰にも割り当てないよう構成する
キーコンテナーの診断設定でデータプレーンの操作のログを収集し、消去の操作を検知したら運用チームへアラートを通知するよう構成する

解説

新しく作るキーコンテナーでは論理削除が既定で有効になっており、有効にした後は無効にできません。消去保護は既定では無効の任意の設定で、論理削除が有効な場合にのみ有効にできます。消去保護を有効にすると、削除された状態のコンテナーや鍵は保持の期間が過ぎるまで消去できず、Microsoftを含め誰も無効にも上書きにもできません。保持の期間は7日から90日の範囲で作成のときにだけ設定できます。論理削除の保持を最長の日数にして別のサブスクリプションへ日次でバックアップする案は、消去の操作そのものを止められません。アクセス許可のモデルをAzure RBACへ切り替えても、ロールは同じ権限を持つ相手が付け直せます。診断設定でデータプレーンの操作を収集してアラートを通知しても、検知するだけで鍵は取り戻せません。

他の選択肢が誤りである理由

「キーコンテナーの論理削除を有効なままにし、保持の期間を最長の日数へ設定したうえで、鍵のバックアップを別のサブスクリプションへ日次で取得するよう構成する」論理削除だけでは消去の操作そのものを止められないため、侵害された管理者アカウントにその場で消去され、回復できる期間を確保できません。
「キーコンテナーのアクセス許可のモデルをアクセスポリシーからAzure RBACへ切り替え、消去の操作を含むロールを運用の担当者の誰にも割り当てないよう構成する」ロールの割り当ては同じ権限を持つ相手がいつでも付け直せるため、侵害された管理者アカウントに対する歯止めとしては働きません。
「キーコンテナーの診断設定でデータプレーンの操作のログを収集し、消去の操作を検知したら運用チームへアラートを通知するよう構成する」監査のログは起きたことを後から追える形にするだけで、消去されたキーコンテナーや鍵そのものを取り戻す手段にはなりません。

設問3

Azure Backupにおける「バックアップポリシー」が定義する内容として最も適切なものはどれか。

ストレージアカウントの冗長性オプション
仮想ネットワークのルーティングルールと、バックアップ通信が経由するネットワーク経路の指定
BLOBのアクセス層を自動移行させるルールと、Hot・Cool間で層を切り替えるタイミングの条件
バックアップを取得するスケジュール（頻度・時刻）と、各バックアップポイントの保持期間（正解）

解説

バックアップポリシーは、バックアップをいつ・どれくらいの頻度で取得するか（日次・週次など）と、取得した各バックアップポイントをどれだけの期間保持するか（日次・週次・月次・年次の保持設定）を定義する設定です。ストレージアカウントの冗長性オプションはストレージアカウント自体の設定であり、バックアップポリシーが定義する内容ではありません（ただしRecovery Services vault自体にも別途冗長性設定があります）。仮想ネットワークのルーティングルールはネットワーク設定の話であり、バックアップポリシーの役割ではありません。アクセス層の自動移行ルールはBLOBストレージのライフサイクル管理ポリシーの役割であり、Azure Backupのバックアップポリシーとは別の機能です。

他の選択肢が誤りである理由

「ストレージアカウントの冗長性オプション」ストレージアカウントの冗長性オプションはストレージアカウント自体の設定であり、バックアップポリシーが定義する内容ではありません（ただしRecovery Services vault自体にも別途冗長性設定があります）。
「仮想ネットワークのルーティングルールと、バックアップ通信が経由するネットワーク経路の指定」仮想ネットワークのルーティングルールはネットワーク設定の話であり、バックアップポリシーの役割ではありません。
「BLOBのアクセス層を自動移行させるルールと、Hot・Cool間で層を切り替えるタイミングの条件」アクセス層の自動移行ルールはBLOBストレージのライフサイクル管理ポリシーの役割であり、Azure Backupのバックアップポリシーとは別の機能です。

設問4

検査画像を、ローカル冗長ストレージで構成した汎用v2のストレージアカウントに保存している。参照は最初の30日にほぼ集中し、その後は監査要求が来たときだけである。運用チームが「作成から60日後にアーカイブアクセス層へ移し、90日後に削除する」というライフサイクル管理ポリシーを提案してきた。この提案に対する評価として最も適切なものはどれか。

アーカイブアクセス層の最小保存期間は180日のため、残り150日分の早期削除料金がかかることになる（正解）
早期削除の対象になる30日を過ぎてから移す設計になっているため、追加の課金は生じずに費用を削減できることになる
アーカイブアクセス層へ移した時点で読み取りができなくなるため、監査要求が来ても取り出せないことになる
アーカイブアクセス層への移行はライフサイクル管理ポリシーからは指定できないため、この提案は構成として成立しないことになる

解説

移行日と最小保存期間の差が、そのまま無駄な課金になるという判断です。汎用v2アカウントでは推奨される最小の保存期間がクールで30日、コールドで90日、アーカイブで180日と定められており、その日数が過ぎる前に削除・上書き・別の層への変更を行うと、残り日数分の早期削除料金が日割りで課金されます。この提案では60日でアーカイブへ移して90日で削除するので、アーカイブに置く期間は30日にしかならず、180日との差である150日分が課金されます。判断の軸は移行元ではなく移行先の層の最小保存期間であり、そこを取り違えると階層化が費用の削減になりません。なおアーカイブ層を使えるアカウントの冗長性はローカル冗長・geo冗長・読み取りアクセスgeo冗長に限られます。

他の選択肢が誤りである理由

「早期削除の対象になる30日を過ぎてから移す設計になっているため、追加の課金は生じずに費用を削減できることになる」30日はクール層の最小保存期間で、ここで効くのは移行先であるアーカイブ層の側の日数のため、移行日が30日を過ぎていることは追加の課金を避ける根拠になりません。
「アーカイブアクセス層へ移した時点で読み取りができなくなるため、監査要求が来ても取り出せないことになる」アーカイブ層のBLOBはオンライン層へリハイドレートすれば読み取れ、優先度の指定によって完了までの時間も選べるため、取り出せないことにはなりません。
「アーカイブアクセス層への移行はライフサイクル管理ポリシーからは指定できないため、この提案は構成として成立しないことになる」ライフサイクル管理ポリシーは条件に合ったBLOBをアーカイブ層へ移す用途で使える仕組みで、指定できないのはアーカイブ層からオンライン層へ戻す向きの操作になります。

設問5

通常はプライマリリージョンのみでトラフィックを処理し、プライマリが利用不可になった場合にのみセカンダリリージョンへフェールオーバーしたい。最も適したTraffic Managerのルーティング方法はどれか。

加重(Weighted)
パフォーマンス(Performance)
地理(Geographic)
優先度(Priority)（正解）

解説

優先度(Priority)ルーティングは、プライマリエンドポイントへトラフィックを集約し、正常性監視でプライマリが利用不可と判断された場合にのみ次点のエンドポイントへフェールオーバーする、アクティブ/パッシブ構成に最適な方式です。加重ルーティングは複数エンドポイントへ比率を指定して振り分ける方式で、通常時は特定リージョンのみを使うアクティブ/パッシブ構成には適しません。パフォーマンスルーティングはユーザーに最も近い(低レイテンシな)エンドポイントへ振り分ける方式で、フェールオーバー専用の優先度制御とは目的が異なります。地理ルーティングはユーザーの地理的位置に基づいてエンドポイントを固定的に振り分ける方式で、プライマリ/セカンダリのフェールオーバー制御とは異なります。

他の選択肢が誤りである理由

「加重(Weighted)」加重ルーティングは複数エンドポイントへ比率を指定して振り分ける方式で、通常時は特定リージョンのみを使うアクティブ/パッシブ構成には適しません。
「パフォーマンス(Performance)」パフォーマンスルーティングはユーザーに最も近い(低レイテンシな)エンドポイントへ振り分ける方式で、フェールオーバー専用の優先度制御とは目的が異なります。
「地理(Geographic)」地理ルーティングはユーザーの地理的位置に基づいてエンドポイントを固定的に振り分ける方式で、プライマリ/セカンダリのフェールオーバー制御とは異なります。

続きは、会員登録なしでそのまま50問解けます。採点と解説つきで、上と同じ本物の問題です。

登録なしで50問解く

← AZ-305 の資格ページへ