A tax-assessment service hardcodes localhost Redis and a compile-time JDBC driver path so developers can run “everything on one laptop.” Which cloud-native adjustment treats those collaborators correctly?
Select an answer to reveal the explanation.
Short Explanation
Backing services are like municipal utility hookups: you plug into water or power by address and credential, and you can point the hose at a different hydrant later. Hardcoded localhost and compile-time assumptions glue the service to one laptop. Rebindable URL-plus-credential attachments keep it movable.
Full Explanation
Cloud-native treatment of collaborators for the tax-assessment service is to treat databases, caches, and message fabrics as attachable URL-plus-credential resources you can rebind without rewriting the service. Hardcoded localhost Redis and a compile-time JDBC driver path couple the service to a laptop topology; the correct adjustment is configuration-bound backing services so the same build attaches to managed Redis or a database URL in each environment.
Forking every dependency into the application monorepo and compiling them as static libraries destroys independent lifecycle and operational management of those systems—you no longer attach a cache, you embed a fork. Binding permanently to a single named host so DNS never changes between environments fights rebinding and promotes fragile hostname coupling. Disabling network access and using only in-process mocks in production maximizes speed on a slide deck while removing the real collaborators the service needs to function.
Exam caveat: backing services are attached resources identified by locator and credentials, not compile-time fixtures and not production mocks; twelve-factor “backing services” is the concept, not a specific Redis SKU.
Operational check: point the same build at a non-localhost Redis URL and database URL via environment configuration, restart, and confirm the service operates without a code change or laptop-only driver path.