I love Terraform and as a curious explorer, I started looking for an alternative when Terraform introduced HCL2. An IaC alternative where I can use the programming language of my choice for declarative approach.

Infrastructure as Code (IaC) has revolutionized how organizations manage and provision cloud resources. By defining infrastructure through code rather than manual processes, teams can achieve consistency, version control, and automated deployment workflows. However, working with IaC tools can present unique challenges, particularly when integrating with cloud services like IBM Cloud Secrets Manager.

While creating a Pulumi project to provision Secrets Manager group instance, I came across an error

CreateSecretGroupWithContext failed: Post "https://0a21f2b7-e695-42e4-873f.us-south.secrets-manager.appdomain.cloud/api/v2/secret\_groups": dial tcp: lookup 0a21f2b7-e695-42e4-873f.us-south.secrets-manager.appdomain.cloud: no such host

halting the infrastructure provisioning entirely. This article provides a comprehensive guide to understanding, diagnosing, and resolving these DNS resolution errors while working with IBM Cloud Secrets Manager through both Terraform and Pulumi.

Understanding Infrastructure as Code (IaC)

Infrastructure as Code allows developers and operations teams to manage infrastructure through machine-readable definition files rather than physical hardware configuration or interactive configuration tools. This approach brings several benefits including repeatability, consistency, and the ability to version control infrastructure changes.

Terraform vs Pulumi: A Brief Overview

While Terraform uses HashiCorp Configuration Language (HCL) and has become the industry standard for IaC, Pulumi offers a modern alternative that allows infrastructure definition using familiar programming languages like Python, TypeScript, Go, .NET, and Java. Both tools support IBM Cloud through dedicated providers, but they differ significantly in their approach and capabilities.

Key differences include:

• Language Support: Terraform uses HCL exclusively, while Pulumi supports multiple general-purpose programming languages
• State Management: Terraform uses local or remote state files, while Pulumi uses its SaaS backend by default
• Testing Capabilities: Pulumi provides native support for unit and integration testing through programming language ecosystems

Introduction to Pulumi

What is Pulumi?

Pulumi is a modern Infrastructure as Code platform that leverages existing programming languages and their native ecosystems to interact with cloud resources through the Pulumi SDK. Unlike traditional IaC tools that require learning domain-specific languages, Pulumi allows developers to use languages they already know and love.

Key Advantages of Pulumi over Traditional IaC Tools

Enhanced Developer Experience: Pulumi provides full IDE support with code completion, error checking, and refactoring capabilities that come naturally with general-purpose programming languages.

Advanced Testing Capabilities: Since Pulumi uses real programming languages, teams can leverage existing testing frameworks and methodologies to validate their infrastructure code.

Stronger Abstraction and Modularity: Programming language features like functions, classes, and packages enable more sophisticated infrastructure abstractions than simple configuration languages allow.

Native Integration with Application Code: Teams can embed infrastructure management directly in their applications or use the same languages for both application and infrastructure development.

Pulumi’s Multi-Language Support

Pulumi supports a wide range of programming languages:

• TypeScript/JavaScript: Native Node.js support with full npm ecosystem
• Python: Full Python 3.x support with pip package management
• Go: Native Go modules and tooling
• .NET: Support for C#, F#, and VB.NET
• Java: Full JVM ecosystem support
• YAML: For simpler, declarative scenarios

Setting Up IBM Cloud with Pulumi

Installing the IBM Cloud Provider for Pulumi

To work with IBM Cloud resources in Pulumi, you need to install the IBM Cloud provider. The IBM Cloud provider for Pulumi must be installed as a local package:

pulumi package add terraform-provider ibm-cloud/ibm

Understanding the Service Endpoint Configuration Error

Though I am exploring Pulumi, the IBM Pulumi provider is based on Terraform provider. So, I took a step back to see if the Terraform provider works but I hit the same error. While digging deeper, I found this GitHub issue that clarifies many questions

