Quiz results are saved to your browser's local storage and will persist between sessions.
Why the sandbox publishes through Consul KV instead of terraform_remote_state, what breaks when an upstream repo hasn't published yet, and who should own a grant when the resource and the dependency point in opposite directions.
In a multi-repo Terraform setup using Consul KV instead of terraform_remote_state for cross-repo data sharing, what's the main advantage of the Consul approach?
terraform_remote_state creates a hard coupling to another repo's ENTIRE state file, including internal details it never meant to expose. A Consul KV write is closer to a service publishing an API contract — deliberate, versioned, and minimal. The tradeoff: nothing catches a field-name typo at plan time the way a typed module output would.
In a dependency chain repo-A → repo-B → repo-C (each publishing data the next consumes via Consul), repo-C fails with an 'Invalid index' error trying to read a key that's supposed to come from repo-A. What's the most likely root cause?
An 'Invalid index' on a specific nested key (not a connection error) means the JSON structure exists but is missing that particular branch — almost always because the actual upstream publisher (repo-A here) either hasn't been applied at all, or was applied with a condition (like a feature flag) that skipped creating the resource that would have populated it. Worth checking the specific missing key against what the publisher actually created before assuming Consul or the reading repo is broken.
Two data "consul_keys" blocks live side by side in the same file. One's path is parameterized by environment (${local.env_key}); the other is hardcoded to end in /default. The hardcoded one starts failing with an empty-string read. What's the most likely explanation?
That's exactly the kind of bug worth ruling other things out before finding: environment/terminal mismatch and wrong-workspace were both checked and ruled out with direct evidence first. The actual cause was found by reading the code directly — one key was parameterized, the structurally identical one beside it wasn't, and the publisher never wrote to the hardcoded path.
Two separate Terraform repos both try to create a google_secret_manager_secret_iam_member granting the same access — one references the other repo's service-account email via cross-repo data, the other only needs data it already has locally. Which one should actually own the grant?
If repo A must run before repo B (by design, e.g. A publishes data B consumes), then A cannot depend on data B produces — B doesn't exist yet when A runs. The grant belongs in whichever repo needs only data that's already available in the correct apply order, even if that repo isn't the one that "owns" the underlying resource in a data-modeling sense.
A local Consul dev agent (consul agent -dev, in-memory only) still has old KV data describing a service account, even though that service account's Terraform state was fully destroyed and rebuilt from scratch. Why?
Nothing connects a terraform destroy in one repo to Consul's own data. If a Consul key was published describing a resource that's since been destroyed and never republished (e.g. because the publishing repo hasn't been re-applied yet), the old data simply sits there until it's overwritten or manually flushed. This can cause confusing errors where GCP says a referenced resource doesn't exist, even though Consul "remembers" it fine.
A real production Consul deployment and the consul agent -dev used in this sandbox both work with identical Terraform HCL. What's actually different between them?
The provider and resource blocks are mechanically identical either way — only WHERE CONSUL_HTTP_ADDR points, and whether real ACL tokens protect it, differ. This is why -dev mode data can vanish or go stale with no warning: it's an intentionally minimal stand-in for a real shared service, not a smaller version of the same guarantees.