⚙️ OpenTofu Error: 'Conflicting configuration arguments' mutually exclusive args set

Exact Error Message

╷
│ Error: Conflicting configuration arguments
│
│   with aws_instance.web,
│   on main.tf line 18, in resource "aws_instance" "web":
│   18:   subnet_id = aws_subnet.public.id
│
│ "subnet_id": conflicts with network_interface
╵

The specifics change with the provider and resource, but the pattern is constant: two arguments that cannot both be set at once were both provided.

What It Means

Provider schemas declare relationships between arguments. Two common ones are ConflictsWith (these arguments may not be set together) and ExactlyOneOf (exactly one of a group must be set). When you set arguments that violate one of these rules, OpenTofu rejects the configuration during validation with Conflicting configuration arguments, naming the two fields that clash.

This is a schema-level guardrail. The provider knows that, for example, defining a network interface inline and also setting subnet_id directly would be ambiguous, so it forbids the combination rather than silently picking one. The fix is always to decide which single argument expresses your intent and remove the other.

Common Causes

• Setting both subnet_id and an inline network_interface block on an aws_instance.
• Providing both ip_address and ip_address_prefix, or both a source block and a source ID, on networking resources.
• Copying an example that used one style while your existing config uses the conflicting style.
• Merging two modules or snippets that each set a different argument for the same concept.
• A conditional that sets both branches’ arguments instead of choosing one.
• Setting an argument that a newer provider version made mutually exclusive with another.

Diagnostic Commands

Validate to get the exact pair of conflicting arguments and the line:

tofu validate

Show the schema for the resource to see which arguments conflict:

tofu providers schema -json | grep -A5 network_interface

Search your config for both arguments to find where they co-occur:

grep -rn "subnet_id\|network_interface" .

Run a plan to confirm the error clears after editing:

tofu plan

Step-by-Step Resolution

1. Read the error. It names both sides of the conflict — here subnet_id conflicts with network_interface. Decide which one you actually want.

2. If you want the instance placed directly in a subnet, keep subnet_id and remove the inline network_interface block:

resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = "t3.micro"
  subnet_id     = aws_subnet.public.id
  # network_interface block removed
}

3. If you need fine-grained control over the interface, keep the network_interface block and remove subnet_id (the subnet is set on the interface instead):

resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = "t3.micro"

  network_interface {
    network_interface_id = aws_network_interface.web.id
    device_index         = 0
  }
}

4. If the choice must be conditional, use a variable plus a dynamic block so only one argument is ever rendered:

dynamic "network_interface" {
  for_each = var.use_eni ? [1] : []
  content {
    network_interface_id = aws_network_interface.web.id
    device_index         = 0
  }
}

Set subnet_id only in the branch where use_eni is false, via a conditional expression or a separate resource.

5. Re-validate and plan to confirm the conflict is gone:

tofu validate && tofu plan

Success! The configuration is valid.

Prevention

• Read the provider documentation for ConflictsWith / ExactlyOneOf relationships before combining arguments that describe the same thing.
• Pick one idiom (inline block vs. top-level argument) per resource and apply it consistently across the codebase.
• When merging modules or examples, reconcile overlapping arguments rather than pasting both.
• Use dynamic blocks and conditional expressions so a variable toggles between mutually exclusive options instead of setting both.
• Run tofu validate in pre-commit and CI so schema conflicts fail fast, before plan or apply.

Related Errors

• Missing required argument — the mirror of ExactlyOneOf when you removed one option but did not set the other.
• Unsupported argument — an argument that the resource does not define at all, distinct from a conflict.
• Invalid combination of arguments — the Terraform-lineage wording for the same class of schema rule.
• Insufficient ... blocks — a required nested block is missing rather than conflicting.

Frequently Asked Questions

How do I know which of the two arguments to keep? Decide by intent: keep the one that expresses how you actually want the resource configured, and remove the other. The provider docs describe what each argument does.

Why does the provider forbid setting both? Because the two arguments describe the same underlying concept in incompatible ways, so allowing both would be ambiguous. The schema enforces ConflictsWith to keep the configuration unambiguous.

Can I set one argument in some cases and the other in others? Yes — use a variable with a dynamic block or a conditional expression so exactly one argument is rendered per run. Never set both branches at once.

The error appeared only after a provider upgrade — why? A newer provider version may have made two previously-independent arguments mutually exclusive. Check the provider’s upgrade guide and drop the now-conflicting argument.

Is there a faster way to refactor conflicting resources? Yes — prompts in the library at /prompts/?stack=opentofu can rewrite a resource to use a single consistent idiom. For more IaC fixes, browse the OpenTofu guides.