Review Checklist

นี่คือ checklist ที่ต้องไล่ดู — ด้วยตาเปล่า บน diff ไหนก็ได้ ไม่ว่าจะเป็นของคุณหรือของ AI — หลังจากเครื่องมือใน Verification Tools รันผ่านสะอาดแล้ว มันตั้งใจให้อยู่หน้าเดียวพิมพ์ได้พอดี: checklist ที่ไม่มีใครเปิดดูจริงตอน review ไม่มีค่าอะไรเลย ทุกบรรทัดลิงก์ไปยัง entry ที่อธิบาย เหตุผล เพื่อให้หน้านี้ยังเป็นแค่ list ไม่ใช่การรื้อคอร์สมาสอนซ้ำ กลุ่มต่างๆ เรียงตามลำดับเดียวกับ วิธีอ่าน Terraform ที่ไม่ได้เขียนเอง บวกกลุ่ม Tooling สุดท้ายที่ครอบคลุมว่าอีกเจ็ดกลุ่มถูก verify ยังไงจริงๆ

flowchart LR
  A["Versions &amp; providers"] --> T["validate/plan จับได้บางส่วน<br/>(deprecation warning, module+count error)"]
  B["State &amp; backend"] --> P["บางส่วน: remote_state พังดังจริง,<br/>backend-locking drift เงียบ"]
  V["Variables"] --> M["ส่วนใหญ่ต้อง review ด้วยคน<br/>(nullable/ephemeral ทำงานเงียบ)"]
  R["Resources &amp; lifecycle"] --> P2["บางส่วน: for_each-on-unknown จับได้,<br/>prevent_destroy-ผิดตัวจับไม่ได้"]
  Mo["Modules"] --> P
  Tg["Terragrunt live tree"] --> M
  C["CI &amp; policy"] --> P2

อะไรจับแต่ละกลุ่มได้จริง ถ้ามี

Versions & providers

• ทุก required_providers constraint เป็น ~> ไม่ใช่ >= ใช่ไหม? Constraint ที่ลอยตัว resolve ไปที่ release ใหม่สุดของ registry ในวันที่ init รัน ดู AI Bug Catalog, entry 1
• .terraform.lock.hcl commit ไว้แล้วหรือยัง — ไม่ได้ gitignore พร้อมกับ .terraform/? ดู entry 4
• terraform validate -json กลับมาโดยไม่มี warning เลยใช่ไหม ไม่ใช่แค่ไม่มี error? Argument ที่ deprecated (acl, managed_policy_arns) ยัง validate และ plan ผ่านสำเร็จ ดู entry 2
• มี module ไหนประกาศ provider block ของตัวเองหรือไม่? มัน validate ผ่านด้วยตัวเองสบายๆ และพังก็ต่อเมื่อผู้เรียกใช้ต้องการ count/for_each/depends_on ดู entry 3

State & backend

• กลไกล็อกของ backend ตรงกับสิ่งที่ Terraform/backend version นี้รองรับจริงหรือไม่ — use_lockfile (S3, stable ตั้งแต่ 1.11) แทนที่ dynamodb_table ที่ deprecated แล้ว? ดู AI Bug Catalog, entry 5 และ The State File
• terraform_remote_state data source ทุกตัวชี้ไปที่ key/path ที่ apply ไปแล้วจริงหรือไม่? ไม่มี mock fallback เลย — state ที่หายไปพัง plan ทั้งหมดหนักๆ ดู entry 6

Variables

• default ของ nullable = false variable เคยแทนที่ null ที่ผู้เรียกส่งมาตรงๆ อย่างเงียบๆ หรือไม่ โดยไม่มีอะไรใน plan/apply output บอกเรื่องการแทนที่เลย? ดู AI Bug Catalog, entry 7
• variable ไหนที่เป็น ephemeral มี default เป็น secret ตรงๆ หรือไม่? มันยังรั่วเข้าไปใน show -json ของ plan ที่ save ไว้ แม้จะไม่เข้า state เลยก็ตาม ดู entry 8

Resources & lifecycle

