diff --git a/docs/infra-as-code-management/iacm-features/module-registry/module-registry-code-structure.md b/docs/infra-as-code-management/iacm-features/module-registry/module-registry-code-structure.md
new file mode 100644
index 0000000000..a6150763a5
--- /dev/null
+++ b/docs/infra-as-code-management/iacm-features/module-registry/module-registry-code-structure.md
@@ -0,0 +1,142 @@
+---
+title: Module Code Structure
+description: Learn about the required code structure for module registry.
+sidebar_position: 10
+sidebar_label: Module Code Structure
+---
+
+OpenTofu or Terraform modules are reusable units of infrastructure configuration that help standardize deployment patterns and improve maintainability. A well-structured module simplifies usage and promotes best practices. This guide outlines the essential components of a Terraform module and how to structure it effectively.
+
+## Requirements
+### Root Module
+All OpenTofu or Terraform configurations consist of at least one module, known as the root module, which is **the only required element**. The most common name for this file is `main.tf`. This file serves as the entry point for [OpenTofu](https://opentofu.org/) or Terraform execution and contains all the necessary configurations to provision the desired infrastructure.
+
+:::info modules folder
+When using submodules, note that they are only recognized if they are placed within the `modules` folder at the root directory.
+Go to [submodule usage](/docs/infra-as-code-management/iacm-features/module-registry/root-sub-module-usage) for more information.
+:::
+
+---
+## Module Layout
+A typical OpenTofu or Terraform module consists of a set of configuration files that define resources, variables, outputs, and dependencies. Below is a recommended directory structure:
+
+```
+module-name/
+├── main.tf # Primary resource configurations
+├── variables.tf # Input variable definitions
+├── outputs.tf # Output values
+├── README.md # Documentation for the module
+├── provider.tf # Provider configuration (if needed)
+├── versions.tf # Required Terraform and provider versions
+├── modules/ # Nested submodules (if applicable)
+├── examples/ # Usage examples for reference
+└── tests/ # Automated tests for the module
+```
+
+## Other key components
+### `variables.tf` (Input Variables)
+- Declares configurable inputs for the module.
+- Variables should include descriptions and, when applicable, default values.
+
+Example:
+```hcl
+variable "instance_type" {
+ description = "EC2 instance type"
+ type = string
+ default = "t2.micro"
+}
+```
+Also see [variable usage](/docs/infra-as-code-management/project-setup/input-variables) for more information.
+
+---
+### `outputs.tf` (Output Values)
+- Defines values that the module will return upon execution.
+- Helps users access relevant module data.
+
+Example:
+```hcl
+output "instance_id" {
+ description = "ID of the created EC2 instance"
+ value = aws_instance.example.id
+}
+```
+
+---
+### `README.md` (Module Documentation)
+- Provides an overview of the module’s purpose and usage.
+- Includes example configurations and descriptions of variables and outputs.
+
+---
+### `provider.tf` (Provider Configuration)
+If a module requires provider settings, define them here. Avoid hardcoding provider settings within a module to allow flexibility.
+
+Example:
+```hcl
+tofu {
+ required_providers {
+ aws = {
+ source = "hashicorp/aws"
+ version = "~> 4.0"
+ }
+ }
+}
+```
+
+---
+### `versions.tf` (Version Constraints)
+- Specifies compatible OpenTofu or Terraform and provider versions.
+- Ensures module stability by preventing incompatible updates.
+
+Example:
+```hcl
+tofu {
+ required_version = ">= 1.0.0"
+}
+```
+
+---
+### `modules/` (Nested Modules / Submodules)
+If a module is composed of multiple submodules, organize them within this directory to improve modularity and reusability.
+
+:::info module folder
+Submodules are only recognized if they are placed within the `modules` folder.
+:::
+
+---
+### `examples/` (Usage Examples)
+Provide working examples demonstrating how to use the module in different scenarios. This helps users understand its implementation.
+
+---
+### `tests/` (Automated Testing)
+Testing ensures the module functions as expected. Use tools like `tofu test` or external frameworks such as `Terratest`.
+
+Example test using `tofu test`:
+```hcl
+tofu {
+ test {
+ assert {
+ condition = resource.aws_instance.example.instance_type == "t2.micro"
+ error_message = "Unexpected instance type"
+ }
+ }
+}
+```
+
+---
+## Best practices
+To ensure your modules are well-structured and maintainable, follow these best practices:
+
+**Root Module:** Always include a `main.tf` file at the root level of your repository. This file serves as the entry point for [OpenTofu](https://opentofu.org/docs/language/modules/) or Terraform execution.
+**Modules Folder:** Place all submodules within a `modules/` folder. Submodules are only recognized if they are placed within this folder.
+**Consistent Naming:** Use consistent naming conventions for files and directories to improve readability and maintainability.
+**Documentation:** Provide comprehensive documentation in the README.md file, including an overview, usage instructions, and examples.
+**Version Constraints:** Specify compatible OpenTofu or Terraform and provider versions in the `versions.tf` file to ensure module stability.
+**Testing:** Include automated tests in the tests/ directory to verify the functionality of your module.
+
+---
+## Conclusion
+A well-structured IaC module enhances reusability, maintainability, and collaboration. By following these guidelines, you can create reliable and scalable modules for your infrastructure needs.
+
+For more details, refer to the following documentation:
+- [Register a Module](/docs/infra-as-code-management/iacm-features/module-registry/module-registry)
+- [Root and Submodule Usage](/docs/infra-as-code-management/iacm-features/module-registry/root-sub-module-usage)
\ No newline at end of file
diff --git a/docs/infra-as-code-management/iacm-features/module-registry/module-registry-tabs.md b/docs/infra-as-code-management/iacm-features/module-registry/module-registry-tabs.md
index 1029f9eb8f..aa9d2f5e7d 100644
--- a/docs/infra-as-code-management/iacm-features/module-registry/module-registry-tabs.md
+++ b/docs/infra-as-code-management/iacm-features/module-registry/module-registry-tabs.md
@@ -1,26 +1,13 @@
---
title: Registered module settings
description: Explore each tab of a registered module to understand its data, settings, and usage in detail.
-sidebar_position: 20
-sidebar_label: Registered module settings
+sidebar_position: 40
+sidebar_label: Registered Module Settings
---
-
-
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-:::warning pending release
-IaCM Module Registry is currently pending release and will be available soon! [Learn more](https://www.harness.io/blog/harness-iacm-module-registry).
-:::
-
## Prerequisites
- A registered *tf* modules, to register a new module, go to [Register a module](https://developer.harness.io/docs/infra-as-code-management/iacm-features/module-registry#register-a-module)
@@ -126,18 +113,7 @@ Submodules can provide users with the flexibility to override or customize certa
## Top level overview
-
+
diff --git a/docs/infra-as-code-management/iacm-features/module-registry/module-registry.md b/docs/infra-as-code-management/iacm-features/module-registry/module-registry.md
index 31131b0848..a6a947abf1 100644
--- a/docs/infra-as-code-management/iacm-features/module-registry/module-registry.md
+++ b/docs/infra-as-code-management/iacm-features/module-registry/module-registry.md
@@ -1,8 +1,8 @@
---
title: Module Registry
description: Learn how to register a module in Harness IaCM
-sidebar_position: 10
-sidebar_label: Register modules
+sidebar_position: 20
+sidebar_label: Register Modules
---
import Tabs from '@theme/Tabs';
@@ -21,18 +21,7 @@ Follow the steps in the guide below to register a new module.
-
+
1. Login to [Harness](https://app.harness.io).
@@ -56,19 +45,8 @@ Follow the steps in the guide below to register a new module.
## Review module settings
Harness pulls various details from your module and makes it easy to review them.
-
+
:::info syncing module versions
The Sync button checks your registered module in Harness against the latest release in your repository and configured connector branch. If a newer version exists, it will sync it.
diff --git a/docs/infra-as-code-management/iacm-features/module-registry/root-sub-module-usage.md b/docs/infra-as-code-management/iacm-features/module-registry/root-sub-module-usage.md
new file mode 100644
index 0000000000..f1de91ed12
--- /dev/null
+++ b/docs/infra-as-code-management/iacm-features/module-registry/root-sub-module-usage.md
@@ -0,0 +1,77 @@
+---
+title: Root & Submodule Usage
+description: Learn about the requirements and correct usage of root modules and nested submodules.
+sidebar_position: 30
+sidebar_label: Root & Submodule Usage
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+
+This document provides an overview of the requirements and best practices for using root modules and nested submodules in your infrastructure-as-code setup. It explains the structure and configuration needed for single-module repositories and how to properly reference submodules within your code. Understanding these concepts will help ensure consistency and maintainability in your module usage.
+
+
+
+
+## Root Level Modules
+If you are using only a single module, you must have a `main.tf` file at the root level of your repository. Below is an example of the typical structure for a single-module repository:
+
+```
+.
+├── README.md
+├── main.tf
+├── variables.tf
+├── outputs.tf
+```
+
+Here is an example of defining a single module in `main.tf`:
+
+```hcl
+module "native-module" {
+ source = "app.harness.io//native-module/aws"
+ version = "1.2.1" # This matches your repository's Git tags.
+}
+```
+
+
+
+## Submodule Usage
+:::info
+While there is no set limit on nested submodule paths, metadata collection is only carried out one level deep.
+:::
+
+Submodules are only recognized if they are placed within the `modules` folder.
+
+Here is an example of the repository tree with submodules:
+
+```
+.
+├── README.md
+├── main.tf
+├── variables.tf
+├── outputs.tf
+├── ...
+├── modules/
+│ ├── submoduleA/
+│ │ ├── main.tf
+│ │ ├── ...
+│ ├── native-module/
+│ │ │── README.md
+│ │ │── main.tf
+│ │ │── variables.tf
+│ │ │── outputs.tf
+```
+
+They can be referenced in your root module `main.tf` file as shown below. Notice the `//` syntax, which indicates the path to the submodule:
+
+```hcl
+module "native-submodule" {
+ source = "app.harness.io//native-module//modules/native-submodule"
+}
+```
+:::info submodule versions
+Note that **submodules cannot have a version included**, as Git tags do not apply to anything beyond the root level.
+:::
+
+