Error Analysis from GitHub Issue

The specific issue documented in GitHub issue reveals a fundamental misconfiguration problem. When users specify service_endpoints = "public-and-private" in their Terraform configuration for IBM Secrets Manager, the resulting instance is provisioned with only private endpoints, despite the configuration suggesting otherwise.

Root Cause Identification:

The issue stems from IBM’s April 2025 change to make private endpoints the default for Secrets Manager instances. However, the critical distinction is that Secrets Manager uses a different parameter structure than other IBM Cloud services for endpoint configuration.

Configuration Inconsistency:

• Standard IBM Services: Use service_endpoints parameter
• Secrets Manager: Uses allowed_network within the parameters block

Analyzing the Incorrect Configuration

The problematic Terraform configuration from the GitHub issue:

resource "ibm_resource_instance" "secrets_manager" {
  count = var.provision_sm_instance == true ? 1 : 0
  name = var.sm_instance_name
  service = "secrets-manager"
  plan = var.sm_service_plan
  location = var.region
  resource_group_id = data.ibm_resource_group.sm_instance.id
  tags = var.tags
  service_endpoints = "public-and-private" # ← This is INCORRECT for Secrets Manager

  timeouts {
    create = "20m"
  }
}

Pulumi implementation

secrets_manager = ibm.ResourceInstance(
    "vpn-secrets-manager",
    name="vpn-secrets-manager",
    service="secrets-manager",
    plan="standard",
    location=region,
    resource_group_id=resource_group_id,
    service_endpoints="public-and-private", 
    tags=["vpn", "certificates", "pulumi"],
    opts=secrets_manager_opts
)

Result : Despite specifying service_endpoints = "public-and-private", the instance is provisioned with only private endpoints, leading to DNS resolution failures when attempting to create secret groups.

Pulumi error

The Correct Configuration Approach

Based on IBM’s documentation and the GitHub issue resolution, the correct approach uses the parameters block:

resource "ibm_resource_instance" "secrets_manager" {
  count = var.provision_sm_instance == true ? 1 : 0
  name = var.sm_instance_name  
  service = "secrets-manager"
  plan = var.sm_service_plan
  location = var.region
  resource_group_id = data.ibm_resource_group.sm_instance.id
  tags = var.tags

  parameters = {
    "allowed_network" = "public-and-private" # ← This is CORRECT for Secrets Manager
  }

  timeouts {
    create = "20m"
  }
}

Pulumi code fix:

Pulumi Code repository

secrets_manager = ibm.ResourceInstance(
    "vpn-secrets-manager",
    name="vpn-secrets-manager",
    service="secrets-manager",
    plan="standard",
    location=region,
    resource_group_id=resource_group_id,
    #service_endpoints=secrets_manager_service_endpoints,
    parameters={
        "allowed_network" : secrets_manager_service_endpoints,    
    },
    tags=["vpn", "certificates", "pulumi"],
    opts=secrets_manager_opts
)

For complete Pulumi code examples, refer to my GitHub repository

Conclusion

The IBM Secrets Manager DNS resolution error stems from a critical configuration difference where Secrets Manager requires parameters = { "allowed_network" = "..." } instead of the standard service_endpoints parameter.

Key Solutions:

• Always use allowed_network within the parameters block for Secrets Manager
• Implement validation to catch configuration errors early
• Use infrastructure modules to encapsulate correct patterns
• Test endpoint accessibility after provisioning

Pulumi Advantages: Offers superior error handling, testing capabilities, and IDE support compared to traditional HCL-based approaches, making it easier to implement robust validation and error handling patterns.

By following these patterns and understanding the service-specific requirements, teams can avoid DNS resolution errors and build reliable infrastructure automation workflows for IBM Secrets Manager.

Related Documentation

• IBM Cloud Secrets Manager
• IBM Cloud VPC VPN
• Pulumi IBM Cloud Provider
• Certificate Management Best Practices