はじめに
このたび、VCP-VCF 9.0 Architect
VMware Certified Professional - VMware Cloud Foundation Architect (2V0-13.25)を、
Passすることに成功しました。
投稿時点で、ネット上であまり本試験に関する記事を見かけなかったため、
せっかくなので自身が実施した取り組みをヒントとして残せればと思います。
自身のポジション的には基盤の管理・運用することはほとんどなく、
プリフェーズにてお客さんニーズを要件やスコープに落とし込む機会が多いため、
AdministratorよりArchitect試験が向いてそうだし、面白そうだと思い挑みました。
一応、過去にDCVとNCVを取得しているのですが、
vSphereやNSXというパッケージ単位が失われて久しい点、
また、VCF9.0となりいろいろ様変わりしていると思うため、
最新アップデートのキャッチアップ目的で挑戦した側面もあったりします。
ロードマップ
ブループリントのインプット
まずは試験のExam Study Guideをインプットし試験範囲の構造を理解しました。
Exam Study Guide
最近は世の中も便利になったもので、文明の利器をふんだんに使って取り組みました。
まず、NotebookLMを用いてpdfを読み込ませ、日本語の翻訳とマインドマップ生成、不明点のQ&Aに対応できるように準備しました。
NotebookLM
pdfファイルを取り込むと、以下のようになります。
ドキュメントのソースをもとにAIが回答してくれます。
不明点を聞いたり壁打ちしたりと一人で黙々とするより圧倒的に効率が良かったです。
NotebookLMのマインドマップを自動的に生成してくれる機能がアツいです。
全体構造を把握したり、深掘りしたい部分にあたりをつけてAIと問答できます。
ソースをもとにした回答はNotebookLMが優秀ですが、
Web上の情報含めていい感じにまとめたい際はPerplaxityを併用してました。
ブループリントを紐解くと以下のセクションが範囲とわかりました。
試験セクション概要
試験は5つの標準セクションに分かれ、
Section 4と5にテスト可能な目標はありません。主な焦点は設計スキルです。
| セクション | ウェイト（推定） | ステータス |
|---|---|---|
| Section 1: IT Architectures, Technologies, Standards | 高い | 含む |
| Section 2: VMware Products and Solutions | 中程度 | 含む |
| Section 3: Plan and Design the VMware Solution | 最高 | 含む |
| Section 4: Install, Configure, Administrate | - | なし |
| Section 5: Troubleshoot and Optimize | - | なし |
Section 1: IT Architectures (主目標)
ビジネス/技術要件の区別、コンセプチュアル/論理/物理設計の違い、要件/前提/制約/リスクの識別、AMPRS（Availability, Manageability, Performance, Recoverability, Security）の考慮、リスク軽減戦略、設計決定の文書化と検証戦略。
Section 2: VMware Products (主目標)
シナリオに基づくVCFアーキテクチャオプションの区別（例: Fleetトポロジー）。
Section 3: Plan and Design (詳細目標多数)
ビジネス要件収集とコンセプチュアルモデル作成。
VCF論理/物理設計
（Fleet, Network, Management Domain, Workload Domain, Automation, Operations）。
可用性（AZ内/跨ぎ）、管理性（ライフサイクル、スケーラビリティ、容量）、パフォーマンス、回復性（BCDR）、セキュリティ、ワークロード移行、消費戦略（テナント、セルフサービス）、監視戦略。
技術ドキュメントのインプット
試験のブループリントを理解したら、お次は技術ドキュメント（TechDocs）をインプットしました。
VMware Cloud Foundation 9.0
こちらも例に漏れずpdfがトップにあるので、それをNotebookLMで読み込みましょう。
pdfで9000ページ超あるのでまともに端から端まで眺めると一生終わりません。
まずはVCF9.0の構造やアーキテクトとして取り扱う要素などの全体を掴みます。
ほどほどに全体感が掴めてきたら、
問題集を解きながら個別具体を理解していきましょう。
問題集でアウトプット
個別具体の理解と並行してUdemyで良さげな問題集を解きまくりましょう。
pdfやテキストで問題集をNotebookLMに登録して自分なりにカスタムしても良いかも。
問題で分からない部分はNotebookLMに聞けば公式ドキュメント準拠で答えてくれます。
あとは目新しい問題がなくなるまでやりこんで、
大体初見の問題が見当たらなくなったと実感したらテストセンターへGOです。
HoLでアウトプット
Hands on Labs、私はまっったく手をつけませんでした。
コンポネント構造のイメージを掴むのに併用してもいいかも。
アーキテクト試験なのでUIの項目やコマンドまで覚えるのは刺さらない気がします。
試験でチャレンジ
15:45試験開始で予約し、3連休を使って詰め込みました。
試験当日に粘ってそのままの状態で突入するのがいつもの流れです。
試験の結果
361/500
やったぜ。
なお、試験は現時点で英語受験のみ。(2026/01/12)
私は英語分からないので単語の雰囲気で回答してなんとか乗り切りました。()
受かればいいんです、受かれば。
勉強時間は20時間前後だと思います。
年末年始に気まぐれでお勉強しつつ、直前の3連休で詰め込みました。
過去vSphereやNSX、VCFの設計構築した経験あるのも手伝い最小限の学習で抑えられたと思います。
なので、初見の方は更に勉強時間が必要だと思われます。
参考
以下、全体感を掴むのと何を深掘りするかの参考になれば。
それぞれの要素の不明点は分かるようになるまでAIと問答して学習しましょう。
このようなツリー構造やテーブルでの出力はPerplaxityが得意なので、
NotebookLMで確実なソースをもとに抽出した要素をコピーし、
そのままPerplaxityに貼り付けて「ツリーにしてっ」と言えば出てきます。
Perplaxity
VCF 9.0 Private Cloudコンポネント構造ツリー
├── VCF Fleet (フリート: 管理スコープ最上位)
│ ├── Fleet-level Management Components
│ │ ├── VCF Operations: フリート監視/FinOps/ライセンス一元管理
│ │ ├── VCF Automation: セルフサービス/マルチテナントガバナンス
│ │ └── VCF Identity Broker: Fleet-wide SSO仲介
│ └── VCF Instance (実装単位: 複数可)
│ ├── Management Domain (必須: 各VCF Instanceに1つ)
│ │ ├── 管理コンポーネント: vCenter, NSX Manager, SDDC Manager
│ │ ├── vSphere Cluster (管理用): Fleet/Instanceコンポーネント実行
│ │ └── Principal Storage: vSAN/NFS/FC共有ストレージ
│ └── Workload Domain (オプション: 各VCF Instanceに最大24)
│ ├── 専用コンポーネント: Workload用vCenter (NSX共有可)
│ ├── vSphere Cluster (業務用)
│ │ └── vSphere Supervisor (K8s対応)
│ │ └── vSphere Namespaces (論理境界)
│ │ └── Workloads: VM/VKS/vSphere Pods
│ └── ネットワーク: NSX Edge/Transit Gateway/VPC
VCF 9.0 要素構成ツリー
├── 1. 仮想インフラストラクチャ (Core Infrastructure)
│ ├── vSphere (ESXi/vCenter): VM/コンテナ/AIワークロード実行
│ ├── vSAN: ESA/OSA共有ストレージプール
│ └── NSX: VPC/分散ファイアウォール/SDN
├── 2. 管理・運用スイート (Management & Operations)
│ ├── VCF Operations (Aria Operations)
│ │ ├── Fleet Management: ライセンス/ライフサイクル/証明書管理
│ │ ├── Operations Management: Health監視/診断
│ │ └── FinOps & Capacity: TCO/容量/Green Score
│ ├── VCF Automation (Aria Automation)
│ │ ├── Cloud Services: VM/K8s/ネットワークプロビジョニング
│ │ ├── Provider/Org Management: マルチテナント
│ │ └── Workload Orchestration: 自動化オーケストレータ
│ ├── SDDC Manager: デプロイ/パッチ/アップグレード
│ └── VCF Installer: 自動デプロイアプライアンス
├── 3. 拡張運用サービス (Extended Services)
│ ├── VCF Operations for Logs: ログ収集/分析
│ ├── VCF Operations for Networks: ネットワーク可視化/T/S
│ └── VCF Operations HCX: 移行/vMotion/ネットワーク拡張
├── 4. モダンアプリケーションプラットフォーム (Modern App Platform)
│ ├── vSphere Supervisor: K8s対応VM/コンテナ統合
│ │ └── vSphere Kubernetes Service (VKS): K8sクラスター管理
│ └── VCF Identity Broker: SSO仲介
└── 5. アドオン・アドバンスドサービス (Advanced Services)
├── Private AI: AIインフラ支援
├── VMware Live Recovery: DR/ランサムウェア復旧
└── VMware Data Services Manager: DBセルフサービス (PostgreSQL/MySQL)
VCF 9.0 要件トレーサビリティツリー
├── 1. ビジネス要件と目標 (Design Profile)
│ ├── 消費モデル (Consumption): Automationセルフサービス, SV K8s, vCenter直接管理
│ ├── 物理サイト構成: 単一サイト, 単一リージョン内複数サイト, 複数リージョン
│ ├── 可用性 (Availability): 単一ホスト/ネットワーク/ラック/AZ障害許容
│ ├── 分離 (Isolation): ハイパーバイザー/ネットワーク/物理クラスター/テナント間
│ ├── 回復性 (Recoverability): バックアップ/リストア, DR対応
│ └── 拡張性 (Expansion): ホスト/クラスター/ドメイン/インスタンス追加
├── 2. 設計の決定とモデル選択 (Design Selections)
│ ├── 運用モデル (VCF Operations): Simple, HA, Continuous Availability(CA)
│ ├── 自動化モデル (VCF Automation): Simple, HA
│ ├── インフラモデル:
│ │ ├── クラスター: Single-Rack, Multi-Rack(L2/L3), Stretched Cluster
│ │ ├── ストレージ: vSAN ESA, vSAN OSA, 分離型
│ │ └── ネットワーク: NSX VPC, NSX Segment, VLAN
│ └── ID/認証モデル (SSO): Embedded, Appliance, Fleet-wide, Instance-level
└── 3. 技術的設計要素 (Design Elements: Requirements & Recommendations)
├── VCF Automation 要件:
│ ├── VCF-AUTO-REQD-HA-001: 3ノードクラスター必須
│ └── VCF-AUTO-REQD-SIM-003: vSphere HA保護
├── VCF Operations 要件:
│ ├── VCF-OPS-REQD-HA-004: DRSアンチアフィニティルール
│ └── VCF-OPS-REQD-LCM-001: ライフサイクル管理
├── vSphere クラスター要件:
│ ├── VCF-CLS-REQD-CFG-002: 最小ホスト数維持
│ ├── VCF-CLS-RCMD-CFG-001: アドミッションコントロール(推奨)
│ └── VCF-CLS-REQD-CFG-006: Stretched用ホストグループ
└── ネットワーク/物理インフラ要件:
├── VCF-NET-REQD-LAT-001: クラスター内遅延<10ms
├── VCF-NET-REQD-SWT-002: MTU 1700+(Overlay)
└── VCF-NET-REQD-NTP-001: 内部NTP同期
VCF 9.0 設計・導入要素の構造化ツリー
├── 1. 要件 (Requirements: 達成必須目標)
│ ├── ビジネス要件 (Business)
│ │ ├── TCO削減・運用オーバーヘッド最小化
│ │ ├── コンプライアンス（データ主権・地政学リスク対応）
│ │ └── セルフサービスIaaS（開発者向け迅速プロビジョニング）
│ └── 技術的設計要件 (Design)
│ ├── 最小ホスト数: Management Domain ≥4ノード（HA/自動再構築）
│ ├── 冗長性: Operations/Automation 3ノードHAクラスター
│ ├── ネットワーク: クラスター内<10msレイテンシ、MTU≥1700
│ └── セキュリティ: FIPS 140-2/3モジュール強制有効
├── 2. 前提条件 (Assumptions/Prerequisites: 設計成立基礎)
│ ├── インフラ前提
│ │ ├── ハードウェア: VCF BOM/HCL準拠（サーバー/NIC/ストレージ）
│ │ └── 外部サービス: NTP（内部推奨）+正引き/逆引きDNS完備
│ └── ライセンス前提
│ ├── VCF Operations一元管理（180日使用状況報告必須）
│ └── 新ライセンス: CPUコア（VCF）+TiB（vSAN）
├── 3. 制約事項 (Constraints: 設計自由度制限)
│ ├── 環境制約
│ │ ├── エアギャップ: オフラインデポ+VCFダウンロードツール必須
│ │ └── マルチサイト: Stretched Clusterサイト間<5ms RTT（vSAN）
│ └── プラットフォーム制約
│ ├── CPUベンダー固定: 単一クラスター内Intel/AMD混在不可
│ ├── FIPSデフォルト有効（無効化不可）
│ └── vCenter:1に対しNSXインスタンス1つのみ
└── 4. リスクと影響 (Risks/Implications: 選択副作用)
├── 可用性リスク
│ ├── SPOF: 単一障害点 ホスト障害→サービス停止
│ └── RPO/RTO: 地域間非同期レプリケーションのデータ損失
├── パフォーマンスリスク
│ ├── リソース競合: 統合構成時のManagement/Workload争奪
│ └── ネットワーク飽和: UDT高速転送→管理NW帯域圧迫
└── 運用リスク
├── 管理オーバーヘッド: Workload Domain分割（最大24）増大
└── 更新制限: BOM準拠のため個別コンポーネント更新不可
| 項目 | 要件トレーサビリティツリー | 設計・導入要素ツリー |
|---|---|---|
| 視点 | 垂直（Why→How→What） | 水平（What by Category） |
| 流れ | ビジネス目標→設計選択→技術要件 | 要件/前提/制約/リスクの4分割 |
| 目的 | 設計判断の正当化・説明 | 全要素の網羅性確保・リスク可視化 |
- 水平ツリー ← 環境調査・制約特定
↓ 全要素インベントリ化 - 垂直ツリー ← 優先順位付け・論理構築
↓ ステークホルダー説明用 - 両ツリー統合 ← 設計文書化（AMPRSトレーサビリティ）
VCF 9.0 AMPRS トレーサビリティツリー
├── 1. Availability (可用性)
│ ├── クラスター選択 → Stretched Cluster(AZ障害耐性), Multi-Rack (ラック障害分離)
│ ├── 管理HA → Operations/Automation/NSX Manager 3ノードクラスター
│ └── 機能 → vSphere HA (ホスト障害), NIC Teaming (NWパス障害)
├── 2. Manageability (運用性)
│ ├── 一元管理 → VCF Operations (Single Pane of Glass, Config Drift検知)
│ ├── セルフサービス → VCF Automation (Cloud Assemblyカタログ)
│ └── LCM → vSphere Lifecycle Manager (イメージベース更新)
├── 3. Performance (性能)
│ ├── ストレージ → vSAN ESA (NVMe最適化シングルティア)
│ ├── ネットワーク → EDP (データパス高速化), Traffic Separation
│ └── アクセラレーション → GPU Reservations (AI/ML最適化)
├── 4. Recoverability (回復性)
│ ├── DR戦略 → VMware Live Recovery (RTO/RPO), Cross-Regionレプリケーション
│ └── バックアップ → File-Based (コンポーネント設定), vSAN Native Snapshot
└── 5. Security (セキュリティ)
├── ID管理 → VCF Identity Broker (SSO), RBAC (最小権限)
├── データ保護 → FIPS 140-2/3強制有効, NSX Micro-segmentation
└── 運用保護 → Certificate/Pass Rotation自動化
| 役割 | 構造化ツリー（性質） | トレーサビリティ（論理） | AMPRS（品質） |
|---|---|---|---|
| 焦点 | 設計材料の棚卸し | 決定プロセスの可視化 | 品質基準の評価 |
| 情報 | 要件/前提/制約/リスク | 目標→選択→仕様の流れ | A/M/P/R/S影響度 |
| 質問 | 「何を考慮？」 | 「なぜその選択？」 | 「どの特性向上？」 |
Phase 1: 調査 → 構造化ツリー
↓ 全要素抽出（制約:FIPS有効、リスク:SPOF）
Phase 2: 論理構築 → トレーサビリティ
↓ TCO削減→vSAN ESA選択→MTU1700要件
Phase 3: 品質評価 → AMPRS
↓ 3ノードHA(A↑,P↓,M↑トレードオフ)
Phase 4: 検証 → 全ツリー整合性確認
VKS (vSphere Kubernetes Service)
├──1. クラスター基盤 (Cluster Architecture)
│ ├── vSphere Supervisor: K8s制御プレーン基盤
│ ├── Control Plane: Simple(1ノード) / HA(3ノード)
│ ├── Networking:
│ │ ├── NSX VPC: セルフサービスNW/隔離/サブネット
│ │ ├── Antrea CNI: 標準コンテナネットワーク
│ │ └── Load Balancer: NSX/Avi/Foundation LB
│ └── Storage:
│ ├── vSphere-pv-csi: vSphere PV as Kubernetes PVC
│ └── vSAN Data Protection: ネイティブスナップショット
├── 2. ソフトウェアパッケージ (Software Packages)
│ ├── Built-in: Pinniped(認証), Antrea(CNI), kapp-controller, metrics-server
│ └── Optional Add-ons: Harbor(レジストリ),
Istio(サービスメッシュ), Prometheus/Grafana, Velero(バックアップ)
├── 3. 管理・ポリシー (Cluster Management)
│ ├── VKS Cluster Management: 階層/リソース管理
│ ├── Governance Policies:
│ │ ├── Pod Security: 実行権限/セキュリティ制約
│ │ ├── Quota: CPU/メモリ/ストレージ制限
│ │ ├── Image Registry: 許可イメージ制限
│ │ └── Mutation: リソース自動変換
│ └── Supervisor Auto-Attach: 自動接続管理
└── 4. 運用・保護 (Operations)
├── Backup/Restore: Velero + CSIボリューム
├── VCF Consumption CLI: kubectl統合VCF CLI
└── Lifecycle: VKr(vSphere Kubernetes Release)更新
vSphere Supervisor レイヤ構造 (Workload Domain vSphere Cluster内)
├── Layer 1: 物理基盤 (Physical Infrastructure)
│ ├── ESXi Hosts: Spherelet (kubelet相当)が展開、vSphere Pod実行
│ ├── vSAN Storage: ESA/OSA、CSIドライバ対応
│ └── Physical Network: MTU1700+、NSXオーバレイ対応
├── Layer 2: Supervisor Control Plane (制御プレーン)
│ ├── Supervisor Control VM (3ノードHA): API Server, Controller, Scheduler
│ └── vCenter統合: vSphere API ↔ Kubernetes API変換
├── Layer 3: ネットワークオーバレイ (NSX統合)
│ ├── T0/T1 Gateway: Namespace毎独立ルーティング
│ ├── NSX Edge Cluster: Load Balancer (NSX/Avi)
│ └── Antrea CNI: Pod間通信 (Geneveカプセル化)
├── Layer 4: Namespace境界 (論理隔離)
│ ├── Resource Pool: CPU/メモリクォータ
│ ├── Storage Policy: vSphere-pv-csi PVC割り当て
│ └── Network Policy: T1ゲートウェイ配下隔離
└── Layer 5: ワークロード実行 (Workloads)
├── vSphere Pods: ESXiネイティブ実行 (CRXコンテナランタイム)
├── VM Workloads: 従来VM並列実行
└── VKS Guest Clusters: Namespace内でCluster API展開
| レイヤ | 役割 | VCF設計影響 |
|---|---|---|
| L1物理 | Spherelet展開 | BOM/HCL必須 |
| L2制御 | K8s→vSphere変換 | 3ノードHA必須 |
| L3 NW | NSXオーバーレイ | MTU1700+制約 |
| L4 Namespace | テナント隔離 | Policyガバナンス |
| L5実行 | VM+Pod統合 | リソース競合 |
NSX (VCF 9.0 Networking)
├── 1. 管理・制御プレーン (Management & Control Plane)
│ ├── NSX Manager: 中央管理 (Simple:1ノード / HA:3ノード)
│ └── NSX Global Manager: Federation（マルチVCF/拠点）
├── 2. 仮想ネットワーク (Logical Networking)
│ ├── Logical Switching: Geneveオーバレイ/VLAN
│ ├── Logical Routing:
│ │ ├── T0 Gateway: North-South（物理NW接続）
│ │ └── T1 Gateway: East-West（テナント内）
│ └── VPC Transit Gateway (TGW):
│ ├── Centralized TGW: Edge集中処理
│ └── Distributed TGW: ESXi分散高性能
├── 3. マルチテナント (Tenancy & Consumption)
│ ├── NSX Projects: 論理分離（セキュリティ/NWオブジェクト）
│ ├── Virtual Private Cloud (VPC): セルフサービスNW
│ └── VPC Connectivity/Service Profiles: 外部接続/サービス定義
├── 4. データプレーン・Edge (Edge Infrastructure)
│ ├── NSX Edge Nodes: 集中サービス（Routing/NAT/VPN）
│ │ ├── Virtual Appliance: VMスケールアップ
│ │ └── Bare-Metal: 高スループット
│ └── NSX Edge Clusters: リソースプール
├── 5. セキュリティ (Security Services)
│ ├── vDefend Firewall:
│ │ ├── Distributed FW (DFW): VM vNIC単位
│ │ └── Gateway FW: T0/T1境界防御
│ ├── Advanced Threat Prevention (ATP)
│ ├── Micro-segmentation: East-West隔離
│ └── VPN: IPsec/L2拠点間接続
└── 6. 運用・パフォーマンス (Operations)
├── Enhanced Data Path (EDP): 3x高速パケット処理
├── IPFIX/SPAN: フロー収集/分析
└── ODS: 自動診断ランブック
まとめ
ユーザの発言を、要件・制約・リスクのどれで解釈するか
この内容はAMPRSのどれに分類されるか
物理設計、論理設計として記載すべき内容はなにか
現状のリスクは何か
このような状況の際、Architectとしてどのようなソリューションを選ぶか
可用性が高いのは...DRを考えると...レイテンシを抑えた実装は...
などなど、
ユーザの発言をVMのフレームワークに則り定義付けられること
各コンポネントの関連性や役割のイメージ、特に重要な要素は深く理解できているか、
普遍的なArchitectとしての考え方の腕試しにもちょうど良い試験だと思いました。
ArchitectとAdministratorどちらにするか迷う場合、
first stepとして、
事業会社やSESの人はAdministratorでオペレーションを学び、
SIerの中の人はArchitectで要件定義や設計要素を学ぶのがマッチしてるのではないでしょうか。
皆さんもこれを機に是非チャレンジしてみてください！！
記事が好評なら他の試験のレポートも書いていこうかなと思います。