Autodesk Revit Quiz: Nested Families
10 questions · exam conditions
0:00
Nested FamiliesQuestion 1 of 10

A manufacturer creates a desk family containing a nested power module. In the project, the desk must appear in a Furniture schedule, while each power module must be tagged and counted separately in an Electrical Fixtures schedule.

Which family configuration best supports these requirements?

Keep the power module non-shared and add its electrical data as parameters in the desk family.
Mark the power module as shared before nesting it, and retain its Electrical Fixtures category.
Change the power module to the Furniture category and mark its identifying parameters as shared.
Create the power module as a model group and place the group inside each desk family type.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Nested Families

Practice Nested 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 Nested 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

A manufacturer creates a desk family containing a nested power module. In the project, the desk must appear in a Furniture schedule, while each power module must be tagged and counted separately in an Electrical Fixtures schedule.

Which family configuration best supports these requirements?

  1. Keep the power module non-shared and add its electrical data as parameters in the desk family.
  2. Mark the power module as shared before nesting it, and retain its Electrical Fixtures category. (correct answer)
  3. Change the power module to the Furniture category and mark its identifying parameters as shared.
  4. Create the power module as a model group and place the group inside each desk family type.
Explanation: When you see a question about nested families in Revit, focus on two key concepts: category and shared status. A family's category determines which schedule it appears in, and marking a nested family as "shared" is what allows it to surface independently in the project — rather than being absorbed invisibly into its host family. For a power module to appear in its own Electrical Fixtures schedule and be individually taggable, it must do two things: belong to the Electrical Fixtures category, and be marked as Shared within the family editor before nesting. Shared nested families behave as independent instances in the project, meaning Revit counts and tags them separately from the host desk. This is exactly what option B describes, making it the correct configuration. Option A fails because keeping the power module non-shared means it disappears into the desk family — its data might live as parameters, but it won't appear as a separate row in any schedule or be independently taggable. Option C creates a category conflict: changing the power module to the Furniture category would merge it into the desk's schedule context, defeating the goal of separate Electrical Fixtures reporting. Marking parameters as "shared" (a different concept from shared families) doesn't resolve the category problem. Option D is fundamentally flawed because model groups cannot be nested inside loadable families — groups exist at the project level, not the family editor level. A useful rule of thumb: whenever a nested component needs its own schedule row or tag, the answer almost always involves making it shared while keeping its correct category intact.

Question 2

A lighting fixture family must support several interchangeable nested lamp modules. The modules have different geometry and photometric data but are all created in the same family category. The project team wants to choose the module from the host fixture's Type Properties.

Which setup most directly provides this behavior?

  1. Create a text type parameter containing the exact name of the desired nested module type.
  2. Create a Family Type parameter for the module category and assign it to the nested component. (correct answer)
  3. Create a Yes/No type parameter for each module and overlap all modules at the same location.
  4. Mark every module as shared and use project filters to select the required module type.
Explanation: When working with nested families in Revit, the key concept being tested here is Family Type parameters — a special parameter type that lets you swap one loaded family type for another directly from the host family's properties. Whenever you see a question about interchangeable nested components controlled from a parent family, think "Family Type parameter." Option B is correct because a Family Type parameter, scoped to the lamp module's category, creates a dropdown in the host fixture's Type Properties listing every loaded type of that module family. You assign this parameter to the nested component instance, and swapping the parameter value swaps the geometry and data of that nested element — exactly what the project team needs. Option A fails because a text parameter simply stores a string of characters. Revit has no mechanism to read that text and automatically substitute a different nested family type — it's purely informational and requires manual workarounds outside normal Revit workflows. Option C is problematic because stacking multiple overlapping components at the same location creates geometry conflicts and doesn't provide clean type-driven control. Managing visibility through Yes/No parameters for every module becomes unwieldy and error-prone as the module count grows. Option D misunderstands the role of the Shared Family setting. Marking families as shared makes their instances schedulable and selectable independently in the project, but it does nothing to create a type-selection mechanism inside the host fixture's properties. Project filters control visibility, not which module is active. As a study tip: memorize that Family Type parameters are the Revit-native solution for "swappable nested components." If a question describes interchangeable sub-elements controlled from a parent family, option B's pattern is almost always the answer.

