Design automated microservice provisioning workflow

WHAT THIS TESTS: Your ability to build a repeatable, self-service provisioning workflow (a golden path) and to reason about how multi-step automation fails and recovers.

A GOOD ANSWER COVERS: Model the flow as discrete, idempotent steps orchestrated by a workflow engine or a platform tool. Step one scaffolds code from a versioned template so every service starts consistent. Step two creates the Git repository and registers it. Step three commits CI/CD pipeline definitions. Step four provisions cloud resources declaratively through infrastructure as code, ideally via GitOps, where a pull request to a config repo is the single source of truth and a reconciler applies it. Capture inputs in a manifest so the whole thing is reproducible and auditable.

COMMON WRONG ANSWERS: A single linear shell script with no idempotency, no transaction boundaries, and no cleanup, so a mid-run failure leaves a repo without infra or infra without a repo.

LIKELY FOLLOW-UPS: How do you make the steps idempotent? What happens if step three succeeds but step four fails? How do you keep the template from drifting across hundreds of services? How do you handle secrets and permissions during provisioning?

ONE CONCRETE EXAMPLE: A developer fills a form naming the service and its team. The pipeline scaffolds from the template, creates the Git repo, opens a pull request adding the service to the GitOps infra repo, and on merge a reconciler provisions a namespace, database, and deployment. Suppose cloud resource creation hits a quota error midway. Because each step is idempotent and tracked, the workflow records partial state, alerts the platform team, and either retries after quota is raised or runs a compensating teardown so no orphaned repo or half-built infra lingers. Re-running the pipeline converges cleanly rather than duplicating resources.