- Which action best uses the host workset structure to improve opening performance?
Answer: Open the host model with Coordination Links closed so that the link instance on that workset is not loaded for the session.
Whenever you see a question about Revit worksets and performance, focus on the relationship between workset visibility at open time versus after the model is loaded — these are two very different moments with very different effects.
Worksets can be set to Closed when you open a host model, which tells Revit not to load the elements on that workset into memory at all. This is the key to answer A: by opening the host model with the Coordination Links workset closed, the link instance assigned to it is never loaded into the session, directly improving open performance and reducing memory overhead. This is the intended, supported workflow for managing large linked files through workset organization.
Answer B is wrong because hiding a category in a view is purely a visual setting — the linked file is still fully loaded into memory; you've just toggled its display. Hiding doesn't free any resources.
Answer C reflects a common misconception. The active workset determines where new elements you create are placed — it has absolutely no effect on which worksets Revit loads when opening the model. Changing the active workset before opening does nothing to bypass other worksets.
Answer D confuses editability with load state. Making a workset noneditable is a worksharing ownership action that controls who can modify elements — it does not unload or detach any linked files.
As a study tip, remember the distinction: Closed workset at open time = not loaded into memory. View visibility and editability settings operate on already-loaded content and never affect what Revit loads during the open process.
- Which sequence establishes an appropriate workshared-model workflow?
Answer: Enable worksharing, organize the resulting worksets, save the model as the central model, and have users create local copies.
Whenever you see a question about setting up collaborative work in Revit, anchor your thinking to the worksharing workflow sequence: one central model lives on the network, and each user works in their own local copy that syncs back to it. Getting the order of operations right is everything here.
The correct path is B. Starting from a standalone file, you first enable Worksharing (via the Collaborate tab), which automatically generates default worksets. You then organize those worksets to reflect logical divisions of the model (such as by discipline or building system), save the file to a shared network location as the central model, and finally have each team member use "Create New Local" to generate their own local copy. Edits flow from local files back to the central model through Synchronize with Central.
A is built on a fundamental misunderstanding — worksharing isn't something you enable in multiple separate files and then merge. There is exactly one central model; you cannot stitch independent files together through synchronization after the fact.
C confuses project templates with central models. A template (.rte) is a starting point for new projects — it carries standards and settings, not a live, shared model. Having each user create their own central model from a template defeats the entire purpose of a single shared source of truth.
D conflates Design Options with worksharing. Design Options let one user explore multiple design alternatives within a single file — they are not a collaboration or file-management tool and provide no mechanism for concurrent multi-user editing.
A good memory anchor: one central model, many local copies — that hierarchy never changes in Revit worksharing.
- What will happen to furniture elements in the coordination view?
Answer: They will be visible because the view template's explicit Show setting overrides the workset's global default.
Whenever you see a Revit question involving workset visibility, keep a clear hierarchy in mind: there is a global default (set when the workset is created or modified in the Worksets dialog), and then there are per-view overrides that can be set explicitly in Visibility/Graphics or enforced through a view template. These two levels are independent, and the per-view setting always wins when it is explicitly defined.
When the Furniture workset was created with Visible in all views cleared, that simply establishes the global default — it tells Revit to hide the workset in views that haven't been given an explicit instruction. A view template that explicitly sets the workset to Show is exactly that kind of explicit instruction. Because the coordination view's template directly overrides the default with a "Show" command, the furniture elements will be visible. Answer D is correct for this reason.
Answer A is wrong because it reverses the actual hierarchy — per-view explicit settings do override the global default; that is precisely what view-level controls are designed for. Answer B introduces the concept of the active workset, which governs only which workset newly created elements are placed on; it has nothing to do with visibility control for existing elements. Answer C confuses editability with visibility — a workset being editable (checked out by a user) is a worksharing ownership concept, completely separate from whether elements display in a view.
A good rule of thumb: in Revit, explicit beats default. Any time a view or view template makes a direct Show/Hide decision, it overrides the workset's global visibility setting.
- What is the most appropriate way for Maya to make the change while minimizing unnecessary ownership?
Answer: Modify the door and allow Revit to borrow that individual element, because neither the door nor its workset is owned.
Whenever you see a Revit worksharing question about making edits, focus on the principle of minimum necessary ownership — Revit is designed to let you borrow individual elements rather than locking down entire worksets unless you truly need to.
In this scenario, the door is unowned, the workset is unowned, and the project allows element borrowing. This is the ideal situation for element borrowing: Revit will automatically request ownership of just that one door when Maya attempts to modify it, without requiring her to claim the entire Interiors workset. That's exactly what makes B correct — it's the most targeted, least disruptive approach, and Revit handles the borrowing request seamlessly in the background.
A is tempting but represents a common anti-pattern. Making the entire workset editable reserves every element on it, blocking teammates from editing anything else on that workset. This is unnecessary when only one door needs to change. C is based on a misconception — elements on non-editable worksets can be borrowed individually; you do not need to move the element to your active workset to modify it. The active workset controls where newly placed elements land, not whether existing elements on other worksets are editable. D is flatly false — element borrowing coexists with other worksets being editable. Borrowing and workset editability are independent mechanisms.
As a study tip, remember: borrow the element, not the workset whenever possible. Questions that offer "make the whole workset editable" as an option are almost always testing whether you recognize that as unnecessary over-ownership.
- What is the expected result of renaming the workset in the Worksets dialog?
Answer: The existing workset receives the new name, while its elements and workset-based view overrides remain associated with it.
When working with worksets in Revit, it helps to think of a workset name as simply a label attached to a persistent internal object — not as a fundamental identifier that elements track independently. Renaming a workset in the Worksets dialog is essentially a metadata update: Revit changes what the workset is called, but everything associated with it — elements, visibility settings, and view overrides — remains linked through the workset's internal ID, not its display name.
This makes D correct. When you rename West Wing to Renovation Zone, Revit updates the name in place. All elements already assigned to that workset stay assigned, and any view-specific visibility overrides configured for that workset in coordination views continue to function without interruption. No manual reassignment or reconfiguration is required.
A is wrong because Revit does not create a parallel empty workset and strand the old elements behind. There is no duplication — the existing workset simply receives a new name. B describes behavior that doesn't exist; renaming a workset has no effect on element assignments or view overrides, and Revit certainly doesn't reset overrides as a side effect of a name change. C reflects a misunderstanding of how Revit stores workset membership. Elements don't hold an independent copy of the workset name — they reference the workset object itself, so a rename propagates automatically.
A good study tip: on Revit exam questions involving worksets, ask yourself whether Revit is tracking something by name or by internal reference. Most workset associations use internal references, which is why renaming, moving, or reorganizing worksets rarely breaks existing relationships.
- Which procedure should be used?
Answer: Delete Existing Survey in the Worksets dialog and choose the option to move its elements to the Site workset.
Workset management in Revit requires understanding how elements are assigned to worksets and what tools actually control that assignment. When you need to move elements from one workset to another and then eliminate the source workset, the key is using the Worksets dialog's delete function, which gives you a migration option for the orphaned elements.
When you delete a workset in Revit, the software prompts you to choose a destination workset for all elements currently assigned to it. This is the correct and intended workflow — select Existing Survey for deletion, then direct its elements to Site when prompted. That's exactly what option B describes, making it the right procedure.
Option A is tempting but fundamentally wrong: renaming a workset does not merge it with another workset of the same name. Revit treats workset names as labels only; two worksets cannot occupy the same identity, and renaming creates a conflict rather than a merge. Option C is a fabricated workflow — closing and reopening worksets controls their visibility, not element ownership or assignment. Elements don't "transfer" between worksets through visibility toggling. Option D misrepresents the Purge function entirely; purging in Revit removes unused families, materials, and view types — it has no mechanism for reassigning workset elements to an active workset. Making a workset active only determines where new elements are placed.
A useful pattern to remember: whenever a Revit question involves eliminating a workset while preserving its contents, think delete with migration. The delete workflow in the Worksets dialog is the only native tool that combines workset removal with controlled element reassignment in a single operation.
- Which action most completely updates the central model and releases Leon's ownership?
Answer: Synchronize with Central and relinquish all of his borrowed elements and owned worksets during that workflow.
When working in a Revit worksharing environment, you need to understand the difference between ownership and visibility. Borrowing an element or owning a workset means you hold an exclusive lock on that content — no one else can edit it until you explicitly release it. The question here tests whether you know which single workflow both pushes Leon's changes to the central model and surrenders his ownership of all locked content.
Synchronize with Central (SWC) is that workflow. During SWC, Revit prompts you with a dialog where you can choose to relinquish borrowed elements, user-created worksets, and project standards worksets individually or all at once. By checking all of those options, Leon accomplishes both goals simultaneously: his local changes are written to the central model, and his locks are released so teammates can immediately access that content. This makes C the correct answer.
A is wrong because simply saving locally and closing Revit does not automatically push changes to the central model or release ownership — a local save only updates Leon's own .rvt file, leaving the central model untouched and the locks intact.
B is wrong because closing a workset in the Worksets dialog only makes that workset inactive (unloaded from view), not relinquished. Ownership is a separate concept from a workset's open/closed visibility state.
D is wrong because detaching a local model severs its relationship with central entirely. It does not update or release anything in the original central model — it simply creates an independent copy.
As a study tip, remember that in Revit worksharing, only Synchronize with Central moves data bidirectionally and offers relinquishment options — saving locally or closing worksets never releases ownership.
- Which workflow best meets the consultant's objective?
Answer: Use Specify for worksets when opening the model, and open only Shell and Site before the model finishes loading.
Whenever you see a question about worksets and performance in Revit, the key concept is understanding when elements are loaded into memory — not just whether they're visible on screen.
When you open a Revit central model (or create a local copy), Revit gives you the option to Specify worksets before the file fully loads. This is the critical window: choosing which worksets to open means Revit only reads and loads those elements into RAM. The consultant who selects only Shell and Site through this dialog achieves exactly what the question asks — reduced memory footprint and faster load times from the start. This makes A the correct workflow.
B is a common trap. Opening every workset first loads all geometry into memory regardless of what you later hide. Workset visibility overrides in views are purely a display setting — they don't unload elements from RAM. The memory demand is already done.
C has the same fundamental flaw as B. Turning off categories in a view changes what you see, not what's loaded. Interiors and Furniture elements remain fully resident in memory; you've only suppressed their display.
D reflects a misconception about what the active workset does. Setting a workset as active only determines which workset newly created elements are assigned to — it has absolutely no effect on which worksets are opened or loaded into memory.
The study tip here: in Revit, visibility ≠ memory. Hiding elements in a view never reduces RAM usage. Only the Specify worksets option at open time, or later using the Close Worksets command, actually controls what's loaded.
- After the additional walls are placed, how will the workset assignments be distributed?
Answer: The existing walls will remain on Shell, while the additional walls will be assigned to Core as they are created.
Whenever you see a question about worksharing in Revit, focus on one core principle: the active workset controls newly created elements, but it never retroactively reassigns existing ones.
When you change the active workset — say, from Interiors to Core — you are simply telling Revit, "anything I create from this moment forward belongs to Core." Elements already placed in the model keep whatever workset they were assigned to at the time of creation. No automatic reassignment happens behind the scenes. This means the existing walls sitting on Shell stay on Shell, and your newly placed walls land on Core. That's exactly what answer C describes, making it correct.
Answer A is wrong because it assumes changing the active workset acts like a batch reassignment tool — it doesn't. The active workset is a placement setting, not an editing command. Answer B incorrectly suggests that new walls inherit their workset from nearby geometry. Revit has no such proximity-based inheritance rule; the active workset alone determines where a new element is assigned. Answer D introduces two false ideas: existing walls don't migrate to the previously active workset (Interiors), and new elements are never left "unassigned" — they always receive the current active workset at the moment of placement.
A useful tip for the exam: think of the active workset like a "stamp" you're using while drafting. Switching stamps changes only what gets stamped going forward — everything already on the page keeps its original mark. If you ever want to move existing elements to a different workset, you must select them and change their Workset property manually in the Properties palette.
- Which alternative is the most appropriate strategy for model organization and performance?
Answer: Use a limited set of logical worksets for collaboration or selective loading, and retain view templates and filters for display control.
When working with Revit worksets, it helps to understand their primary purpose: enabling collaborative multi-user editing and allowing selective loading of portions of a model. Worksets are not designed to replace visibility controls — that distinction is the heart of this question.
A well-structured workset strategy uses a small number of logical groupings (site, shell, interiors, MEP, etc.) so team members can borrow elements efficiently and so linked models or large files can be partially loaded to improve performance. Since the project already uses view templates and filters effectively, those tools should continue handling display control — they're purpose-built for it. Option C is correct because it keeps worksets focused on collaboration and selective loading, while preserving the existing, appropriate tools for category visibility.
Option A is a classic trap: workset closure can hide geometry, but using it as your primary visibility control method is unpredictable, slow to manage, and breaks the intended workflow. It's a workaround, not a strategy. Option B misunderstands workset ownership — Revit worksets are not meant to be permanently assigned per user. Ownership is dynamic; locking elements indefinitely to individuals creates bottlenecks and defeats collaborative flexibility. Option D swings too far in the opposite direction. The default workset alone cannot support selective loading or meaningful team coordination on large projects — additional logical worksets genuinely improve both.
A useful rule of thumb for the exam: worksets = collaboration and loading; filters and view templates = display control. When you see a question mixing these concepts, ask yourself which tool is being applied to the right job.
