Autodesk Revit Quiz: Placing And Swapping Families

10 questions · exam conditions

0:00

Placing And Swapping FamiliesQuestion 1 of 10

A door family has been loaded into a project from the Insert tab. The user then starts Component > Place a Component, but the newly loaded door does not appear in the Type Selector. The family is visible under Doors in the Project Browser.

What should the user do to place an instance of the loaded family?

Start the Door command and select the loaded door type from the Type Selector.

Reload the family while the Place a Component command remains active.

Drag the family name from the Project Browser into the drawing area.

Change the family's category to Generic Models before placing an instance.

← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Placing And Swapping Families

Practice Placing And Swapping Families in Autodesk Revit with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Placing And Swapping Families, giving you a quick way to practice the rules, question types, and explanations that matter most for Autodesk Revit.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

What should the user do to place an instance of the loaded family?

Start the Door command and select the loaded door type from the Type Selector. (correct answer)
Reload the family while the Place a Component command remains active.
Drag the family name from the Project Browser into the drawing area.
Change the family's category to Generic Models before placing an instance.

Explanation: 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.

Question 2

A window family has been revised externally to correct its geometry. In the project, the Width type parameter for an existing type was intentionally changed from the library value of 900 mm to 850 mm. The geometry correction is required, but the project's 850 mm value must remain.

When reloading the revised family, which option should be selected?

Overwrite the existing version, but do not overwrite its parameter values. (correct answer)
Overwrite the existing version and all of its parameter values.
Cancel the reload and create a separate in-place window family.
Delete every existing instance before loading the revised family again.

Explanation: 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.

Question 3

A face-based Generic Model family represents a sensor that must attach to the underside of a sloped ceiling. The family has been loaded, and the user is working in a view where the underside face can be selected.

Which placement workflow best preserves the sensor's intended relationship to the ceiling?

Place any Generic Model first and swap it to the sensor after positioning.
Start Place a Component, choose Place on Work Plane, and use the floor level.
Place the sensor unhosted at floor level and align it to the ceiling afterward.
Start Place a Component, choose Place on Face, and select the ceiling's underside. (correct answer)

Explanation: 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.

Question 4

A work plane-based equipment family must be placed on a named reference plane. The family loads successfully, but placement uses the current level rather than the intended reference plane.

Which sequence should the user follow before placing the equipment?

Change the view's associated level to the named reference plane, then place it.
Place the equipment on the current level, then swap it to the reference-plane type.
Set the active work plane to the named reference plane, then use Place on Work Plane. (correct answer)
Reload the family with parameter values overwritten, then restart the placement command.

Explanation: 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.

Question 5

A project originally contained 900 mm and 1200 mm door types from the same family. No instances used the 1200 mm type, and that type was selected during a Purge Unused operation. Later, a user needs to swap one door to 1200 mm, but only the 900 mm type appears in the Type Selector.

Which action most directly restores the intended swap option?

Select the door and clear its instance parameters before opening the Type Selector.
Reload the family so the removed 1200 mm type is added to the project again. (correct answer)
Temporarily unpin the door so all original family types become visible again.
Change the door's phase so the purged type is regenerated by the project.

Explanation: 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).

Question 6

Three chair instances use different types from one chair family. Each chair has a unique instance Mark. A type from a second chair family is already loaded, and all three selected chairs must be changed to that type while remaining in place.

What is the expected result when the user chooses the second family's type from the Type Selector?

All selected chairs change type; their locations and instance Marks are retained. (correct answer)
Only chairs matching the first selected chair's original type are changed.
All selected chairs change type, but their instance Marks are reset automatically.
The swap is rejected because selected instances currently use different family types.

Explanation: 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.

Question 7

Twenty identical tables use the 1800 mm type. Only one table must become the already loaded 1500 mm type. The remaining 19 tables must retain both their current type and dimensions.

Which action accomplishes the change with the least unintended impact?

Select all 20 tables and edit the selected instances' length parameter.
Edit the 1800 mm type and change its Length parameter to 1500 mm.
Select the one table and choose the 1500 mm type from the Type Selector. (correct answer)
Reload the family and overwrite the 1800 mm type's parameter values.

Explanation: 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.

Question 8

A manufacturer supplies an RFA file and a matching type catalog containing 12 desk sizes. When loading the family, the user selects only the 1200 mm and 1500 mm types. Later, a 1800 mm desk must be placed, but that type is absent from the Type Selector.

Which action most directly makes the 1800 mm type available without recreating it manually?

Reload the family and select the 1800 mm entry from the type catalog. (correct answer)
Duplicate the 1500 mm type in the project and rename it 1800 mm.
Open the Type Selector and enable the option to display unloaded types.
Place a 1500 mm instance and stretch it to the required overall length.

Explanation: 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.

Question 9

A user selects a Casework cabinet and wants to swap it with a visually similar family that was created in the Furniture category. Both families are loaded, but the Furniture type is not listed in the selected cabinet's Type Selector.

Which workflow correctly addresses the reason the target type is unavailable?

Use Match Type Properties to transfer the Furniture type to the cabinet.
Rename the Furniture family so its name matches the selected Casework family.
Drag the Furniture type onto the cabinet to override the category restriction.
Create or obtain an equivalent Casework-category family, load it, and then swap the type. (correct answer)

Explanation: 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.

Question 10

Two projects, Project A and Project B, are open along with a family in the Family Editor. The user chooses Load into Project, selects only Project A in the destination prompt, and then closes the family. The family can be placed in Project A but is absent from Project B.

What is the most direct way to make the family available for placement in Project B?

Synchronize Project B with its central file so that Revit discovers and imports families already loaded into other open projects.
Load the RFA file into Project B directly, or reopen the family in the Family Editor and choose Project B as the load destination. (correct answer)
Copy the Type Selector configuration from Project A into the Project B interface so the family entries are mirrored across both projects.
Close Project A so that Revit automatically transfers its loaded family definitions into the remaining open project.

Explanation: 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.