設問と背景
エンタープライズ顧客は、自動化ポリシーの変更が多数のリソースに誤った影響を与えることを懸念しています。変更が送信される前に、潜在的な許可（allows）、拒否（denials）、影響を受けるオブジェクトをSaaS側でプレビュー表示すべきかどうかを判断してください。
これはプロダクトのトレードオフに関する質問であり、OPA、Terraform、または特定のワークフローエンジンの使用を求めるものではありません。プレビューと本番実行の違い、ユーザーの信頼、権限管理、段階的なロールアウトに焦点を当ててください。
面接官の評価ポイント
ユーザー課題の理解
「誰が影響を受けるか？」と「最終的な実行結果が完全に一致することが保証されているか？」を明確に区別し、高リスクなポリシーやロールを特定できているか。
精度の境界
古いシミュレーション結果を保証として提示することなく、プレビューで使用されるスナップショット、外部ファクト、評価時点を正確に定義できているか。
プロダクトスコープ
すべてのルールに対して完璧なシミュレーションを約束するのではなく、初期のポリシ一部分セット、オブジェクト規模、差分（diff）表示、承認フロー、ロールバック経路を適切に選択できているか。
価値の検証
意図しない影響の発生率、アンドゥ（取り消し）率、プレビューの利用率、実行との乖離（ダイバージェンス）、サポートチケット数によって価値を検証できているか。
確認すべき明確化の質問
- 大規模または不可逆的な影響を引き起こす可能性のあるポリシーはどれか？
- 顧客が必要としているのは、オブジェクト一覧、サマリー、差分表示、それともコスト見積もりか？
- プレビューはライブの外部状態を使用する必要があるか、それともスナップショットで十分か？
- 変更には複数人の承認者、ロールバック機能、または監査ログの保持が必要か？
- 結果によって機密性の高いリソース名やテナント間の情報が漏洩する可能性はないか？
- 許容されるレイテンシーとオブジェクト数の上限はどの程度か？
30秒回答フレームワーク
「まずは、影響が不可視であるために高リスク顧客が変更を躊躇したり誤送信したりしているかを検証します。第1弾のリリースでは、ロジックが明確で列挙可能なルールを対象とし、タイムスタンプ付きスナップショットから追加、削除、許可、拒否、不明な状態を返します。プレビューは実行結果を保証しないことを明示し、送信時に再評価してドリフトを表示します。実行時と同じ権限を再利用し、監査可能で、大規模スコープに対しては非同期で実行します。プレビューの採用率、実行との乖離、アンドゥ率、インシデント数に基づいて適用範囲の拡大を判断します。」
ステップごとの詳細解説
ステップ 1：課題とセグメントの検証
管理者、監査担当者、運用担当者にインタビューを行い、意図しないポリシー適用の影響、承認の遅延、ロールバックの困難さによる損失を把握します。不可逆性、オブジェクト数、コンプライアンス要件に基づいてセグメンテーションを行います。
ステップ 2：プレビュー契約の定義
ポリシーバージョン、評価時刻、状態スナップショット、外部ファクトのバージョン、出力タイプを規定します。最低でも、変更あり、変更なし、適用対象外、不明（理由付き）のオブジェクトを区別します。
ステップ 3：初期スコープの選定
明示的なロジック、列挙可能なオブジェクト、説明可能な結果を持つルールを優先します。リアルタイムのランダム性、手動アクション、または監視不可能な外部システムに依存するルールは後回しにし、明示的に不明ステータスを返します。
ステップ 4：インタラクションとガードレールの設計
サマリー、代表的なオブジェクトサンプル、ダウンロード可能なリスト、機密フィールドのマスキング、ドリフト警告を表示します。高リスクな変更には再確認、2名による承認、または段階的実行を義務付けます。プレビューと送信で同一の認可チェックを使用します。
ステップ 5：競合状態とプライバシーの処理
送信時に現在の状態を再評価し、プレビューと実行結果を比較します。ドリフトが閾値を超えた場合は一時停止するか確認を求めます。テナントごとに結果を隔離し、表示を最小限に抑え、監査ログを保持します。
ステップ 6：ロールアウトと計測
社内ユーザーおよび低リスクな顧客から開始します。プレビューのレイテンシー、採用率、実行との乖離、アンドゥ操作、意図しない影響、サポートチケットを記録します。プレビューと実行結果の不一致が頻発する場合は、スナップショットを修正するか提供価値の定義を狭めてから拡大します。
模範回答例
「ドライランを完全な安全保証として位置付けることはしません。まずは削除や一括権限付与など、影響が大きく列挙可能なアクションから開始し、ミスを減らすために影響リストが顧客に本当に必要とされているかを検証します。プレビューの入力にはポリシーバージョン、テナント、評価時刻、状態スナップショットを紐付け、出力では追加、削除、変更なし、不明のオブジェクトをルールの説明とともに分類します。
結果には有効期限を表示し、送信時にも同一の実行エンジンを使用します。状態のドリフトが発生した場合は変更を一時停止するか確認を要求します。権限は本番実行時と一致させ、機密リソースは要約表示とし、大規模な結果は非同期で処理します。より多くのルールを追加する前に、低リスク顧客を対象にパイロット運用を行い、実行との乖離、アンドゥ率、意図しない影響、チケット数を測定します。」
よくある間違い
- シミュレーションを実行保証と呼んでしまうこと。
- プレビューから送信までの間の状態競合（レースコンディション）を無視すること。
- v1ですべてのポリシー、オブジェクト規模、外部依存関係に対応すると約束すること。
- 理由、サンプル、不明状態を示さずに合計数値のみを表示すること。
- プレビューにより広範な権限を与えてしまい、クロステナントのリソースを露出させること。
- ポリシーバージョン、状態のタイムスタンプ、監査エビデンスを省略すること。
- 実行との乖離や意図しない影響ではなく、クリック数だけで測定すること。
- プレビューと実行結果が乖離しているにもかかわらず、境界を修正せずに拡大を続けること。
追加の質問と回答
追加質問 1：プレビューと実行結果が一致しない場合はどうしますか？
送信時に再評価を行い、ドリフトを表示します。閾値を超えた場合は一時停止します。両方の評価についてポリシー、状態、時刻、判定識別子を記録し、不一致の原因を分類します。
追加質問 2：シミュレーションのために本番データをコピーしないのはなぜですか？
データのコピーはプライバシー、コスト、鮮度の問題を引き起こします。必要なフィールドとスナップショット時刻のみを保持した、隔離されたスナップショットまたはマスキングされたプロジェクションを使用する方が望ましいです。
追加質問 3：どの顧客に最初に提供すべきですか？
オブジェクトの境界が明確で、承認プロセスが確立されており、ロールバック能力とフィードバック体制が整っている顧客を選択します。規制対象の顧客とは、監査、データ保持、隔離要件を事前に確認します。
追加質問 4：プレビューの対象が大きすぎる場合はどうしますか？
まずはグループ化されたサマリーと代表的なサンプルを表示し、その後非同期での一覧生成と完了通知を提供します。プレビューのクエリが本番実行のリソースを圧迫しないよう、制限とコスト警告を設定します。
追加質問 5：長期的に保守する価値があることをどのように証明しますか？
機能が有効な顧客とコントロールグループを比較し、ミス、アンドゥ、インシデント、承認時間、チケット数を検証します。プレビューの採用率と実行との乖離を組み合わせて、精度と削減されたコスト・労力を評価します。