Question 3

An accessory must be nested in a cabinet family and constrained to the cabinet's front panel. The same accessory will later be reused on panels with different thicknesses and orientations. The current accessory was created as a wall-hosted family and cannot be placed on the panel in the cabinet Family Editor.

Which revision is the most appropriate?

  1. Recreate the accessory as a face-based family and place it on the cabinet panel's face. (correct answer)
  2. Keep the accessory wall-hosted and mark it as shared before loading it into the cabinet.
  3. Convert the cabinet panel into a wall category element so it can host the existing accessory.
  4. Load both families directly into the project and combine them as a model group.
Explanation: When nesting families in Revit, the hosting behavior of the nested family determines whether it can be placed inside the parent family's editor. A wall-hosted family requires an actual wall element as its host — it cannot be placed on geometry like a cabinet panel, regardless of how that panel looks or behaves. This is the core concept being tested here. The right move is choice A: recreating the accessory as a face-based family. Face-based families attach to any planar surface — a floor, ceiling, wall, or modeled solid face like a cabinet panel. This makes them highly flexible for reuse across panels with different thicknesses and orientations, which is exactly the scenario described. Once recreated as face-based, the accessory can be placed directly on the cabinet panel's face inside the Family Editor and will adapt as the panel geometry changes. Choice B is tempting but misses the point — marking a family as "shared" controls whether nested instances appear independently in schedules and can be selected in the project, but it does nothing to change the family's hosting requirements. A wall-hosted shared family still needs a wall to be placed. Choice C is a workaround in the wrong direction. Converting the cabinet panel into a wall category element would compromise the cabinet family's integrity, introduce category conflicts, and create downstream issues with scheduling and visibility — it's not a sustainable or appropriate solution. Choice D sidesteps the problem entirely. Loading both families into a project and grouping them doesn't create a proper nested relationship, and the accessory wouldn't be constrained to the panel. As a study tip: whenever you see a nested family placement problem in Revit, immediately ask yourself what hosting type the nested family uses — that single decision drives everything else.

Question 4

A non-shared nested bracket family is used inside an equipment host family. After changing the bracket geometry in its source RFA file, the author opens the project and finds that existing equipment instances still display the old bracket.

Which workflow most reliably updates the nested geometry in the project?

  1. Rename the revised bracket type, load it into the project, and let Revit replace matching nested geometry.
  2. Reload the revised bracket directly into the project, because all nested copies reference the source RFA automatically.
  3. Purge the bracket from the project, reopen the project, and allow Revit to retrieve the revised source file.
  4. Reload the revised bracket into the equipment family, save it, and then reload the equipment into the project. (correct answer)
Explanation: Whenever you see a question about nested families in Revit, think in terms of the family hierarchy: a nested family lives inside a host family, not directly inside the project. That chain of containment is exactly what determines the correct update workflow. Because the bracket is nested inside the equipment family, the project never holds a direct reference to the bracket's RFA — it only knows about the equipment family. To get the revised geometry into the project, you must first update the bracket inside the equipment family editor, then push the updated equipment family into the project. That's precisely what D describes: reload the bracket into the equipment family, save it, and reload the equipment into the project. This respects the two-step hierarchy and guarantees every equipment instance reflects the new bracket geometry. A is a trap rooted in a misunderstanding of how Revit matches nested components. Renaming a type doesn't trigger automatic replacement — Revit matches by family and type name on reload, so renaming actually breaks the link rather than fixing it. B is wrong because non-shared nested families are not independently referenced by the project. They are embedded within the host family, so reloading the bracket directly into the project has no effect on instances that host it through the equipment family. C describes a workflow that doesn't exist in Revit. Purging unused elements removes content with no references; it doesn't cause Revit to "re-fetch" an external source file on reopen. As a study habit, always map the family nesting depth before choosing an update strategy — each level in the hierarchy requires its own reload step.

