Azure Fundamentals（AZ-900）の練習問題（当サイト作成）

正解：ウ（自社のデータと、従業員のアカウントやアクセスの管理）　当サイトの解答

• ア × 誤り SaaS でも利用者が基盤のハードウェアを持つと考えた

  物理ホストは、SaaS ではサービス提供側（Microsoft）の責任です。

• イ × 誤り SaaS でも OS の更新は利用者の作業だと考えた

  SaaS では OS の管理も Microsoft 側が担います。

• ウ ○ 正しい

  データと ID・アクセス管理は、どのサービス形態でも利用者側に残ります。

• エ × 誤り 物理的な安全管理を利用者の作業に含めた

  データセンターの物理的な管理は、クラウドでは Microsoft 側の責任です。

正解：ア（同じ構成のインスタンスを、需要に合わせて増やしたり減らしたりする。）　当サイトの解答

• ア ○ 正しい

  台数を増減する水平スケーリングは、Azure で自動化の仕組みが用意されています。既存のインスタンスは動き続けられます。

• イ × 誤り サイズを大きくすれば停止なく自動で調整できると考えた

  サイズを変える垂直スケーリングは、再配置のために一時的に使えなくなることがあり、自動化は一般的ではありません。

• ウ × 誤り ピークに合わせて固定で用意するのがクラウドの使い方だと考えた

  常に最大を用意すると、使わない時間帯も費用がかかります。需要に合わせて増減させるのがクラウドの利点です。

• エ × 誤り 負荷の増減への対応と障害時の切り替えを取り違えた

  別リージョンへの複製は障害への備えで、日々の需要の増減に合わせる方法ではありません。

正解：エ（Azure App Service を使う。）　当サイトの解答

• ア × 誤り 仮想マシンでも OS の運用は任せられると考えた

  仮想マシンは IaaS で、OS やアプリの管理は利用者が行います。

• イ × 誤り Microsoft 提供のイメージを選べば、OS の運用も Microsoft が担うと考えた

  OS イメージを選ぶのは利用者で、仮想マシンは IaaS です。OS の更新などの管理は利用者が行います。

• ウ × 誤り 自動化すれば OS の管理責任がなくなると考えた

  スクリプトで自動化しても、OS の更新は利用者の責任のままです。

• エ ○ 正しい

  App Service は PaaS に分類されます。公式の概要では、基盤を管理せずに Web アプリを動かせるプラットフォームと説明されています。利用者はアプリのコードに集中できます。

正解：イ（その仮想マシンは止まる可能性があり、備えるには別のゾーンにも同じ役割のリソースを置く。）　当サイトの解答

• ア × 誤り ゾーンを指定しても自動で別ゾーンに切り替わると考えた

  ゾーンを指定したリソースでは、別ゾーンへの切り替えは利用者の責任です。

• イ ○ 正しい

  単一ゾーンに置いたリソースは、そのゾーンの障害の影響を受けます。複数ゾーンに分けて置く設計が必要です。

• ウ × 誤り ゾーンは分離されていないと考えた

  各ゾーンは電源・冷却・ネットワークが独立しているため、1つのゾーンの障害はほかのゾーンに及びにくい設計です。

• エ × 誤り ゾーン障害とリージョン障害の備えを取り違えた

  ゾーンを指定したリソースの切り替えは利用者の責任と説明されています。ゾーン障害でペアのリージョンへ自動で移る、という説明はありません。

正解：ウ（ゾーン冗長ストレージ（ZRS））　当サイトの解答

• ア × 誤り コピーが複数あれば、データセンターの障害にも耐えると考えた

  LRS は1つのデータセンター内で複製するため、データセンター全体の障害には耐えられません。

• イ × 誤り geo 冗長なら、リージョン外に出さない要件も満たすと考えた

  GRS は別のリージョンにもコピーするため、リージョンの外に出さない要件に合いません。

• ウ ○ 正しい

  ZRS は、同じリージョン内の3つ以上のゾーンにコピーします。ゾーンが1つ使えなくなっても読み書きを続けられ、データをリージョン内にとどめられます。

