DP300-CS02#2
【Case Study】Contoso 社 Azure SQL Database 新規構築
【背景】
Contoso 社は EC サイト の新規構築で OLTP データベース を Azure SQL Database で運用する計画 です。本番リリース は 3 ヶ月 後で 想定 アクセス は ピーク時 5,000 同時 ユーザー / 平均 1,500 同時 ユーザー、DB 容量 は 初年度 500 GB、年間 200 GB 増加 見込み です。
【既存環境】
Microsoft Entra ID テナント、Azure Subscription 1 つ、East US リージョン に Hub VNet 構成済み (10.0.0.0/16)、PCI DSS 準拠要件 あり、SQL Server SA 付きライセンス を既存保有。
【要件】
- 業務時間 (9-18 時) はピーク負荷 5,000 ユーザー対応
- 夜間 (18-9 時) は低負荷、コスト最小化したい
- 東日本 リージョン に DR 構成
- PCI DSS 準拠で TDE + Always Encrypted + 監査ログ必須
- Bicep + Azure DevOps で IaC + CI/CD 構築
- バックアップ自動化 + 失敗 通知 必須
【質問 2/2】
本シナリオで バックアップ自動化 + 失敗 通知 を実現する最適な構成はどれですか?
解説
【正解: A】の理由
Azure SQL Database のバックアップは Microsoft 管理 で 自動 取得 (PITR デフォルト 7 日 + 最大 35 日 延長可能) され LTR で 月次 / 年次 を最大 10 年保管 することで PCI DSS の長期 保管 要件 を 満たせます。Azure Monitor Action Group で バックアップ失敗 通知 を Email / Teams Webhook で 自動 通知 し 異常 検知 が可能 となります。
【他選択肢が違う理由】
- B: 手動 BACPAC は運用負荷 過大 + PITR には及びません。
- C: バックアップ 不要 は コンプライアンス 違反 です。
- D: SQL Server Agent は Azure SQL Database では 利用不可 です。

コメント