In Postman, where does a mock server get the replies it serves, and who can change them?
answer
- The replies were not written for the mock
- Look inside the collection, not beside it
- Saved examples are the reply set
- Held in an account, not your repository
- Collection edit right is reply edit right
basics
~20 sA Postman mock server replies with the examples already saved beside the requests in the collection it was created from. Those examples live in a Postman account, and anyone allowed to edit that collection can edit them.
solid answer
~50 sA Postman mock server has no reply set of its own. It answers with the **examples already saved beside the requests** in the collection it was created from, so the same document that describes a call also supplies the canned answer to it — definition, documentation and double in one artefact. That document is held in a Postman **account**, not in a file your repository tracks, which means the replies are governed by that account's membership rather than by your review process. There is no second permission boundary between the request and the reply: whoever may edit the collection's requests may edit the examples the stand-in answers with. The anatomy of a saved example belongs to the collection-format subject; what matters here is the arrangement — the reply set is somebody else's copy of a document your history never records.
go deeper
Be ready to say plainly that the replies are the examples already saved in the collection, and that the collection lives in an account rather than in your repository. That single sentence is what the screen is testing.
Explain the consequence: because the reply set is the collection's own examples, editing a request and editing a reply need the same permission, and there is no build step between an edit and what a consumer receives.
Show that you treat this as a custody question. Say what you would keep in your own repository, and how a consumer would find out that a reply changed when nothing in your history did.
Own the boundary call: which delivery paths may depend on content governed by an account outside your accountability boundary, and what the exit costs if that account stops being available to you.
## What the stand-in actually answers with A **mock server** in Postman is a hosted stand-in for a service: consumers aim their calls at it instead of at the real thing and get replies back before the real thing exists. What makes the Postman arrangement distinctive is not that a stand-in exists — every ecosystem has those — but **where its replies come from**. They are not authored into the mock as a separate artefact. They are the **saved examples that already sit beside the requests in the collection**: the same document a person opens to fire a call by hand, and the same document that renders as that collection's documentation for readers. So one document plays three parts at once: - it is the **definition** — the list of calls a consumer may make; - it is the **documentation** — what a reader is shown about each call; - it is the **double** — the source of the replies the stand-in hands back. No conversion step turns one of those into another. There is no compile, no publish-to-a-stub, no second copy that could fall behind the first. That is the whole appeal, and it is also the whole exposure. ## Where the reply set lives The collection is held in a **Postman account** on the vendor's side, not as a file your repository tracks. That single fact drives most of the interview conversation: - your version control holds **no record** of an edit to a reply; - your branch protection, code owners and pull-request review do not reach it; - the same commit of your build can see different replies on two different days; - the people who can change it are the people that account admits, which is not the same set as the people who can merge to your default branch. ## Who may change it The edit right here is simply **collection edit right**. There is no second boundary between "the request I send" and "the reply the stand-in gives", because they are two halves of the same saved document. Anybody trusted to add a request or correct a path in that collection is, by exactly that trust, able to change what the double answers with. This is not a misconfiguration to be tightened away; it is the shape of the arrangement, and a strong candidate designs around it instead of assuming a gate is there. ## The two ledgers | Question | Your repository | The hosted collection | |---|---|---| | Where does a change appear? | as a diff on a branch | inside somebody's account | | Who approves it? | reviewers you name | whoever that account trusts | | When do you learn of it? | at review time | when a consumer's call fails | | What is the audit trail? | your commit history | outside your history entirely | | How do you undo it? | revert the commit | ask the holder to undo it | ## Why teams take the trade anyway Say the upside out loud in an interview, or you sound merely opposed: 1. **No extra authoring.** The examples already exist, saved by somebody who was exploring the real service; the stand-in costs no second artefact and no second maintenance job. 2. **Documentation and double cannot disagree.** A reader and a consumer are looking at the same saved bytes, so the documented reply is the served reply by construction. 3. **Nothing to operate.** Uptime, hosting and lifecycle are somebody else's problem. The cost is the mirror image of each of those: you have handed the contents of a build dependency to an account you may not hold, with no diff of yours, no review of yours, and no revert of yours. ## What an interviewer is testing The question looks like trivia and is not. It separates the candidate who has only clicked the button from the one who has thought about **custody**. The answer that scores names the source (saved examples in the collection), the location (an account, not your repository) and the permission (collection edit right is reply edit right), and then draws the consequence: a dependency that can change without anything in your history changing. ## Where this subject ends Keep the boundary crisp — several neighbouring subjects own the parts that are not this one: - the **anatomy of a saved example** inside the collection document belongs to the collection-format subject; - **stub servers you start and operate yourself**, and managed stub services whose reply set is not a collection, are different subjects; name them here only as a boundary; - **how a stand-in picks which canned reply to return**, and what it does with a call it does not recognise, is service-virtualization material; - **keeping a stand-in honest against the real service** is its own subject. This one is about custody and edit rights, not fidelity.
- If nobody writes a stub definition, what is the authoring cost of this arrangement?Close to zero, which is its main appeal. The examples were saved by somebody exploring the real service, so the stand-in reuses work that already happened. The cost moves elsewhere: you now depend on content held in an account you may not hold, changeable by anyone who may edit that collection, with no diff and no revert on your side.
- Does a change to the served reply pass through your repository's review?No. The replies are the collection's own examples, held in an account rather than tracked by your version control, so your pull-request review, code owners and branch protection never see the change. Whatever review that account applies is the only review there is, and the first person on your side to notice is usually a consumer whose call fails.
It is like a restaurant whose menu photographs are also the meal: change the picture and the plate that arrives changes, and anyone who may reprint the menu may do it.
saying these in an interview costs you the question
- Says the mock server keeps its own separate reply catalogue
- Assumes the replies were recorded from the real service
- Thinks changing a reply needs a permission separate from editing
- Believes the collection is tracked in the team's repository
- Treats the documented reply and the served reply as different things