読みにくいが、一行一行追っていけば、なるほど確かにという感じで評価されているのがわかるので、困ったら読む価値は十分ある。読みやすくするtraceを使う注意点が2つある。「なんでテストが通らないかわからないけど、traceが読みにくくて追いきれない」そんなときは、dataもOR評価もせず、決め打ちのinputに対するミニマムポリシーを用意してルールを直書きしてみるといい。traceを見てもポリシーはあってるがテストが通らないテストに引数がついていないだろうか。私はこれで数時間溶かした。rego正直気持ちが悪いしデバッグがしにくい原因の1つ。ツールを選ぶ基準はいろいろあります。IaCの言語がチームとって扱いやすいか、クラウドやサービスへのIaCの対応状況は早い/十分か、コミュニティの大きさは十分でググれば情報を入手できるか、実装がオープンソースで公開されているか、利用事例が欲しいか、など様々な理由で選ぶことでしょう。いうからには最低限出来ていないと困ること」というのが個人的にあります。維持できないと判断したためでした。最低限求めることを言語化しようと思います。持てることを求めます。これらが不完全なIaCでは、コードでのリソース管理は不完全なものになり、今回のように維持できない原因になるため避けます。コードとリソース状態の一致を保障できることを求めます。一致が保障できることで、コードからリソースの状態を完全に制御できます。実行前に実行プランを出力できることを求めます。実行プランによりコードの変更適用前にリソースへの影響がわかるため、PRベースでレビューをうけつつ開発ができます。正確な実行プランには、ステートかそれに準じたものと継続した開発体制が必要になるでしょう実行プランによるコード変更によるリソース差分の確認ステートをIaCサービスやオブジェクトストレージに配置し、ステート実行時にロックできることを求めます。コードでクラウドリソースを管理できるとはどういうことでしょうか?私は、コードで定義を書いたらリソースが追加されてほしいし、コードの定義を変更したらリソースが変更されてほしいし、コードの定義を消したらリソースが削除されてほしいです。リソースの状態と一致するとコードでクラウドリソースが管理でき、クラウドコンソールで操作する機会を大きく減らすことができます。3コードでリソースを管理するためにはチームでスムーズに開発を行いたいです。チーム各自でブランチを切って並行してコードを修正、修正ごとに実行プランで差分を確認し、レビューを受け、問題ないならマージしたいでしょう。ステートをリモートに置いたり、実行ごとにロックされるとチーム開発で扱いやすくなります。レビューの漏れに対応するためには、コードで誤って消されてもリソースの削除をブロックする機能も必要になるでしょう。コードをリソースに適用した後に、クラウド側でリソースに変更がかかったりすることがあるのを考慮すると、リソースの変更差分を無視する機能も必要になるでしょう。最低限求めることがわかります。リソース状態になることを期待しますコードを追加したときに、リソースでも追加されることを期待しますコードを変更したときに、リソースでも変更されることを期待しますコードを削除したときに、リソースは削除されることを期待しますコードで誤って削除がかかる変更を記述したときに、リソースの削除をブロックする記述ができることを期待します。(protection)コードの適用時に、リソースで起こった変更を無視したりコードの変更を無視する記述ができることを期待します。(ignore)コードの適用前に、実行プランを表示して実リソースとの差分を正確に示せることを期待します実行プランは、「現在のリソース状態とコードの差分」を示せることを期待します。コードとリソースの一致を保証できないと何が起こるのかを考えてみましょう。ついて軽く説明しましょう。