A city edge stack’s Terraform root lists VLAN and interface resources for IOS XE but never configures how Terraform authenticates to the device. What is missing from the constructed workflow?
Select an answer to reveal the explanation.
Short Explanation
The provider is the radio channel Terraform uses to talk to the switch—without it, resource blocks have nowhere to land. Cloud landing zones and Puppet certs are different stories, not this IOS XE workflow hook.
Full Explanation
Terraform needs a provider block to know how to reach and authenticate to the target platform. When a city edge stack’s root lists VLAN and interface resources for IOS XE but never configures authentication or reachability, the missing piece is a provider block for the IOS XE / Cisco device with those details. Without it, plan and apply cannot manage the resources against real campus switches no matter how complete the HCL resource bodies look.
An AWS landing-zone module that replaces the need for any device provider fails because campus IOS XE is not configured by AWS account scaffolding alone. A Puppet agent certificate as Terraform’s only supported reachability path mixes tools and is not how Terraform providers authenticate to network devices. A Meraki Dashboard API key stored as the Terraform backend lock confuses remote-state locking with device provider credentials and targets the wrong platform for this IOS XE stack.
Exam caveat: backend configuration stores state; provider configuration talks to the device—both may exist in a mature workflow, but the stem’s gap is the device provider. Use variables and a secret store for passwords and tokens in civic pipelines.
Operational check: add the provider with lab credentials, re-run plan, and confirm Terraform can refresh and read device-backed resources instead of failing on missing provider configuration.