Question 5

A nested shelf family has Width defined as a type parameter. It is placed once inside a cabinet family. The cabinet author wants a Width parameter on each cabinet instance to resize only that instance's nested shelf, without creating additional cabinet or shelf types.

What change is required before the desired association can be made?

  1. Mark the shelf as shared, then use a cabinet instance parameter with the same parameter name.
  2. Keep the shelf Width as a type parameter and associate it directly with a cabinet instance parameter.
  3. Change the shelf Width to an instance parameter, reload it, and associate it with a cabinet instance parameter. (correct answer)
  4. Keep both parameters type-based and enable reporting on the cabinet's Width parameter.
Explanation: Whenever you see a question about nested families and parameter associations in Revit, focus on one core rule: a type parameter in a nested family can only be driven by a type parameter in the host family. Instance-to-type associations are not permitted. This is the constraint that shapes the entire question. To give each cabinet instance its own shelf width without creating new types, you need a cabinet instance parameter controlling the shelf. But that association is only valid if the shelf's Width is also an instance parameter. So the required fix is exactly what C describes: change the shelf's Width from a type to an instance parameter, reload the shelf family into the cabinet, and then associate it with a cabinet instance parameter. This unlocks the instance-level flexibility the scenario demands. Option A is a trap — marking a family as "shared" controls whether nested instances appear independently in schedules and can be tagged, but it does nothing to change how type vs. instance parameter associations work. Sharing alone won't enable the desired behavior. Option B describes something Revit simply won't allow: you cannot directly associate a nested family's type parameter with a host instance parameter — the parameter types must match in scope. Option D misunderstands reporting parameters entirely; reporting parameters read geometric values (like constraints) back into the family, they don't enable cross-scope type/instance associations. As a study tip, remember the matching rule: instance drives instance, type drives type. When a question asks about controlling a nested family parameter from the host, always check whether the scopes align — if they don't, the nested parameter must be changed first.

Question 6

A family author selects the Shared checkbox for a nested pump family. The author then expects every parameter in the pump to become a shared parameter and appear automatically as editable fields in the host family's schedule.

Which statement correctly distinguishes these concepts?

  1. The Shared setting exposes every pump parameter in the host's category schedule, regardless of parameter binding.
  2. The Shared setting converts all pump family parameters into shared parameters when the host is reloaded.
  3. The Shared setting makes the pump independently recognized in the project; parameter sharing and schedule fields are configured separately. (correct answer)
  4. The Shared setting only shares the pump's geometry, while parameter values remain fixed in the source family.
Explanation: Whenever you see a Revit question about nested families and the "Shared" checkbox, separate two distinct concepts in your mind: instance recognition and parameter visibility. These are related but not the same thing, and confusing them is exactly the trap this question sets. Marking a nested family as Shared does one specific thing: it tells Revit to treat that nested component as an independently schedulable and taggable element within the project, rather than as an invisible part of its host. A nested pump marked Shared will appear in a Mechanical Equipment schedule on its own. However, this setting says nothing about which parameters are exposed or editable at the host or project level. To surface specific pump parameters in a schedule, you must separately associate those parameters — typically through shared parameters — and bind them to the appropriate category. That reasoning confirms C as correct: the Shared setting handles recognition; parameter configuration is a separate workflow. A is wrong because Shared does not automatically expose every pump parameter in a schedule. Parameters must be explicitly mapped and scheduled — Revit won't do this wholesale just because a family is marked Shared. B is wrong because the Shared checkbox does not convert existing family parameters into shared parameters upon reload. Shared parameters must be created deliberately through the Shared Parameter file and then assigned. D is wrong because the Shared setting has nothing to do with geometry versus values — it's entirely about how the project database identifies the nested component. As a study tip: on Revit exam questions, watch for answers that overstate what a single setting does. Revit separates concerns deliberately — recognition, parameter binding, and scheduling are each configured independently.