• ใช้ count กับ list ไหนที่อาจถูกจัดลำดับใหม่ได้ ในที่ที่ for_each เป็นทางเลือกปลอดภัยทางเดียวหรือไม่? การเอา element ตรงกลางออกเลื่อน index ทุกตัวที่ตามมา ดู AI Bug Catalog, entry 10
• lifecycle { prevent_destroy = true } อยู่บน resource ที่สำคัญจริงหรือไม่ — ตรวจตรงๆ ไม่ใช่สมมติจาก resource ใกล้ๆ? ดู entry 9 พิสูจน์ด้วย plan -destroy จริงที่ destroy database ที่ไม่ถูกป้องกันได้โดยไม่มีอะไรต้านเลย
• for_each ไหน derive key มาจาก computed attribute ของ resource ที่ managed อีกตัวหรือไม่? Error “Invalid for_each argument” จริงและปัจจุบัน — ดู entry 11
• ใช้ null_resource ในที่ที่ terraform_data (1.4+) ตัดทั้ง provider dependency เพิ่มออกไปสำหรับพฤติกรรมที่เท่ากันหรือไม่? ดู entry 12
• มี argument ไหนที่ดู copy มาจาก resource type ที่คล้ายกันแต่ไม่ใช่ตัวเดียวกันหรือไม่ (deletion_protection บน azurerm_linux_virtual_machine, จริงบน compute resource ของ provider อื่นแต่ไม่ใช่ที่นี่)? Error “Unsupported argument” จริง — ดู entry 13

Modules

• ทุก source ที่ไม่ใช่ registry pin revision ไว้แล้วหรือยัง — ?ref=<tag-or-sha> สำหรับ source แบบ git::, version ตรงๆ สำหรับ registry module? ถ้าไม่มี Terraform จะ track default branch ของ HEAD อย่างเงียบๆ ดู AI Bug Catalog, entry 14
• depends_on บน module call ไหนมีไว้เพื่อ “แก้” ข้อร้องเรียนเรื่องลำดับที่จริงๆ แล้วเป็น reference cycle จริงหรือไม่? ไม่มี depends_on ใดกด Error: Cycle จริงไว้ได้ ดู entry 15

Terragrunt live tree

• มีอะไรอ้างอิง run-all/plan-all หรือไม่? ทั้งคู่เป็นคำสั่งที่ไม่รู้จักตั้งแต่ Terragrunt 1.1 CLI redesign — ปฏิเสธจริงและทันที ดู AI Bug Catalog, entry 16
• ไฟล์ terragrunt.hcl ของสอง environment เคยมีค่า account_id/region/subscription/project เหมือนกันทุกตัวอักษรใน inputs หรือไม่? terragrunt hcl validate จับ copy-paste ที่ valid ทาง syntax แบบนี้ไม่ได้ ดู entry 17 พิสูจน์ด้วย diff ของ dev/prod ที่เหมือนกันทุกตัวอักษรจริง

CI & policy

• -auto-approve เคยรันกับ plan ที่ สดใหม่ แทนที่จะเป็นไฟล์ plan -out ที่ save และ review แล้วหรือไม่? ดู AI Bug Catalog, entry 18 พิสูจน์ด้วย apply เทียบข้างกันจริง
• GitHub Action จาก third-party ทุกตัว pin ด้วย commit SHA เต็ม ไม่ใช่ tag ที่เปลี่ยนได้อย่าง @master/@main ใช่ไหม? ดู entry 19
• Policy Rego ไหนใช้ syntax ก่อน v1 (deny[msg] { ... }) หรือไม่? มัน load ไม่ผ่านเลยภายใต้ OPA/conftest ปัจจุบัน — ดู entry 20 พิสูจน์ด้วย rego_parse_error จริง
• comment #checkov:skip= ทุกอันระบุ ID ที่กำลัง fail จริงๆ หรือไม่ ไม่ใช่ ID จริงแต่ไม่เกี่ยวข้อง? comment skip ที่ระบุ ID ผิด (แต่จริง) ไม่ได้ suppress อะไรเลย — ดู entry 21 พิสูจน์ด้วย skip ของ CKV_AZURE_35 ที่ปล่อยให้ finding จริงของ CKV_AZURE_59 ยังอยู่
• มี secret จริงถูก commit ในไฟล์ .tfvars หรือไม่ หรือเหลืออยู่ใน terraform.tfstate เป็น plaintext แม้ output จะติด sensitive แล้วหรือไม่? ดู entry 22–23

Tooling

• terraform validate -json | jq '.diagnostics[]' ถูกเช็คหา warning ด้วยหรือไม่ ไม่ใช่แค่ exit code ที่ไม่ใช่ศูนย์? ดู Verification Tools
• CI รัน terraform plan -detailed-exitcode จริงและตรวจ show -json ของ plan ที่ save ไว้ด้วย policy tool จริง (conftest, checkov) ไม่ใช่แค่กวาดตาดู plan text หรือไม่? ดู Verification Tools
• terragrunt hcl validate/render รันใน CI ก่อน run --all plan เพื่อจับ syntax error ก่อนที่ tree 10 หน่วยจะ apply ไปครึ่งหนึ่งหรือไม่? ดู Verification Tools

