ある企業がAWSアカウントのプロビジョニングプロセスを全面刷新しようとしています。現状の課題：アカウント作成から利用開始まで3〜5営業日かかる、ITチームが手動でCloudTrail設定・デフォルトVPC削除・IAMロール作成を実施、本番アカウントの申請承認はメールチェーンで行われCTO承認待ちで数日かかることがある、タグ付け基準やコスト管理が統一されていない、四半期監査で40%のアカウントにコンプライアンス違反が発見されている。新要件：（1）非本番アカウントは申請から2時間以内、本番アカウントは承認込みで4時間以内にプロビジョニング完了、（2）全アカウントに自動適用するベースライン設定：CloudTrail有効化・デフォルトVPC削除・AWS Config有効化・Security Hub有効化・コスト予算アラート（開発環境$500/月、本番環境$5,000/月）、（3）本番アカウントは指定承認者の承認を必須とし、承認なしにプロビジョニングできないよう技術的に強制する、（4）アカウント作成時にcost-center・team・environmentタグを必須入力とする、（5）コンプライアンス制御を作成時だけでなく継続的に適用する、（6）すべてのカスタマイズはコードで管理するGitOps（Gitリポジトリを唯一の信頼できる情報源として使用するインフラ管理手法）アプローチを採用する。これらの要件を最も包括的かつ効率的に満たす設計として最も適切なものはどれですか？
AFTはTerraformによるGitOps管理を実現し、グローバル・アカウント固有カスタマイズパイプラインでプロビジョニング後の設定を完全自動化できます。AFTのアカウントリクエストパイプライン内のCodePipeline手動承認アクション（Manual Approval Action）がSNS通知と組み合わさることで、本番アカウント申請の技術的強制承認を実現します（AWS Service Catalogには標準の承認ワークフロー機能は存在しないため、AFTパイプラインのCodePipeline手動承認ステップを活用します）。Control Towerの必須ガードレールは継続的なコンプライアンス適用を保証します。 選択肢B の StackSets展開に時間がかかり2時間要件の達成が困難でGitOps管理も弱いです。 選択肢C の AnsibleとJiraによる手動承認ステップが残り4時間要件と技術的強制承認の実現が困難です。 選択肢D の Service CatalogとStackSetsで部分的に自動化できますが、GitOps管理がAFTより弱く包括性に劣ります。