Question 7

A door family contains a nested handle family. The handle geometry currently uses a fixed stainless-steel material. The author wants one Material parameter in the door Type Properties to control the finish of the nested handle.

Which sequence correctly establishes this control?

  1. Parameterize the handle geometry's material, reload the handle, and associate that parameter with a door Material parameter. (correct answer)
  2. Assign the handle to a door subcategory, reload it, and map that subcategory to a door Material parameter.
  3. Mark the handle as shared, reload it, and assign the door's material directly through Object Styles.
  4. Give the door and handle Material parameters identical names, allowing Revit to link their values automatically.
Explanation: When working with nested families in Revit, the core challenge is creating a parameter "chain" that passes control from the host family down into the nested one. Think of it like a relay — the nested family must first expose a parameter, and then the host family must catch it. The correct approach, option A, follows this exact relay. First, you open the handle family and replace the fixed stainless-steel material assignment with a Material parameter — this makes the handle's finish controllable from outside. Then you reload the handle back into the door family. Finally, inside the door family editor, you select the nested handle instance and associate its exposed Material parameter to a new or existing Material parameter on the door itself. Now, whatever material a user sets in the door's Type Properties flows directly into the handle's geometry. Option B confuses subcategories with parameters. Subcategories control visibility and graphic overrides (line weight, color), not material assignments driven by type parameters. Mapping a subcategory to a Material parameter is not a valid workflow in Revit. Option C misunderstands the "shared" setting. Marking a family as shared allows its elements to be scheduled and tagged independently in the project, but it has nothing to do with linking material parameters between host and nested families. Object Styles also control graphics, not parametric material values. Option D describes a feature that simply doesn't exist in Revit. Matching parameter names between two separate families does not create any automatic link — parameter association must be explicitly wired inside the family editor. Remember: nested family parameter control always requires explicit association inside the host family editor — Revit never links parameters automatically based on names alone.

Question 8

A laboratory casework family contains a nested sink. For some casework instances, the sink must be hidden while the rest of the casework remains visible. The choice must be made separately for each placed casework instance.

Which configuration best meets the requirement?

  1. Associate the sink's Visible property with a type Yes/No parameter in the casework family.
  2. Assign the sink to a unique subcategory and turn that subcategory off in selected casework instances.
  3. Mark the sink as shared and hide its category in the view containing each affected casework instance.
  4. Associate the nested sink's Visible property with an instance Yes/No parameter in the casework family. (correct answer)
Explanation: When working with nested families in Revit, the key question is always visibility scope: should a visibility control affect all instances of a family type equally, or can each placed instance behave differently? That distinction points directly to the difference between type and instance parameters. The requirement here is per-instance control — some casework instances hide the sink, others show it, all from the same family. The correct approach, D, is to associate the nested sink's Visible property with an instance Yes/No parameter. Because it's an instance parameter, each placed casework element carries its own independent value, letting you toggle the sink's visibility on a case-by-case basis directly in the Properties palette. A is close in structure but wrong in scope. A type Yes/No parameter controls visibility for every instance sharing that family type simultaneously. If you hide the sink on one instance, it disappears on all instances of that type — you'd need a separate type for every visibility variation, which is impractical. B misunderstands how subcategory visibility works. Subcategories are controlled at the view level via Visibility/Graphics Overrides, affecting every element in that subcategory across the entire view — not selectively per instance. C introduces a shared nested family, which makes the sink schedulable and independent, but hiding its category in a view again affects all instances of that category in that view, not individual casework placements. The study tip to take away: whenever a question asks for per-instance control over a nested component's visibility, an instance Yes/No parameter driving the Visible property is almost always the answer.

