A permitting portal uses PostgreSQL, a message queue, and a Meraki Dashboard API endpoint. Which design treats those as 12-factor backing services?
Select an answer to reveal the explanation.
Short Explanation
Backing services are plug-in appliances—change the hose, not the engine. URLs and credentials attach the datastore, queue, and Meraki API; baking the production host into the binary treats them as source code.
Full Explanation
Backing services—databases, queues, and Cisco API endpoints—should attach by URL and credential so operations can retarget without changing application code. Treat Meraki, DNA Center, and datastore endpoints as attached resources: swap connection strings and tokens per environment while the civic binary stays constant. Hard-coding the production database hostname and Meraki base URL inside the compiled binary freezes topology into the artifact and forces rebuilds for routine moves. Requiring a code change and rebuild whenever the queue URL or credential location changes similarly treats configuration as source and slows incident response. Embedding a full Meraki SDK copy and a local SQLite file inside every release as “source, not attachments” blurs the backing-service boundary and couples releases to embedded state that does not scale across replicas. Exam caveat: attaching by URL still demands TLS validation, credential rotation, and network policy—attachment is not an excuse for cleartext or shared long-lived keys. Operational check: point the same image at a lab Meraki/DNA sandbox via injected URLs, exercise a read path, then retarget credentials to the next environment without rebuilding.