An enterprise architecture team is implementing local developer workstation and CI/CD pipeline integration testing for microservices using Google Cloud Emulators. Match each Google Cloud service emulator on the left with its corresponding configuration environment variable and functional testing behavior on the right.
- Cloud Pub/Sub EmulatorRequires exporting PUBSUB_EMULATOR_HOST and does not persist topic or subscription metadata across emulator process restarts.
- Cloud Spanner EmulatorRequires exporting SPANNER_EMULATOR_HOST and supports in-memory schema DDL and DML operations, but lacks support for Cloud KMS customer-managed encryption keys (CMEK).
- Cloud Firestore EmulatorRequires exporting FIRESTORE_EMULATOR_HOST and supports evaluating security rules alongside local document read/write operations.
- Cloud Bigtable EmulatorRequires exporting BIGTABLE_EMULATOR_HOST and operates as a lightweight gRPC server without supporting backup/restore operations.
Answer
Each Cloud Emulator maps to its corresponding host environment variable and capability profile: Cloud Pub/Sub uses PUBSUB_EMULATOR_HOST with ephemeral state; Cloud Spanner uses SPANNER_EMULATOR_HOST supporting DDL/DML without CMEK; Cloud Firestore uses FIRESTORE_EMULATOR_HOST supporting security rules testing; Cloud Bigtable uses BIGTABLE_EMULATOR_HOST over gRPC without backup/restore capabilities.
Each service emulator requires setting its distinct host environment variable (e.g., PUBSUB_EMULATOR_HOST, SPANNER_EMULATOR_HOST, FIRESTORE_EMULATOR_HOST, BIGTABLE_EMULATOR_HOST) so that Google Cloud client SDKs redirect traffic to local ports instead of production GCP endpoints. Furthermore, each emulator provides specific local capabilities (such as Firestore Security Rules testing or Spanner local DDL execution) while intentionally omitting cloud-scale production capabilities like CMEK or backup/restore.
Step-by-Step Solution
Key Concept
Google Cloud Emulators and Development Testing Frameworks
Estimated Time:1m 30s