Question 9

A casework host family contains a nested drawer family. The drawer already has an instance parameter named Depth. The designer wants users to change drawer depth by editing a parameter on the casework instance, without opening or directly selecting the drawer.

What should the family author do in the host Family Editor?

  1. Create a host instance length parameter and associate it with the nested drawer's Depth parameter. (correct answer)
  2. Create a project length parameter and apply it separately to the Casework and Generic Models categories.
  3. Rename the host depth parameter to exactly match the nested parameter, allowing automatic synchronization.
  4. Mark the drawer as shared and edit its Depth value independently after loading the casework.
Explanation: When working with nested families in Revit, the key concept being tested here is parameter association — the mechanism that lets a host family expose control over a nested family's parameters to the end user. Think of it as wiring: you're creating a visible control on the outside of a box that connects to something working inside. To give casework users control over the drawer's Depth without requiring them to select the drawer directly, the family author should create a new instance parameter of type Length on the host casework family, then associate it with the nested drawer's Depth parameter. You do this in the Family Editor by selecting the nested component and clicking the small gray button next to its Depth parameter in Properties — this opens a dialog where you can link it to a host-level parameter. Answer A correctly describes this workflow. B is wrong because project parameters live in the project environment, not inside family files. You cannot use them to wire together parameters within a Family Editor session. C describes a common misconception — Revit does not automatically synchronize parameters just because they share the same name. Name matching alone has no functional effect on nested family parameter inheritance. D misunderstands what "shared" means: marking a nested family as shared makes it independently schedulable and selectable in a project, but it does not create any parameter linkage to the host. Editing its Depth independently defeats the entire goal of seamless host-level control. As a study tip, remember that whenever a question involves controlling a nested family's behavior from the host, your answer almost always involves associating parameters — not renaming, not sharing, not using project parameters.

Question 10

A shared caster family is nested four times in a mobile cabinet family. After the cabinet is loaded into a project, a user can use the Tab key to highlight an individual caster. The user assumes that the caster is therefore unrelated to the cabinet.

Which statement most accurately describes the resulting relationship?

  1. Each caster is independently selectable and schedulable, but it remains a nested component placed through the cabinet. (correct answer)
  2. Each caster becomes a free-standing project instance whose placement no longer depends on the cabinet family.
  3. The casters remain inseparable geometry, and Tab selection only exposes their individual subcategories.
  4. The cabinet becomes a project group, with the casters acting as unhosted members of that group.
Explanation: When you encounter questions about nested families in Revit, the key concept to keep in mind is the distinction between selectability and independence. Just because you can isolate an element doesn't mean it exists outside its host hierarchy. In Revit, a shared nested family is specifically designed to allow its instances to be individually selected, tagged, and scheduled within a project — even though they were placed through a parent (host) family. When the mobile cabinet is loaded into the project, the four casters become selectable as discrete instances via Tab, and they can appear in schedules independently. However, their geometry, position, and existence are still governed by the cabinet family's definition. They are not free-floating elements; they are nested components whose placement logic originates from inside the cabinet family. Answer A correctly captures this dual nature: individual selectability and schedulability coexist with the casters remaining nested components. This is precisely what the "shared" designation enables. Answer B is incorrect because shared families do not become free-standing project instances. They cannot be moved or deleted independently of the cabinet — their positions are driven by the parent family. Answer C is wrong because Tab selection does far more than expose subcategories; it genuinely exposes individual schedulable and taggable instances. The geometry is not "inseparable" in the way C implies. Answer D is a fabrication. Revit does not convert loaded families into project groups, and casters do not become unhosted group members. This conflates the Group tool with the Family nesting workflow. Study tip: Always remember the "shared" checkbox in nested family settings — it's the toggle that unlocks individual schedulability without breaking the nesting relationship.