Cloud teams should classify raw resource blocks as an exception path and either remove them or bind them to explicit approvals, owners, and expiry rules. If they remain a routine alternative to modules, the governance model stays fragmented and enforcement will remain partial.
When raw Terraform resource blocks stay in the path, what does governance really need to control?
Raw resource blocks are not just a syntax preference, they are a governance decision. If they remain available alongside modules, cloud teams need a clear rule for when they are allowed, who approves them, and how long the exception lasts. Otherwise the platform will drift into mixed standards, where policy is harder to enforce and code reviews become inconsistent.
That distinction matters because modules create a repeatable control surface. Raw blocks can still be legitimate for edge cases, but they should be treated as an exception path with explicit ownership and review, not as an interchangeable alternative to a standard module catalogue.
Why raw blocks create fragmentation instead of flexibility
When raw resource blocks are allowed without boundaries, teams often bypass the design decisions embedded in modules: naming, tagging, encryption defaults, logging hooks, network controls, and identity assumptions. The result is not just more code styles, but more control variants, which makes it harder to prove that every resource meets the same baseline.
That fragmentation also weakens operational consistency. A platform team can no longer assume that one module change improves coverage everywhere, because some resources are built outside that path. Over time, the exception becomes a shadow standard, and the review burden shifts from policy enforcement to detective work.
Where teams still need a comparison point for cloud guardrails, NIST Cybersecurity Framework 2.0 is useful for framing governance, inventory, and control consistency across shared services.
How to treat exceptions without losing control
The practical model is simple: allow raw blocks only when the use case cannot be expressed safely in an approved module, and then make the exception visible. A raw block should have a named owner, a stated reason, an approval record, and an expiry or review date so the exception does not become permanent by accident.
Teams should also decide what the exception is allowed to bypass. If the raw block can skip tagging, policy checks, or security defaults, the approval needs to be materially stronger than a normal pull request review. If the exception only changes structure but still inherits platform controls, the governance burden is lower, but the control evidence still needs to be explicit.
For cloud control design, the NIST SP 800-53 Rev 5 Security and Privacy Controls catalogue is a useful reference for mapping configuration management, access control, auditability, and change control expectations.
What good looks like in practice
Good governance does not ban every raw resource block. It makes the default path obvious, makes the exception path expensive enough to justify, and gives reviewers a clean signal when someone is stepping outside the standard. In mature setups, teams can tell at a glance whether a resource came from a trusted module, whether it was exempted, and whether that exemption still needs to exist.
If raw blocks are still common, measure them as an exception rate, not as a neutral implementation choice. A rising exception rate usually means the module catalogue is incomplete, the module ownership model is unclear, or teams are avoiding the standard because it is harder to use than the raw provider interface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.PO-01 — Policy Establishment and Communication | Raw block exceptions need a clear policy and communicated standard path. |
| ID.AM-02 — Software Platforms and Applications Inventory | Modules versus raw blocks is an inventory and standardization issue for cloud assets. | |
| Recommendation — Define when raw Terraform blocks are permitted and require the rule to be communicated and enforced. Inventory approved modules and flag unmanaged raw resource patterns for remediation. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Terraform modules and raw blocks both shape configuration baselines for cloud resources. |
| CM-6 — Configuration Settings | Raw blocks can bypass standard configuration settings that modules normally enforce. | |
| CM-3 — Configuration Change Control | Exception approvals and expiry rules are a change-control problem for infrastructure code. | |
| Recommendation — Establish approved infrastructure baselines and route deviations through formal exception handling. Use approved configuration settings and require documented justification for deviations. Require formal review and approval for infrastructure-as-code changes outside approved modules. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Raw Terraform blocks are a configuration-management exception that must be controlled. |
| A.8.32 — Change management | Allowing raw blocks as an exception path depends on disciplined change governance. | |
| Recommendation — Control infrastructure configuration changes and document exceptions to approved patterns. Apply change management to non-standard Terraform patterns and time-limit the exception. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Approved Terraform modules are a secure configuration mechanism; raw blocks can weaken it. |
| Recommendation — Standardize secure cloud configurations and reduce unmanaged infrastructure variations. | ||
Practitioner Guidance
What to prioritise: Put the strongest controls around the exception path first. If raw blocks stay allowed, make approval, ownership, and expiry mandatory before you worry about refining the module library.
What to verify: Every raw block should have a current business or technical justification, an accountable owner, and a review date. If any of those are missing, treat it as an unmanaged drift item, not a harmless shortcut.
Common mistake: Teams often preserve raw blocks “for flexibility” and then never retire them. That turns an exception into a parallel delivery pattern, which is exactly where enforcement starts to fail.
Practitioner takeaway: The objective is not to eliminate every raw resource block, it is to stop exceptions from becoming the normal route around platform governance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org