Walking the deployment interface
This lesson is different from the others, and it is worth saying why up front. A LangSmith organization is provisioned for each candidate, and smith.langchain.com is one of the two whitelisted sites. That means some questions in this domain are answered by navigating rather than by recalling, and the person who has already clicked around answers them in twenty seconds while the person meeting the interface cold spends three minutes finding the left-hand nav.
One honesty note before we start. Interfaces get redesigned, and exact button labels are the least durable thing anybody can teach you. What follows is structural: the hierarchy, what each level owns, and which question each view answers. Where I name a section I am describing its role rather than guaranteeing its caption.
The hierarchy, top down
The containment runs from your organization, through a workspace or project grouping, down to individual deployments, and inside a deployment down to the runtime objects you already know: assistants, threads, runs.
That path matters more than any single screen, because the level tells you what the view can answer. The organization level owns the things that were decided once and cannot be moved, and the region is the sharpest example: it was chosen at organization setup, it is independent of where your company is, and there is no migration. The deployment level owns the served unit. The runtime objects live inside it.
What each level answers
At the deployment level you are asking operational questions. Which build is currently serving? What preceded it? What is the environment configured with? Is this thing healthy, and what has it been doing? Revision history, environment configuration and deployment status all belong here.
At the assistant level you are asking configuration questions. What settings does this named configuration carry, what versions does it have, and which one is promoted?
At the thread and run level you are asking “what actually happened”. This is where a conversation’s state and a run’s execution live, and it is where LangSmith tracing meets deployment: the trace of a run is the record of the work, while the thread’s checkpointed state is the record of the result.
Studio, which is not tied to any of it
Studio is described as “a specialized agent IDE”, and the important fact about it is architectural rather than visual: it talks to any server implementing the Agent Server API protocol. Local langgraph dev server or a deployed one, it does not care, because it is speaking the protocol rather than being granted a tier.
It offers Graph Mode and Chat Mode, and it supports time-travel debugging. That last capability is downstream of a storage decision you learned about in a completely different context: you can only travel back through time that was written down, and checkpoints are what wrote it down.
The five-minute drill worth doing while you have wifi
Open the organization. Walk down to a single run and name every level you pass. Then find, and note the path to, four things: revision history, environment configuration, an assistant’s version list, and a run’s trace. Those four paths cover most of what an interface-shaped question can ask, and having walked them once converts a three-minute question into a twenty-second one.
Try it yourself
Why the interface itself is examinable
This lesson exists for a specific reason about how the exam is administered, and knowing the reason changes how you study it.
A LangSmith organization is provisioned for each candidate. What does that imply about how some questions in this domain are meant to be answered?
Reveal answer
That some questions are answered by looking, not by recalling. With a provisioned organization and smith.langchain.com whitelisted, a question about where a setting lives or what a view shows can be resolved by navigating to it. That makes familiarity with the interface a scoreable skill in its own right: the candidate who has clicked through the deployment views before knows where to go in seconds, and the candidate meeting the interface for the first time under the clock spends a question's entire time budget orienting.
Where you would look for revision history
You want to confirm which build is currently serving traffic and what preceded it. Which level of the hierarchy holds that?
Show answer
Correct answer: D — The deployment, since a revision is a version of the deployment
A revision versions the deployment, so its history belongs to the deployment. The tempting wrong answer is the assistant, because assistants genuinely do carry a version history with promote and rollback, and the interface shows both kinds of history in visually similar ways: they are histories of different objects. Getting this right in the interface is the same skill as getting it right on paper, which is why the vocabulary lesson comes first and this one comes fourth.
Two minutes to find an environment variable
Under exam conditions, with a provisioned organization open, you need to check what a deployment's environment is set to. What is the fastest correct path?
Show answer
Correct answer: A — Open the deployment, then its settings or environment section, where that configuration is managed
Environment configuration belongs to the deployment, so it is managed in the deployment's own settings area. The tempting wrong answer is the assistant, because configuration is exactly the word assistants own and the confusion between assistant config and deployment environment is the single most reliably exploited one in this domain. Studio inspects graph execution rather than deployment settings, and a run trace is the wrong instrument for a static setting.
What Studio is and what it connects to
Studio is the piece of the interface that is not tied to a single deployment, which is exactly why it gets asked about.
How is Studio described, what can it connect to, and what two modes does it offer?
Reveal answer
Studio is described as a specialized agent IDE. It talks to any server implementing the Agent Server API protocol, which is why it works against a local server and a deployed one alike: it is protocol-based, not tier-based. It offers Graph Mode and Chat Mode, and it supports time-travel debugging, which pairs directly with checkpoints, since you can only travel back through history that was written down.
Walk the hierarchy before you are timed on it
Do this once with the interface open if you have connectivity, and once from memory if you do not. The second version is the one that counts.
- Write down the containment path from the top of the interface to a single run, naming every level you pass through.
- For each level, write the one question that level answers and the one question it cannot answer.
- Mark which level owns revisions, which owns assistant versions, and which owns environment configuration.
- Write down where you would go to answer each of these: is the deployment healthy, what did this conversation actually say, which build is live, and who is allowed to call this.