chore: strengthen blog and case study internal links (#167)

## what

- Add contextual internal links across Terraform/OpenTofu foundations,
architecture, performance, automation, and AI content.
- Connect relevant blog guidance with Cursor and Power Digital
case-study proof.
- Refresh modification dates on updated blog posts.

## why

- Help readers move from a specific problem to the next useful guide or
real-world outcome.
- Strengthen topic clusters without forcing unrelated archive content
into the navigation.

## references

- No related GitHub issue.

Co-authored-by: yangci <hi@yangci.dev>

Author: LindsayB610

content/blog/2024-08-22-terralith-monolithic-terraform-architecture.md

@@ -5,7 +5,7 @@ title: "The Terralith: Monolithic Architecture of Terraform & Infrastructure as
 author: Yangci Ou
 slug: terralith-monolithic-terraform-architecture
 date: 2024-08-22
-# date_modified: 2025-xx-xx Be sure to use this if you've updated the post as this helps with SEO and index freshness
+date_modified: 2026-08-18
 description: This article explores the challenges and pitfalls of Terralith, a monolithic Terraform architecture in Infrastructure as Code, and uncovers why a Terralith is not a good practice.
 image: /img/updates/terralith/terralith-article.png
 preview_image: /img/updates/terralith/terralith-preview-image.png # Use preview_image to prevent image overflow, best aspect ratios 270x355 or 600x700
@@ -71,7 +71,7 @@ Imagine a Terralith’s state file like a single, massive spreadsheet tracking e
 
 In IaC, the workflow first checks all resources against the real infrastructure, then plans the changes from your infrastructure code, and finally executes the plan by applying it. Even if we are trying to modify something as minor as renaming one resource, **the system must verify against every single resource in the state file**.
 
-It’s a domino effect because this not only slows down the development and deployment process, but also increases the vulnerability to transient errors such as credential expirations and API rate limits. At Masterpoint, we've had clients with Terralith codebases which took over 30+ minutes for simple plans and applies. As you can imagine, they often timed out or reached the API limits.
+It’s a domino effect because this not only slows down the development and deployment process, but also increases the vulnerability to transient errors such as credential expirations and API rate limits. At Masterpoint, we've had clients with Terralith codebases which took over 30+ minutes for simple plans and applies. As you can imagine, they often timed out or reached the API limits. If you need to prove which resources are causing the slowdown before committing to a refactor, use [OpenTofu's `-exclude` flag to isolate the performance bottleneck](https://masterpoint.io/blog/using-opentofu-exclude-flag-isolate-performance-bottlenecks/).
 
 ![Terralith API Limit Example](/img/updates/terralith/terralith-api-limit-example.png) <!-- API Limit Screenshot -->
 
@@ -95,7 +95,7 @@ Breaking up a monolithic TF architecture is like splitting each floor of the sky
 
 Of course, there are scenarios where a Terralith might make sense, such as smaller projects, prototyping, and proof of concepts. “But as you evolve, as you have more teams and more complicated setups, you need to think about [blast radius, state management, and architecture],” as said by [Nicki Watt](https://www.hashicorp.com/resources/evolving-infrastructure-terraform-opencredo).
 
-While the specific end structure will vary based on organizational needs, a general approach to breaking up a Terralith involves splitting infrastructure into different services and drawing clear boundaries around them. You have a few options to do this. At Masterpoint, we typically create root modules at the service boundary: AWS RDS clusters, AWS SQS Queues, Lambda Functions, and ECS Services all get their own root module. Then we instantiate instances of these root modules with specific configuration for each time the service is used within our client’s infrastructure. For example, if you have a prod and a staging database, the same AWS RDS root module would be configured differently and used two times.
+While the specific end structure will vary based on organizational needs, a general approach to breaking up a Terralith involves splitting infrastructure into different services and drawing clear boundaries around them. You have a few options to do this. At Masterpoint, we typically create root modules at the service boundary: AWS RDS clusters, AWS SQS Queues, Lambda Functions, and ECS Services all get their own root module. Then we instantiate instances of these root modules with specific configuration for each time the service is used within our client’s infrastructure. For example, if you have a prod and a staging database, the same AWS RDS root module would be configured differently and used two times. For the migration sequence, backups, and state moves, see our guide on [breaking up a Terralith](https://masterpoint.io/blog/steps-to-break-up-a-terralith/).
 
 [TF Workspaces](https://opentofu.org/docs/language/state/workspaces/) is another method to manage this complexity. By leveraging workspaces, teams can maintain separation between environments while reusing the same TF codebase. This approach adheres to the [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) principle, reducing duplication and helping some of the pitfalls mentioned above.
 

content/blog/2024-10-10-migrate-off-tfc.md

@@ -5,7 +5,7 @@ title: "How to Migrate off Terraform Cloud"
 author: Veronika Gnilitska
 slug: how-to-migrate-off-tfc
 date: 2024-10-10
-# date_modified: 2025-xx-xx Be sure to use this if you've updated the post as this helps with SEO and index freshness
+date_modified: 2026-08-18
 description: "Need to to migrate off Terraform Cloud? We're happy to share some tips about preparation, pitfalls, and the process itself based on Masterpoint's experience."
 image: /img/updates/migrate-off-tfc/main.webp
 preview_image: /img/updates/migrate-off-tfc/preview.webp
@@ -68,7 +68,7 @@ To migrate the state, you must use the Terraform [API](https://www.terraform.io/
 
 This extra step makes the migration process more labor-intensive compared to other backends. We’ve found [this detailed guide on downloading your Terraform state files to be helpful](https://github.com/hashicorp/terraform/issues/33214#issuecomment-1553223031). It is a GitHub comment by a HashiCorp team member.
 
-Ensure your new storage solution is configured correctly to handle Terraform state files, including appropriate redundancy, access permissions, and encryption settings. While there are other options, we encourage our clients to utilize their primary cloud’s object storage solution, like AWS S3, Google Cloud Storage, or Azure’s Blob Storage, to ensure that the infrastructure management process is secure, reliable, and integrated within the broader cloud environment. If you want a jumpstart on using S3 as your state storage, [check out Cloud Posse’s tfstate-backend module](https://github.com/cloudposse/terraform-aws-tfstate-backend).
+Ensure your new storage solution is configured correctly to handle Terraform state files, including appropriate redundancy, access permissions, and encryption settings. While there are other options, we encourage our clients to utilize their primary cloud’s object storage solution, like AWS S3, Google Cloud Storage, or Azure’s Blob Storage, to ensure that the infrastructure management process is secure, reliable, and integrated within the broader cloud environment. For the rationale and a complete S3 example, see [why cloud object storage is the best Terraform remote backend](https://masterpoint.io/blog/why-use-cloud-object-storage-terraform-remote-backend/). If you want a jumpstart on using S3 as your state storage, [check out Cloud Posse’s tfstate-backend module](https://github.com/cloudposse/terraform-aws-tfstate-backend).
 
 ## Variables and Secrets Management
 
@@ -97,7 +97,7 @@ Consider these questions for your migration plan:
 1. Do you have a cost analysis tool that needs to be implemented in your new solution?
 1. Do you have infrastructure management access policies that need to be implemented in your new solution? Think of Sentinel or OPA.
 1. Do you have any security scanning that needs to be implemented in your new solution? Consider integrating with Snyk or other similar tools.
-1. Do you have any webhooks or notifications executed from Terraform Cloud? You’ll need to migrate the configuration, including tokens, recipients, and anything else.
+1. Do you have any webhooks or notifications executed from Terraform Cloud? You’ll need to migrate the configuration, including tokens, recipients, and anything else. Our guide to [efficient Terraform automation notifications](https://masterpoint.io/blog/importance-of-efficient-notifications-terraform-automation/) covers how to keep failure alerts useful after the move.
 1. Do you run Drift Detection for any of your Terraform Cloud Workspaces? Do you need your new solution to have analogous functionality?
 
 Finding the answers to these questions for your organization and coming up with a plan to deal with each use case in the planning phase will help ensure a smooth migration.
@@ -191,7 +191,7 @@ Here’s the promised [checklist](https://docs.google.com/document/d/1ibwIi3gKIx
 
 Migrating off Terraform Cloud requires careful planning and execution, but by following these tips, you can achieve a smooth transition. Remember to document your migration process, communicate with your team, and continuously test and refine your approach.
 
-With the right preparation, you'll be well on your way to managing your infrastructure with greater control and flexibility.
+With the right preparation, you'll be well on your way to managing your infrastructure with greater control and flexibility. For a 43,000-resource migration from Terraform Cloud to Spacelift and OpenTofu, see the [Power Digital case study](https://masterpoint.io/case-studies/power-digital/).
 
 Finally, feel free to [reach out to us](https://masterpoint.io/contact/) if you need help or a second set of eyes.
 

content/blog/2025-03-06-steps-to-break-up-a-terralith.md

@@ -5,7 +5,7 @@ title: "Steps to Break Up a Terralith"
 author: Veronika Gnilitska
 slug: steps-to-break-up-a-terralith
 date: 2025-03-06
-# date_modified: 2025-xx-xx Be sure to use this if you've updated the post as this helps with SEO and index freshness
+date_modified: 2026-08-18
 description: In this follow-up to our "What Is a Terralith?" article, we shift the focus from describing the problem to providing a detailed migration plan, practical guidance, and a handy checklist for breaking up a Terralith into smaller, more manageable root modules.
 image: /img/updates/steps-to-break-up-a-terralith/main.png
 preview_image: /img/updates/steps-to-break-up-a-terralith/preview.png
@@ -49,7 +49,7 @@ Let’s take a look at the typical symptoms of a Terralith:
 
 - **Large state file(s)**: A large number of resources are stuffed into a single `.tfstate` state file. There’s no universally correct file size or resource count for TF. However, our experience suggests that **if your state files have between a few hundred and 1000+ resources** then you're likely dealing with performance and manageability issues. Not all APIs are the same, so that might not be the case for you, but we're painting with a broad brush here to give you an idea. Ideally, your TF root modules are built around service boundaries that share the same lifecycle, allowing for easy division.
 - **One big root module**: There is no clear separation of concern or logical grouping of services, such as databases, networking, and DNS. While deciding how to segment resources can be complex, a foundational best practice is to place unrelated resources in separate root modules. For example, if a Route 53 alias is only used by Service A — and never by Service B — avoid defining it in the same module as Service B.
-- **Slow plan/apply operations**: Having many resources in a single state file can cause TF `plan` and `apply` operations to slow down considerably. Even if you don’t know the exact file size or resource count, experiencing sluggish performance is a sign. If your plan regularly takes 10 minutes or more, congrats, you have a Terralith! This issue can also arise when a root module manages many of the same resource types, such as DataDog monitors. In these cases, consider restructuring your configuration (e.g., grouping monitors into logical modules based on who owns them in the organization or their business impact).
+- **Slow plan/apply operations**: Having many resources in a single state file can cause TF `plan` and `apply` operations to slow down considerably. Even if you don’t know the exact file size or resource count, experiencing sluggish performance is a sign. If your plan regularly takes 10 minutes or more, congrats, you have a Terralith! This issue can also arise when a root module manages many of the same resource types, such as DataDog monitors. In these cases, consider restructuring your configuration (e.g., grouping monitors into logical modules based on who owns them in the organization or their business impact). Before beginning a breakup, you can [use OpenTofu's `-exclude` flag to isolate the performance bottleneck](https://masterpoint.io/blog/using-opentofu-exclude-flag-isolate-performance-bottlenecks/) and confirm where the time is actually going.
 - **Complex deployments**: If your deployment process frequently relies on partial or “targeted” applies — for example, using `terraform apply -target=<resource>` — or other manual interventions, your root module resources are too entangled.
 - **High blast radius**: If even a small change or upgrade in one part of the infrastructure can affect unrelated components, you probably have a Terralith. This situation increases operational risk.
 
@@ -360,7 +360,7 @@ Ready to move from theory to action? We’ve consolidated everything into a sing
 
 Breaking up a Terralith into smaller, more manageable modules is **crucial** for organizations seeking to improve speed, reduce risk, and follow modular best practices in Infrastructure as Code. While newer Terraform/OpenTofu features like `import` and `remove` blocks have made migrations easier, there is still complexity and potential for error. Hence, our emphasis on scripts, backups, careful planning, and validation.
 
-While the process requires care during planning and execution, the benefits of a modular and maintainable infrastructure are well worth the effort.
+While the process requires care during planning and execution, the benefits of a modular and maintainable infrastructure are well worth the effort. See how we decomposed a 43,000+ resource Terralith for [Power Digital](https://masterpoint.io/case-studies/power-digital/).
 
 If you need assistance or have questions about the process, our team at Masterpoint are the go-to experts in IaC. We’ve done this dozens of times and can help guide you through breaking up your Terralith and setting up future-proof IaC.
 

content/blog/2025-04-01-importance-of-efficient-notifications-terraform-automation.md

@@ -5,7 +5,7 @@ title: "Importance of Efficient Notifications in Terraform & IaC Automation"
 author: Yangci Ou
 slug: importance-of-efficient-notifications-terraform-automation
 date: 2025-04-01
-# date_modified: 2025-xx-xx Be sure to use this if you've updated the post as this helps with SEO and index freshness
+date_modified: 2026-08-18
 description: Explore how unnoticed Terraform & Infrastructure as Code (IaC) failures can lead to significant problems, and how efficient notification alerts can prevent issues from cascading into major operational disruptions.
 image: /img/updates/efficient-notifications-terraform-automation/terraform-automation-notifications.png
 callout: <p>👋 <b>If you're ready to take your infrastructure to the next level, we're here to help. We love to work together with engineering teams to help them build well-documented, scalable, automated IaC that make their jobs easier. <a href='/contact'>Get in touch!</a></p>
@@ -30,7 +30,7 @@ Because there are so many factors involved in cloud infrastructure, there’s mo
 
 But do you know what’s way worse than a failed TF deployment? A deployment failure that doesn’t get noticed **for days**.
 
-In this article, we'll talk through this problem and share how we believe it should be handled. We'll include specifics on how we do this today with [Spacelift](https://spacelift.io/) for our clients.
+In this article, we'll talk through this problem and share how we believe it should be handled. We'll include specifics on how we do this today with [Spacelift](https://spacelift.io/) for our clients. If you are weighing that move, start with our guide on [migrating off Terraform Cloud](https://masterpoint.io/blog/how-to-migrate-off-tfc/).
 
 ## The Silent Failure Problem in IaC Deployments
 

content/blog/2025-04-17-using-mcps-to-run-terraform.md

@@ -4,7 +4,7 @@ draft: false
 title: "Using MCPs to Run Terraform"
 author: Weston Platter
 date: 2025-04-17
-# date_modified: 2025-xx-xx Be sure to use this if you've updated the post as this helps with SEO and index freshness
+date_modified: 2026-08-18
 slug: using-mcps-to-run-terraform
 description: "We jump into a hands-on exploration of Model Context Protocol (MCP), sharing our experiment using a MCP client to run terraform init, plan, apply. We share our take on where agents add value and highlight security considerations when adding MCPs to your workflow."
 image: /img/updates/using-mcps-to-run-terraform/header5.png
@@ -99,7 +99,7 @@ Example Cursor `mcp.json` config file
 
 ### Terraform code
 
-From there, I added a `main.tf` file in the configured `TERRAFORM_DIR` and wrote some basic terraform code to provision the Postgres resources:
+From there, I added a [`main.tf` file](https://masterpoint.io/blog/standard-tf-files/#maintf-resource-definitions-and-primary-infrastructure) in the configured `TERRAFORM_DIR` and wrote some basic terraform code to provision the Postgres resources. The example pins its provider version; see our [Terraform versioning guide](https://masterpoint.io/blog/ultimate-terraform-versioning-guide/) for how to choose compatible constraints:
 
 - **Terraform block**: sets the required provider, `cyrilgdn/postgresql`
 - **Provider config**: connects to a local Postgres instance as `admin_user`
@@ -198,7 +198,7 @@ My takeaways from the experience:
 
 {{< lightboximg "/img/updates/using-mcps-to-run-terraform/mcp-collective.png" "Collection of MCPs" >}}
 
-- **Surfacing feedback loops is where agentic tools can shine.** Most of the pain in this experiment came from not seeing the error — not from the error itself. Agentic workflows that help you interpret state, errors, or diff outputs (and offer remediations) are more valuable than abstracting away the command execution. The real unlock isn’t just running `terraform apply` — it’s making sense of what went wrong and suggesting what to do next.
+- **Surfacing feedback loops is where agentic tools can shine.** Most of the pain in this experiment came from not seeing the error — not from the error itself. Agentic workflows that help you interpret state, errors, or diff outputs (and offer remediations) are more valuable than abstracting away the command execution. The real unlock isn’t just running `terraform apply` — it’s making sense of what went wrong and suggesting what to do next. For a testing-focused example of putting AI assistance to work in Terraform code, read [our prompt strategies for test generation](https://masterpoint.io/blog/ai-meets-tf-prompt-strategies-for-test-generation/).
 
 <br>