- Which action most directly restores the intended swap option?
Answer: Reload the family so the removed 1200 mm type is added to the project again.
Whenever you see a question about missing types in Revit, think about the project browser vs. the loaded family content. The Type Selector only shows types that currently exist in the project — if a type was purged, it's gone from the project database entirely, regardless of what the original family file contains.
When Purge Unused removes a family type like the 1200 mm door, it deletes that type's definition from the project. The 900 mm type remains because it had active instances, but the 1200 mm type is simply no longer part of the project. The most direct fix is to reload the family from its source file (via Load Family or through the Family Editor), which re-introduces all types defined in that family — including the previously purged 1200 mm type. Once reloaded, it reappears in the Type Selector and the swap can be made. This makes B the correct answer.
A is incorrect because clearing instance parameters has nothing to do with which types are available in a family — it only affects parameter values on a placed element. C is a red herring; pinning/unpinning controls whether an element can be moved or deleted, and has no relationship to which family types are loaded in a project. D is also wrong — phases control when elements appear in the project timeline, but they don't regenerate or restore purged type definitions. Phases and family types are completely separate concepts.
A useful rule of thumb: purging is permanent within a session — the only way back is reloading. On exam questions, watch for distractors that confuse element properties (phases, pins, parameters) with project content management (loaded types, families).
- What is the most direct way to make the family available for placement in Project B?
Answer: Load the RFA file into Project B directly, or reopen the family in the Family Editor and choose Project B as the load destination.
When working with families in Revit, it's important to understand that loading a family into a project is a per-project action — families are stored within each project file independently. The Family Editor's "Load into Project" command lets you choose which open projects receive the family at that moment, but any project you don't select simply doesn't get it. There's no automatic sharing or propagation between open projects.
Because the family was loaded only into Project A, the most direct fix is straightforward: either locate the original RFA file and use Insert > Load Family directly within Project B, or reopen the family in the Family Editor and use "Load into Project" again — this time selecting Project B as the destination. Both paths accomplish the same result efficiently. This makes B the correct answer.
A is wrong because synchronizing with a central file manages worksharing and model changes, not family definitions from sibling projects. Revit does not "discover" families loaded into other open projects during sync — that's simply not how the workflow operates.
C describes something that doesn't exist in Revit. The Type Selector is a placement interface element, not a transferable configuration. You cannot mirror family entries between projects by copying UI settings.
D is wrong because closing Project A has no effect on Project B's family library. Revit does not transfer families between projects when one closes — each project file remains entirely self-contained.
As a study tip: whenever a question mentions families being "missing" from a project, think load destination. The fix is almost always reloading the RFA directly into that project.
- Which action most directly makes the 1800 mm type available without recreating it manually?
Answer: Reload the family and select the 1800 mm entry from the type catalog.
When working with Revit families that include a type catalog, it's important to understand that the catalog acts as a filter at load time — you choose which types enter the project, and unchosen types are simply not loaded. They still exist in the source RFA and catalog files, waiting to be loaded on demand.
Because the 1800 mm type was never loaded into the project, the most direct fix is to reload the family. When you use Insert → Load Family on a family that's already in the project, Revit prompts you with the type catalog again. This time, you select the 1800 mm entry (along with any previously loaded types you want to keep), and Revit adds it to the project without disturbing existing instances. That's exactly what answer A describes, making it the correct choice.
Answer B is tempting but fundamentally flawed: duplicating the 1500 mm type and renaming it creates a new type with 1500 mm parameter values — the name changes but the dimensions don't. You'd have to manually edit every parameter to match the 1800 mm specification, which is error-prone and defeats the purpose of the catalog.
Answer C describes a feature that doesn't exist in Revit. The Type Selector only shows types already loaded into the project; there is no "display unloaded types" toggle.
Answer D stretches an instance geometrically, but instance-level dragging doesn't change the underlying type parameters, so the family's behavior and schedules remain incorrect.
As a study habit, remember: type catalogs control what gets loaded, not what exists. Any time a type is missing, your first instinct should be to reload the family and revisit the catalog selection.
- What is the expected result when the user chooses the second family's type from the Type Selector?
Answer: All selected chairs change type; their locations and instance Marks are retained.
When working with Revit's Type Selector, it helps to understand that the tool operates on all currently selected elements simultaneously, regardless of whether those elements belong to different family types. This question tests your understanding of how type-swapping behavior works across a multi-element selection.
When you select multiple chair instances — even if they span different types within the same family — and choose a new type from the Type Selector, Revit applies that new type to every selected instance at once. Each chair retains its position in the model because type changes don't affect instance placement. Critically, instance parameters like the Mark value are properties of the instance, not the type, so they are preserved through the swap. This makes A the correct answer: all selected chairs change to the new type, stay in place, and keep their unique Marks.
B is wrong because it describes behavior that doesn't exist in Revit — the Type Selector doesn't filter your selection based on which type was active when you first clicked. It acts on everything selected. C is incorrect because Marks are instance parameters and are never automatically reset during a type change; Revit only flags duplicate Marks, it doesn't clear them. D reflects a common misconception that mixed-type selections cause errors, but Revit handles this gracefully — selecting instances from different types is perfectly valid, and the Type Selector applies the new type uniformly.
As a study tip, remember the Revit rule: instance parameters survive type changes, type parameters do not. Any question involving Mark, Comments, or custom instance data during a type swap should lead you toward the answer that preserves those values.
- Which workflow correctly addresses the reason the target type is unavailable?
Answer: Create or obtain an equivalent Casework-category family, load it, and then swap the type.
Whenever you see a question about swapping family types in Revit, the core concept being tested is category-based filtering. The Type Selector only displays types that belong to the same category as the currently selected element. This is a foundational rule in Revit's family system — categories aren't just organizational labels, they control scheduling, visibility, and, critically, which types are interchangeable.
This is exactly why D is correct. A Casework element and a Furniture family are assigned to different categories, so Revit will never list a Furniture type in the Type Selector of a selected Casework element — no workaround exists within the Type Selector workflow. The only legitimate solution is to have a family in the Casework category that matches your visual intent, then load and swap to that type. This respects Revit's category architecture rather than fighting it.
Option A is incorrect because Match Type Properties copies parameter values between elements of the same type — it doesn't reassign category membership or allow cross-category type swapping. Option B is a common misconception: family names have no bearing on category assignment. Renaming a Furniture family to match a Casework family doesn't change its category, so it still won't appear in the Casework Type Selector. Option C describes functionality that simply doesn't exist in Revit — you cannot drag a family type onto an element to override its category restriction.
As a study tip, remember this pattern: in Revit, category is destiny. Whenever a type isn't appearing where you expect it, ask yourself whether the categories match — that's almost always the root cause on exam questions like this.
- Which action accomplishes the change with the least unintended impact?
Answer: Select the one table and choose the 1500 mm type from the Type Selector.
Whenever a Revit question asks you to change one instance without affecting others, you need to distinguish between type-level changes and instance-level changes. Type parameters in Revit apply to every element sharing that type — so modifying a type affects the entire family type, not just one element.
Selecting the single table and choosing 1500 mm from the Type Selector (option C) is the correct approach. The 1500 mm type is already loaded, so you're simply reassigning that one instance to a different, pre-existing type. The 19 remaining tables stay on the 1800 mm type, completely untouched. This is the most surgical, lowest-risk action available.
Option A is tempting but dangerous: if "Length" is a type parameter (as it typically is for furniture families), editing it on a selected instance may prompt Revit to either change the entire type or be unavailable at the instance level entirely — neither outcome is safe. Even if it were an instance parameter, bulk-editing all 20 selected tables would change all of them, not just one. Option B directly edits the 1800 mm type's Length parameter, which would resize all 20 tables simultaneously — the exact opposite of what the scenario requires. Option D reloading the family and overwriting parameter values would push changes across every placement of that family type in the project, causing widespread unintended impact.
Study tip: On Revit exam questions, the phrase "only one must change" is a signal to use the Type Selector on a single selected instance — never edit a type when instance-level reassignment is possible.
- When reloading the revised family, which option should be selected?
Answer: Overwrite the existing version, but do not overwrite its parameter values.
When reloading a family into Revit, you face a critical decision: how much of the existing project data gets overwritten. This question tests your understanding of the two reload options and when each is appropriate.
Because the geometry fix lives inside the family file itself, you need the updated family loaded into the project. However, the Width parameter was deliberately customized at the project level (850 mm instead of the library's 900 mm), and that customization must survive the reload. Option A — overwrite the existing version but not its parameter values — does exactly this. Revit replaces the family's geometry and internal definitions while preserving any type parameter values you've already edited in the project. This is the precise tool designed for this scenario.
Option B is the trap most students fall into. Choosing to overwrite the family and all parameter values would reset Width back to 900 mm, erasing the intentional project customization — the opposite of what the scenario requires.
Option C is impractical and unnecessary. In-place families are reserved for unique, site-specific geometry that can't be a loadable family. Creating one here adds complexity without solving the problem.
Option D misunderstands how family reloading works. Deleting instances before reloading is not required by Revit and would cause significant rework — you'd lose all placement data for those windows.
A useful rule of thumb: whenever a question describes a scenario where some project-side values must be protected during a family reload, the answer will almost always involve the "do not overwrite parameter values" option. Recognizing that distinction between family-side and project-side data is key on this exam.
- Which placement workflow best preserves the sensor's intended relationship to the ceiling?
Answer: Start Place a Component, choose Place on Face, and select the ceiling's underside.
When working with face-based families in Revit, the key question to ask yourself is: what is this family designed to host? Face-based Generic Models are specifically built to attach to a surface — and that surface becomes their host, maintaining the family's orientation and positional relationship even if the host moves or rotates.
For a sensor that must sit flush against a sloped ceiling's underside, option D is the correct workflow. Choosing Place on Face and clicking the ceiling's underside tells Revit to bind the family instance to that specific face. The sensor will inherit the ceiling's slope, stay perpendicular to it, and follow it if the ceiling ever changes elevation. This is exactly what face-based families are designed to do.
Option A is a workaround that introduces unnecessary steps and risks misalignment — swapping families after placement doesn't guarantee the new family will host correctly to the ceiling face. Option B, using Place on Work Plane at floor level, ignores the ceiling entirely; the sensor would float at the wrong elevation with no connection to the sloped surface. Option C places the family as unhosted, meaning it has no parametric relationship to the ceiling at all — manually aligning it is fragile and won't update if the ceiling changes.
The study tip here: whenever a question involves a face-based family, the correct placement method will always involve selecting the intended host face directly. Revit's family categories (hosted vs. unhosted vs. face-based) determine which placement modes are meaningful — knowing that distinction will help you eliminate distractors quickly on the exam.
- What should the user do to place an instance of the loaded family?
Answer: Start the Door command and select the loaded door type from the Type Selector.
Whenever you see a question about placing families in Revit, the key concept to keep in mind is that commands are category-specific. Revit organizes families into categories (Doors, Windows, Furniture, etc.), and each placement command only surfaces families belonging to its matching category.
The "Place a Component" command (found under Architecture > Component) is designed for Generic Model families and similar non-hosted component categories. Because the loaded family belongs to the Doors category, it simply won't appear in the Type Selector while that command is active — the tool is filtering it out by design. The correct approach, answer A, is to use the dedicated Door command (Architecture > Build > Door), which correctly filters and displays all door-category families, including your newly loaded one. You'll then find it available in the Type Selector.
Answer B is a trap — reloading the family doesn't change its category, so it still won't appear under Place a Component. The family is already loaded successfully, as confirmed by its presence in the Project Browser. Answer C is tempting because dragging from the Project Browser can work in some scenarios, but for hosted families like doors, which require a wall host, dragging directly into the drawing area typically doesn't initiate the proper hosted placement workflow. Answer D would actually break the family — changing its category to Generic Models strips away door-specific behavior like wall hosting and door schedules.
The study tip here: always match your placement command to the family's category. If a family isn't showing up in the Type Selector, ask yourself whether you're using the right command for that category.
- Which sequence should the user follow before placing the equipment?
Answer: Set the active work plane to the named reference plane, then use Place on Work Plane.
Whenever you see a question about placing work plane-based families in Revit, think about the work plane system — Revit uses the active work plane to determine where hosted elements land, and that plane must be explicitly set before placement begins.
Work plane-based families rely on whichever plane is currently active in the session. If you haven't changed it, Revit defaults to the view's associated level, which is why placement goes to the wrong location even though the family loads correctly. The fix is to first navigate to Architecture (or Structure) tab → Work Plane → Set, select the named reference plane from the list, and then use Place on Work Plane during the placement command. That sequence — set the plane, then place — is exactly what C describes, making it correct.
A is wrong because you can't reassign a view's associated level to a reference plane; levels and reference planes are distinct datum elements, and a view's level association isn't interchangeable with a reference plane.
B is tempting but backward — placing first on the wrong host and then "swapping" isn't a native Revit workflow. There is no built-in swap command that changes a family's host from a level to a reference plane after placement.
D confuses family reloading (which updates type parameters and geometry) with work plane behavior. Reloading the family does nothing to the active work plane, so the placement problem persists.
As a study tip: on Revit exam questions about family placement errors, always check whether the active work plane is the culprit before looking at family settings or view properties — it's the most common source of "wrong location" placement issues.
