WEB問題集
解説
【正解: A】の理由
Azure Migrate はオンプレ → Azure 移行プロジェクトの統合ハブで、Discovery / Assessment / 移行実行 / 進捗管理を一元提供します。Site Recovery / Database Migration Service / App Service Migration Assistant を内包し、依存関係マッピングや TCO 試算も無料で利用できます。
【他選択肢が違う理由】
- B. 物理サーバの郵送: 物理郵送は Data Box の領域で、Azure Migrate はソフトウェア ベースの移行ハブです
- C. RDB のみ: VM / Web アプリ / DB / VDI など多様なワークロードに対応し、DB 専用ではありません
- D. 廃止サービス: 現役の主力サービスで Microsoft 推奨の移行管理ツールです
解説
【正解: A】の理由
Azure Arc はオンプレや AWS / Google Cloud のサーバ / Kubernetes / SQL を Azure 管理面に投影し、Azure Policy / Monitor / Defender / GitOps / Sentinel を統一適用するハイブリッド + マルチクラウド管理プラットフォームです。Azure 外のリソースに Azure と同じガバナンスを拡張します。
【他選択肢が違う理由】
- B. 物理弧装置: Arc はソフトウェア プラットフォームで、物理装置の販売ではありません
- C. ロード バランサ: L7 負荷分散は Application Gateway / Front Door の領域で、Arc は管理面拡張サービスです
- D. オンプレ専用: 実際には AWS / Google Cloud にも対応するマルチクラウド製品です
解説
【正解: A】の理由
Azure Stack ファミリは顧客のデータセンターやエッジ拠点で Azure サービスを動作させるオンプレ製品群です。Hub は完全な Azure 互換環境、HCI は仮想化ハイパーコンバージド インフラ、Edge は AI / IoT エッジ向けと用途別に提供されます。
【他選択肢が違う理由】
- B. クラウド上の Azure 全般: Azure Stack は顧客サイトで動作するオンプレ製品で、パブリック クラウド全般を指しません
- C. ケースのブランド: 物理筐体ではなく Azure サービスを動かす製品ファミリです
- D. 廃止: 現役の戦略的ハイブリッド製品ファミリで継続提供されています
解説
【判定: はい】の理由
Rehost (Lift & Shift) はオンプレ VM を Azure Site Recovery や Azure Migrate でレプリケートし、Azure VM として起動する戦略で、コード変更ゼロ + 短期間 + EOL OS 対応の 3 要件を満たします。Windows Server 2008 SP2 / 2012 R2 は Azure 上で無料の拡張セキュリティ更新 ESU が提供されます。
【「いいえ」が違う理由】
6R 戦略の中で Rehost は最速かつ最低リスクで、100 台規模の短期移行に最も適合します。移行後に Refactor / Rearchitect を段階的に進める「Migrate first, modernize later」が現代の王道で、移行後は Reservations や Hybrid Benefit でコスト最適化も可能です。
解説
【判定: いいえ】の理由
Refactor (PaaS 化) は OS / ランタイム / 構成の互換性確認やテストに 1 アプリあたり数週間〜数ヶ月かかり、100 台を 3 ヶ月で完了させるのは非現実的です。さらに Windows Server 2008 SP2 のレガシー業務システムは PaaS への移行が極めて困難で、コード変更最小化の要件にも反します。
【「はい」が違う理由】
短期大量移行 + EOL OS を含むシナリオでは Rehost が最適解です。Refactor は移行後の継続的モダナイゼーション フェーズでビジネス価値の高いアプリを順次選定して進めるアプローチが現実的で、CAF でも「Migrate first → Optimize later」が推奨されます。
解説
【判定: いいえ】の理由
Rebuild はマイクロサービスやサーバーレスへの完全書き直しで、1 アプリあたり数ヶ月〜数年かかります。100 台を 3 ヶ月で書き直すのは数十人体制でも非現実的で、コード変更最小化の要件と完全に矛盾します。レガシー業務システムは未文書化仕様も多く、再現リスクも高くなります。
【「はい」が違う理由】
Rebuild はビジネス価値が極めて高く長期投資が正当化されるコア システムや、クラウドネイティブ機能が必須のシナリオに限定すべきです。本問の 100 台短期移行では Rehost が最適で、書き直しは移行後に優先度評価して段階的に進めるべきアプローチです。
解説
【正解: A】の理由
Hybrid Identity は Microsoft Entra Connect でオンプレ Active Directory のユーザーやグループを Microsoft Entra ID に同期し、Password Hash Sync / Pass-Through Authentication / Federation のいずれかを構成する仕組みです。Seamless SSO と組み合わせ統合認証体験を実現します。
【他選択肢が違う理由】
- B. 物理サーバ共有: ID 管理ではなくハードウェア共有の話で、ハイブリッド ID とは無関係です
- C. 別 Microsoft アカウント: 個別アカウントの利用はハイブリッド統合ではなく、シングル サインオンも実現できません
- D. サポートされない: 実際には Microsoft の主力ハイブリッド機能として正式提供されています
解説
【正解: A, B, C】の理由
Azure 移行プロジェクトで使われる主要サービスは Azure Migrate (統合移行ハブ)、Azure Site Recovery (VM レプリケーションと DR)、Azure Database Migration Service (SQL / Oracle / MySQL / PostgreSQL / MongoDB の最小ダウンタイム移行) の 3 つです。これらは Azure Migrate ハブから連携して呼び出せます。
【他選択肢が違う理由】
- D. Excel: 表計算ソフトで Azure 移行サービスではありません
- E. Word: 文書作成ソフトで Azure 移行サービスではありません
解説
【正解: A, B】の理由
ハイブリッド / マルチクラウド管理の中核は Azure Arc と Azure Stack ファミリです。Arc は Azure の管理機能を Azure 外のリソースに拡張し、Stack は Azure サービスそのものをオンプレで動作させます。両者は補完関係で、組み合わせて利用されます。
【他選択肢が違う理由】
- C. Excel: クラウド サービスではなく Office 製品で、ハイブリッド管理機能を持ちません
- D. Azure DNS: 名前解決の専門サービスでハイブリッド管理の範疇ではありません
- E. Azure CDN: グローバル コンテンツ配信サービスで、ハイブリッド管理とは別カテゴリです
Microsoft Cloud Adoption Framework の標準的なクラウド移行プロセスの順序に並べ替えてください。
- Discover (発見): Azure Migrate でオンプレ サーバ / アプリ / DB を自動検出、依存関係分析
- Assess (評価): Azure 移行レディネス、適合 VM サイズ推奨、TCO 試算、リスク評価
- Migrate (移行): ASR / DMS / 適切なツールで Rehost / Refactor / Rearchitect を実施
- Optimize (最適化): Cost Management / Advisor / Defender で運用最適化、PaaS 化推進
解説
【正しい順序: Discover → Assess → Migrate → Optimize】の理由
Microsoft Cloud Adoption Framework の Migrate メソドロジーで定められた標準プロセスです。Discover で Azure Migrate アプライアンスがオンプレの VMware / Hyper-V / 物理サーバ / DB を自動検出し、Application Dependency Mapping で通信依存を可視化します。Assess で Right-Sizing / 移行レディネス / TCO 試算 / 6R 戦略推奨を実施し、Migrate で ASR / DMS 等の適切なツールを選定してパイロット → 段階的本番移行を行います。Optimize では Cost Management / Advisor / Defender / Reservations / Hybrid Benefit で運用最適化と段階的 PaaS 化を継続します。