How do you decide between Terraform, a configuration management tool, and a cloud native option for a given job?

Match the tool to the lifecycle. Use a declarative provisioning tool like Terraform for creating and destroying cloud resources with a state model. Use configuration management for what happens inside a machine when you cannot use immutable images. Use cloud native tooling when you need tight integration or your organization is entirely on one provider. The bigger factor is usually team familiarity and having one obvious way to do things.

I split it by lifecycle. Provisioning cloud resources, so networks, clusters, databases, is declarative with a state model, and Terraform is my default there because the provider coverage is broad and the plan step gives me a genuine review artifact before anything changes. Configuration inside a machine is a different job, and honestly I try to avoid needing it at all by baking images and treating instances as disposable, so configuration management ends up limited to image building or legacy boxes I cannot replace yet. Cloud native tooling is a real option when an organization is entirely on one provider and values the tight integration, and the multi cloud portability argument for Terraform is weaker than people claim, because the modules are provider specific anyway. What decides it more often than technical merit is what the team already knows and what the existing code is written in. Introducing a second provisioning tool for the same resources is the actual mistake, because now drift can come from either direction and nobody knows which one is authoritative.