🏗️ Checklist ช่วยแคบขอบเขตการค้นหา ไม่ได้แทนที่มัน

ทุกบรรทัดข้างบนแมปกับหนึ่งใน 23 pattern ใน AI Bug Catalog — มีแค่ส่วนน้อยเท่านั้นที่ validate/plan/terragrunt ปฏิเสธตรงๆ รัน list นี้กับทุก diff ไม่ว่าเครื่องมือเหล่านั้นจะผ่านสะอาดแค่ไหน

ทำไม coverage diagram ของกลุ่ม 'Versions & providers' ถึงบอกว่า 'validate/plan จับได้บางส่วน' ในขณะที่ 'Variables' กับ 'Terragrunt live tree' บอกว่า 'ส่วนใหญ่ต้อง review ด้วยคน'?

เป็นแค่การสุ่มเลือก — ทุกกลุ่มมี tool coverage เหมือนกันหมด Argument ที่ deprecated หรือ module+count ที่ขัดกันเป็นสิ่งที่ validate/plan ตรวจจับได้จาก schema/graph เพียงอย่างเดียว ส่วนคำถามว่า default ของ nullable แทนที่ null อย่างเงียบๆ หรือไม่ หรือ terragrunt.hcl ของสอง environment ต่างกันจริงหรือไม่ เป็นคำถามเชิง semantic ที่ไม่มีเครื่องมือไหนตรวจได้โดยไม่รู้เจตนาจริงของ reviewer Variables ไม่เคยถูก validate ด้วยเครื่องมือไหนเลย ไฟล์ Terragrunt fail hcl validate เสมอ

stack หนึ่งมี database resource จริงที่ไม่มี lifecycle block เลย อยู่ข้างๆ helper resource ที่ทิ้งได้ซึ่งมี lifecycle { prevent_destroy = true } กลุ่มไหนใน checklist ครอบคลุมการ review คู่นี้ และมันขึ้นอยู่กับอะไรในการจับ?

Terragrunt live tree — ขึ้นอยู่กับ input ต่อ environment Resources & lifecycle — การจับขึ้นอยู่กับการเช็ค prevent_destroy กับ resource ที่สำคัญจริงๆ เพราะ terraform plan เองยอมรับ configuration นี้โดยไม่มีข้อโต้แย้งเลยจนกว่าจะมีการลอง plan -destroy จริง Versions & providers — prevent_destroy เป็นเรื่องของ provider version Tooling — มีแค่ checkov เท่านั้นที่จับเรื่องนี้ได้

ทำไม checklist ถึงถาม 'Rego policy ทุกตัวใช้ syntax v1 หรือไม่' ในกลุ่ม CI & policy แทนที่จะสมมติว่า conftest จะแค่เตือนเรื่อง syntax เก่า?

conftest อัปเกรด syntax Rego เก่าให้อัตโนมัติเสมอ พิสูจน์ตรงๆ: syntax ก่อน v1 อย่าง deny[msg] { ... } สร้าง rego_parse_error จริงตอน LOAD ภายใต้ conftest ปัจจุบัน — เป็นความล้มเหลวหนักตั้งแต่เริ่มรัน ไม่ใช่ warning ซึ่งดูเหมือนปัญหา CI/tooling ได้ แทนที่จะเป็นสิ่งที่มันเป็นจริงๆ Syntax Rego v1 กับก่อน v1 ทำงานเหมือนกันเป๊ะ เรื่องนี้เกี่ยวกับ checkov เท่านั้น ไม่เกี่ยวกับ conftest

ทำไม checklist ถึงมีบรรทัด 'checkov skip comment ทุกอันระบุ ID ที่กำลัง fail จริง' แยกออกมา แทนที่จะเชื่อว่า checkov จะ flag comment ที่ระบุ ID ผิด?

checkov error เสมอเมื่อ ID ของ skip comment ไม่ตรงกับ check ที่ fail พิสูจน์ตรงๆ: การรัน checkov จริงกับ #checkov:skip=CKV_AZURE_35 (ID จริงแต่ผิดตัว) ปล่อยให้ finding ที่ fail จริงคือ CKV_AZURE_59 ยังอยู่ในรายงานเหมือนไม่มี skip comment เลย นี่เป็นแค่ความกังวลเชิงทฤษฎี ไม่เคยเกิดขึ้นจริง checkov ปฏิเสธ skip comment ที่มี ID ไม่รู้จักทั้งหมด

Submit

Mark as complete