WEB問題集
解説
【正解: A】の理由
TCO Calculator はオンプレミスのサーバ / ストレージ / ネットワーク / ライセンス / 電力 / 運用人件費を入力し、同等ワークロードを Azure に移行した場合の総保有コストを 3〜5 年スパンで比較するツールです。CapEx から OpEx への転換効果を定量化でき、経営層向けの移行提案資料として広く活用されています。
【他選択肢が違う理由】
- B. 未デプロイ Azure 構成の月額見積: これは Pricing Calculator (料金計算ツール) の役割で、TCO Calculator とは別ツールです
- C. リアルタイム コスト アラート: アラートや予算管理は Azure Cost Management の機能で、TCO Calculator には含まれません
- D. リザーブド インスタンスの割引率可視化: Reservations の推奨や割引可視化は Cost Management の領域で、TCO の範囲外です
解説
【正解: A】の理由
消費ベース (Pay-as-you-go) 料金モデルは実際に利用した時間 / 容量 / トランザクション数だけが課金対象となり、未使用時はほぼゼロ課金になる点が最大の利点です。需要に応じてスケールすると課金も連動するため、CapEx 中心のオンプレ調達と比べてピーク外時間の無駄を大幅に削減でき、変動の大きいワークロードに最適です。
【他選択肢が違う理由】
- B. 常に固定金額で利用できる安定性: 消費ベースは利用量で変動するため固定ではありません。固定が必要なら Reservations を併用します
- C. ライセンス料が完全に無料: Microsoft 製品の一部が含まれることはありますが、すべてが無料になるわけではありません
- D. ハードウェアを所有できる: クラウドではハードウェアは Microsoft が所有し、顧客は利用権のみを得ます
解説
【正解: A】の理由
弾力性 (Elasticity) は需要変化に追従して自動的にリソースを増減できる能力です。スケーラビリティが拡張可能性を表す広い概念であるのに対し、弾力性は自動性と双方向性 (上下動可) を加えた動的特性を指します。VMSS / Functions / App Service のオートスケールが典型例で、ピーク時のみ増強し通常時に縮小することでコスト効率も向上します。
【他選択肢が違う理由】
- B. 物理ハードウェアを顧客が選定 / 増設: 物理層は Microsoft 管理で、弾力性の本質である自動スケールとは無関係です
- C. 同一インスタンスに垂直に CPU / メモリを追加: これは Scale Up (垂直スケーリング) で、弾力性が指す主機能ではありません
- D. 常にリソースを最大容量で保持し続ける: 弾力性とは逆方向の発想で、コスト効率も悪化します
解説
【判定: いいえ】の理由
IaaS では Guest OS / ミドルウェア / ランタイムまで顧客責任となり、要件「OS 管理コスト最小化」「アプリ コード集中」と正面衝突します。VM パッチ適用、Web サーバ チューニング、マルチリージョン手動デプロイ、スケール ルール自作などの運用負荷が積み上がり、「地域分散による低レイテンシ配信」と「短納期での市場投入」の双方が困難になります。
【「はい」が違う理由】
IaaS は OS フル制御 / 特定ライセンス制約 / レガシー アプリの Lift & Shift 用途であり、グリーンフィールドの Web アプリ開発には不向きです。本シナリオの 3 要件は PaaS (App Service + Front Door) またはサーバーレス (Functions / Container Apps) が最小工数で満たせます。
解説
【判定: はい】の理由
Azure App Service は OS / ランタイム / ミドルウェア / パッチを Microsoft が完全管理する PaaS で、「OS 管理最小化」「コード集中」要件を直接満たします。Azure Front Door と組み合わせると 100+ エッジ拠点で低レイテンシ配信が実現でき「地域分散」も担保されます。GitHub Actions / Azure DevOps からのデプロイは数分で完了し短納期にも適合します。
【「いいえ」が違う理由】
トラフィック増加時も App Service オートスケールが追従し、Application Insights で可観測性も確保できます。Premium V3 プランではゾーン冗長で 99.99% SLA も実現でき、本シナリオの 3 要件すべてを最小の運用負荷で同時に満たせる最適解となります。
解説
【判定: いいえ】の理由
SaaS は完成済みアプリを利用する形態で、「新規 Web アプリを開発」シナリオとは前提が異なります。Power Apps はローコード / ノーコードの業務アプリ作成ツールで、専用フル機能 Web アプリの構築には UI / データ モデル / 連携先で制約があり、要件「アプリ コード開発に集中」と矛盾します。経験豊富なエンジニアの能力を活かしきれません。
【「はい」が違う理由】
SaaS は M365 / Dynamics 365 / Salesforce など既製業務システム利用、Power Apps は開発スキル不要の社内ワークフロー アプリ作成、と用途が異なります。本問の「コード重視 + 短納期 + 地域分散」要件には PaaS (App Service + Front Door) が最適解となります。
解説
【正解: A】の理由
Active-Active は全インスタンスが同時に稼働しトラフィックを分散処理するため、リソース効率が高く 1 台障害時も他で継続できます。Active-Passive は通常時に Active 側のみ処理し、Passive 側は Hot Standby として障害時に引き継ぐ構成です。Azure では SQL DB Always On や VPN Gateway の active-active / active-standby SKU で具体的に選択できます。
【他選択肢が違う理由】
- B. 両者は同義で互換的に使用できる: 稼働効率と切替挙動が明確に異なり、設計上区別されます
- C. Active-Active はオンプレ専用、Active-Passive はクラウド専用: どちらもクラウド / オンプレ双方で用いられる設計パターンです
- D. Active-Passive はオートスケールを意味する: オートスケールは需要追従のスケール アウト / インの仕組みで別概念です
解説
【正解: A】の理由
水平スケーリング (Scale Out / In) はインスタンス台数を増減する方式で、VMSS や App Service のインスタンス数調整が典型例です。負荷分散と可用性向上が同時に実現でき、クラウドの弾力性と親和性が高い手法です。垂直スケーリング (Scale Up / Down) は同一インスタンスの CPU / RAM / ディスクを変更する方式で、再起動を伴うことが多くクラウドでは水平を優先するのがベスト プラクティスです。
【他選択肢が違う理由】
- B. 両者は同義であり置換可能: 異なる戦略と用途を持ち、互換ではありません
- C. 水平はオンプレ専用、垂直はクラウド専用: どちらもクラウド / オンプレ両方で利用されます
- D. 垂直スケーリングはディスク容量のみ増加できる: 垂直は CPU / メモリ / ディスクすべてを対象とし、ディスクに限定されません
以下の各ステートメントについて、クラウドの代表的な利点に関する記述として正しい場合は「はい」、誤っている場合は「いいえ」を選択してください。
注: 正解 1 つにつき 1 点が与えられます。
| ステートメント | はい | いいえ |
|---|---|---|
クラウドの「弾力性」は需要変化に応じてリソースを自動的に増減させる能力を指す。 弾力性 (Elasticity) はクラウドの中核的利点で、需要に追従し自動でスケール アウト / インします。VMSS / App Service / Functions のオートスケールが典型実装で、ピーク時のみリソースを増やし通常時に縮小して、課金も連動して変動します。 | ||
クラウドの「グローバル リーチ」によって、世界各地のリージョンへ即時にデプロイし低レイテンシ配信ができる。 Azure は世界 60+ リージョンを持ち、各拠点へ数分でデプロイできます。Front Door / CDN をエッジ活用すれば世界中のユーザーへ低レイテンシ配信ができ、自社データセンター不要でグローバル展開を実現できます。 | ||
クラウドの「信頼性」は必ずシステムの 100% 可用性を保証する。 Reliability は障害から回復し稼働継続する能力ですが 100% 可用性は保証しません。Azure の SLA は構成に応じて 99.9〜99.99% で、100% は物理法則上不可能です。要件に応じた構成と SLA 値の理解が必要です。 |
次の各ステートメントを完成させるために、責任主体の正しい選択肢を選んでください。同じ選択肢は 2 回使用できません。
| ステートメント | 選択 |
|---|---|
IaaS において、Guest OS のパッチ適用責任は [ ] である。 IaaS では Guest OS のパッチ適用は常に顧客責任です。Microsoft はホスト OS / ハイパーバイザーまでを管理し、Guest OS 以上は顧客が Update Manager や独自エージェントで維持します。これが IaaS 運用負荷の中心です。 | |
SaaS / PaaS / IaaS のいずれにおいても、物理データセンターの建物セキュリティ責任は [ ] である。 物理データセンター / ハードウェア / 物理ネットワーク機器の責任は全モデルで常に Microsoft 側です。顧客は ISO 27001 / SOC / PCI-DSS 等の認定を Service Trust Portal で確認でき、物理層には関与しません。 | |
Microsoft Entra ID 上のユーザー / グループ / アクセス権の管理責任は責任共有モデルにおいて [ ] である。 ID とアクセス権の管理は全モデル共通で常に顧客責任です。M365 / Dynamics 365 (SaaS) でも Entra ID 上のユーザー作成 / MFA / Conditional Access は顧客が実施します。Microsoft は機能提供のみを担います。 |