• エ × 誤り 読み取りができれば、障害時も書き込みを続けられると考えた

  RA-GRS も別リージョンへコピーします。リージョンの外に出さない要件に合いません。

正解：ア（Azure Functions）　当サイトの解答

• ア ○ 正しい

  Azure Functions はサーバーレスで、ファイルのアップロードなどのイベントをきっかけにコードを実行できます。

• イ × 誤り 常時動く仮想マシンに処理を置くのが基本だと考えた

  仮想マシンでも実行はできますが、OS を含むサーバーの管理が必要になり、要件に合いません。

• ウ × 誤り 台数が自動で増減するなら、サーバーの管理も不要だと考えた

  スケールセットは、仮想マシンのインスタンスを自動で増減させるサービスです。仮想マシンを前提とするため、サーバーの管理はしたくないという条件に合いません。

• エ × 誤り 仮想の環境を提供するサービスなら、処理の実行にも使えると考えた

  Azure Virtual Desktop は仮想デスクトップを提供するサービスで、イベントで処理を実行するものではありません。

正解：エ（グループの場所はメタデータの保存先を指すだけで、中のリソースは別のリージョンにも置ける。）　当サイトの解答

• ア × 誤り グループの場所が、中のリソースの場所も縛ると考えた

  グループの場所はメタデータの保存先です。グループ内のリソースは、別のリージョンに作れます。

• イ × 誤り グループの場所が課金の単位だと考えた

  グループの場所が指定するのはメタデータの保存先です。料金の請求先リージョンを決めるものとは説明されていません。

• ウ × 誤り メタデータとデータを取り違えた

  リソースグループが保存するのはリソースに関するメタデータです。データそのものは各リソースが持ちます。

• エ ○ 正しい

  グループの場所はメタデータの保存先で、グループ内のリソースは異なるリージョンに置けます。

正解：イ（Azure Policy）　当サイトの解答

• ア × 誤り リージョンの制限も、利用者の権限で決めるものと考えた

  RBAC は利用者が実行できる操作を管理するもので、リソースの作成場所を規則で制限するものではありません。

• イ ○ 正しい

  Azure Policy はリソースのプロパティを規則と照らして評価します。許可する場所を定める組み込みの定義があります。

• ウ × 誤り ロックで作成場所も制限できると考えた

  ロックは、リソースの削除や変更を防ぐ機能です。作成できる場所は制限しません。

• エ × 誤り 推奨を出すサービスなら、作成場所の制限もできると考えた

  Azure Advisor は構成や使用状況を分析して推奨を示すサービスです。リソースの作成場所を規則で制限するものではありません。

正解：ア（リソースの設定を変更できるが、削除はできない。）　当サイトの解答

• ア ○ 正しい

  CanNotDelete は、読み取りと変更は許し、削除だけを防ぎます。

• イ × 誤り 削除できないロックは、変更も止めると考えた

  変更も止めるのは、ReadOnly のロックです。CanNotDelete では変更できます。

• ウ × 誤り ロールの権限がロックより優先されると考えた

  ロックは利用者の権限より優先され、すべての利用者とロールに適用されます。

• エ × 誤り リソースを管理できるロールがあれば、ロックも外せると考えた

  ロックの作成・削除には Microsoft.Authorization 配下の権限が必要です。組み込みロールの一覧（built-in-roles）では、Contributor はこの権限の書き込み・削除が NotActions に入っています。そのため、ロックを解除できません。

正解：ウ（設定した宛先に通知が送られる。リソースは動き続ける。）　当サイトの解答

• ア × 誤り 予算には、利用を止める機能があると考えた

  予算を超えても、リソースは影響を受けず、利用は止まりません。

• イ × 誤り 予算が上限として働くと考えた

  予算は、新しいリソースの作成を制限するものではありません。

• ウ ○ 正しい

  予算のしきい値を超えると通知が出ますが、リソースには影響せず、利用は止まりません。

• エ × 誤り 予算の超過がサブスクリプションの停止につながると考えた

  予算は支出を追って知らせる仕組みで、サブスクリプションを無効にはしません。