WEB問題集
解説
【正解: A】の理由
高可用性 (HA) はゾーン障害やハードウェア故障などの通常障害でサービスを止めない冗長化設計で、Availability Zone 分散や Load Balancer + 複数インスタンス構成が代表例です。Disaster Recovery (DR) はリージョン規模の広域災害時に別リージョンへ復旧する計画で、RTO / RPO の設定と Azure Site Recovery によるレプリケーションが核となります。HA は「継続させる仕組み」、DR は「復旧計画」と整理できます。
【他選択肢が違う理由】
- B. HA と DR は同義: 守備範囲もコストも異なり、同義ではありません。HA はリージョン内、DR はリージョン横断が基本です
- C. 説明が逆: HA = 同一リージョン冗長、DR = 別リージョン復旧が一般的な役割分担で、本選択肢は逆です
- D. HA 無料 / DR 有償: いずれも構成によりコストが発生し、HA と DR で課金体系が分かれているわけではありません
解説
【正解: A】の理由
SaaS は完成済みのアプリケーションをそのままサービスとして利用する形態で、Microsoft 365 (Outlook / Teams / SharePoint / Word / Excel) が代表例です。サーバ / OS / ミドルウェア / アプリ本体の保守はすべて Microsoft が担い、顧客はブラウザやクライアントから利用するだけです。顧客責任は ID / アクセス管理、データ分類、デバイス保護に限定されます。
【他選択肢が違う理由】
- B. Azure Virtual Machines: IaaS の代表で、ゲスト OS / アプリ / データすべてを顧客が管理します
- C. Azure Kubernetes Service: マネージド Kubernetes (PaaS) で、コントロール プレーンは Microsoft 管理ですがアプリ自体は顧客が用意するため SaaS ではありません
- D. Azure SQL Database: マネージド DB (PaaS) で、サーバ管理は Microsoft ですが完成アプリではないため SaaS ではありません
解説
【正解: B】の理由
パブリック クラウドの最大の特長は、初期投資 (CapEx) なしに必要な時に必要なだけリソースを従量課金 (OpEx) で調達できる点です。需要が増えれば数分でスケール アウトし、ピーク後はスケール インして課金もそれに追従するため、ビジネスの俊敏性とコスト最適化を同時に実現できます。グローバル リーチと最新のマネージド サービス活用も大きな付加価値です。
【他選択肢が違う理由】
- A. 物理ハードウェアの所有: パブリック クラウドではハードウェアは Microsoft 所有で、顧客は利用権のみを取得します
- C. 規制要件を回避: 規制は「回避」ではなく「準拠」が原則で、Sovereign / Region / コンプライアンス機能で要件を満たします
- D. 必ず安くなる保証: ワークロード次第ではオンプレが安いケースもあり、TCO Calculator での比較が前提となります
解説
【正解: A】の理由
プライベート クラウドは自社所有のデータセンターまたは専有領域上に構築するクラウドで、ハードウェアとソフトウェア スタックを完全に自社管理下に置けます。金融 / 防衛 / 医療など物理ロケーションや管理権限の完全コントロールが要求されるワークロードに最適です。Azure Stack HCI や VMware による構築が代表例で、ハイブリッド構成で Azure と組み合わせる選択肢もあります。
【他選択肢が違う理由】
- B. 初期投資ゼロで世界展開: パブリック クラウドの典型シナリオで、プライベートは初期投資が大きい構成です
- C. ピーク時のみスケール アウト: パブリック クラウドの弾力性の領域で、プライベートでは物理キャパシティの上限があります
- D. グローバル CDN: Azure Front Door / CDN などパブリック クラウドのエッジ サービスが該当する用途です
解説
【正解: A】の理由
マルチクラウド戦略は Azure / AWS / Google Cloud など複数パブリック クラウドを同時に利用する戦略で、主目的はベンダー ロックイン回避と各クラウドの得意分野の活用です。AI は Azure、データ分析は Google Cloud、既存ワークロードは AWS のように適材適所で割り振れます。リージョン障害時の事業継続性を別クラウドへ拡張する手段にもなり、調達交渉でも有利になります。
【他選択肢が違う理由】
- B. コストを必ず下げる: 複数クラウドの統合運用は管理コストが増えるため、必ず安くなるとは限りません
- C. 管理を単純化: 真逆で、複数の管理ツール / 課金体系 / IAM を統合する必要があり管理は複雑化します
- D. ハイブリッドと同義: ハイブリッドは「オンプレ + パブリック」、マルチクラウドは「複数パブリック」で対象が異なります
解説
【正解: A】の理由
Reliability はシステムが障害から回復し稼働を継続できる能力を指す広い設計原則で、HA と復旧性を包含します。Fault Tolerance はその実装手段の一つで、コンポーネント単位の障害 (ディスク故障、電源喪失、NIC エラーなど) を吸収してサービスを止めずに継続させる設計です。RAID、ECC メモリ、冗長電源、Availability Zone 跨ぎ配置などが具体例となります。
【他選択肢が違う理由】
- B. 対義語: Reliability と Fault Tolerance は同じ方向の概念で、対義ではありません
- C. 性能 / コスト指標: どちらも障害対応の概念で、性能やコストを表す指標ではありません
- D. 同義: スコープが異なり、Reliability は広い目標、Fault Tolerance は具体的な実装パターンです
解説
【正解: A】の理由
Economies of Scale (規模の経済) はクラウド ビジネス モデルの核となる概念です。Microsoft や AWS は世界で数十万から数百万台規模のサーバを運用しており、ハードウェア集中購買、独自設計の電源 / 冷却 / ネットワーク機器、運用自動化の規模効果により、個社オンプレ構築より圧倒的に低い単位コストを実現します。この差を価格に転嫁することで、顧客は自前構築より安く高品質なインフラを利用できます。
【他選択肢が違う理由】
- B. 税制優遇でほぼゼロ: 税制優遇は一部地域に限られ、コストがほぼゼロになることはありません。本質要因は規模の経済です
- C. ソフトウェアが完全に無料: Microsoft 自社製品の OS ライセンスは保有していますが、サードパーティ製品は通常通り課金されます
- D. 手作業で組み立て: クラウド事業者は徹底した自動化と標準化された生産ラインを採用しており、手作業ではありません
解説
【正解: A, B, C】の理由
Agility (俊敏性) はクラウドの中核的な利点で、ビジネスの変化対応速度を劇的に高めます。新サービスのプロビジョニングは Azure Portal / CLI / Bicep で数分単位で完了し、オンプレで数週間から数ヶ月かかった調達 / 設置を 100 分の 1 以下に短縮できます。オートスケールにより需要変化に即座に追従でき、機会損失とアイドル コストを同時に回避できます。この調達速度と弾力性により、新製品 / 機能の市場投入時間 (Time to Market) も大幅に短縮できます。
【他選択肢が違う理由】
- D. 物理ハードウェアの選定 / 組立: クラウドではハードウェアは Microsoft が管理し顧客は触れません。物理層の選定はリードタイムを増やすため俊敏性とは逆方向です
- E. すべて無料: クラウドは従量課金 / Reservations / Spot などの課金モデルがあり、すべて無料ではありません
解説
【正解: A, B】の理由
Predictability はクラウドの利点の一つで、コスト面とパフォーマンス面の 2 軸で評価されます。Reservations / Savings Plan により対象リソースのコストを予約期間中に固定でき、予算編成の精度が向上します。オートスケールは需要変動下でも応答時間 / TPS を SLA 範囲内に保ち、ユーザー体験を一定に保てます。Cost Management の予算 / アラートや Action Group と組み合わせれば、上振れリスクや性能低下も早期に検知できます。
【他選択肢が違う理由】
- C. すべて Spot VM でコスト確定: Spot は最大 90% 安価ですが Azure 側で eviction される可能性があり、むしろ予測しづらい状態となります。中断可能な開発 / バッチ向けで本番には不適です
- D. 物理ハードウェアを顧客が交換: クラウドでは Microsoft 管理であり顧客は触れません。Predictability とは無関係です
- E. 命名規則を揃える: 運用品質を上げる施策ですが Predictability の例ではありません
以下の各ステートメントについて、Governance (ガバナンス) と Manageability (管理容易性) の観点から正しい場合は「はい」、誤っている場合は「いいえ」を選択してください。
注: 正解 1 つにつき 1 点が与えられます。
| ステートメント | はい | いいえ |
|---|---|---|
Governance はリソース作成時の制約 (許可リージョン、必須タグ等) を強制し、組織標準への準拠を担保する活動である。 正しい記述です。Azure Policy がリソース作成時の制約を Deny / Audit 効果で強制し、Initiative で複数ポリシーを束ねて統制パッケージとして適用できます。Management Group 階層で割り当てると配下の全 Subscription に継承され、全社ガバナンスを実現できます。 | ||
Manageability の「Management of the cloud」はクラウド リソース自体の管理 (作成 / 設定 / 削除) を、「Management in the cloud」は IaC (ARM Template / Bicep) や Azure Automation を使ってクラウドで自動化的に管理することを指す。 正しい区別です。前者はクラウドの「リソース管理」、後者はクラウドを「使った管理」(IaC / 自動化 / オーケストレーション) で、Manageability の 2 側面を分けて捉えるとガバナンスと運用の議論が整理しやすくなります。 | ||
Tags はリソースに対する物理的な制約 (削除禁止等) を強制する仕組みである。 誤った記述です。Tags はキー / 値のメタデータでリソースを分類するラベルであり、物理的な制約は強制しません。削除禁止は Resource Lock の CanNotDelete、作成時制約は Azure Policy が担当し、Tags はそれらの評価条件として使われます。 |