Autodesk Revit Quiz: Family Types
10 questions · exam conditions
0:00
Family TypesQuestion 1 of 10

A manufacturer wants to distribute a configurable laboratory cabinet. Users must be able to load it into unrelated projects, create multiple size types, and update its geometry without opening any particular building project.

Which family approach best satisfies all of these requirements?

Create a loadable family in an external RFA file and define the required cabinet types.
Create an in-place family in a sample project and copy its instances into other projects.
Create a system-family type in a template and distribute it through project standards.
Create separate in-place families for each size and place them in the relevant projects.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Family Types

Practice Family Types 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 Family Types, 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 wants to distribute a configurable laboratory cabinet. Users must be able to load it into unrelated projects, create multiple size types, and update its geometry without opening any particular building project.

Which family approach best satisfies all of these requirements?

  1. Create a loadable family in an external RFA file and define the required cabinet types. (correct answer)
  2. Create an in-place family in a sample project and copy its instances into other projects.
  3. Create a system-family type in a template and distribute it through project standards.
  4. Create separate in-place families for each size and place them in the relevant projects.
Explanation: Whenever you see a Revit question involving portability, reusability across unrelated projects, and geometry that can be edited independently, you should immediately think about the three family types: loadable (RFA), in-place, and system families — and which one supports standalone editing and distribution. Loadable families, stored as external RFA files, are purpose-built for exactly this scenario. You can open the RFA directly in the Family Editor, define multiple types (different cabinet sizes) within a single file, and distribute that one file to any project. Users simply load it in via Insert > Load Family — no source project required. This makes A the clear answer. B fails on multiple fronts: in-place families are embedded in the specific project where they're created. You cannot open them independently, you cannot export them as standalone RFA files, and copying instances between projects is not a reliable workflow for distributing configurable content. Each instance also lives in isolation, making type management nearly impossible. C is a trap for students who remember that system families (walls, floors, ceilings) can be transferred between projects via Project Standards. However, laboratory cabinets are not system families — system families are hard-coded into Revit and cannot be created by users or manufacturers. D compounds the worst problems of in-place families by multiplying them. Creating a separate in-place family per size eliminates any centralized type management and ties every version permanently to a specific project file. As a study tip: on Revit exam questions, "distribute to unrelated projects" and "edit without opening a project" are strong signals pointing to a loadable RFA family every time.

Question 2

A consultant sends a project containing approved floor types and approved furniture content. The recipient can use Transfer Project Standards for the floor definitions, while the furniture was originally supplied in separate RFA files.

Which explanation best accounts for the different transfer methods?

  1. Floor types are system-family types stored in projects, while furniture content is typically loadable from external family files. (correct answer)
  2. Floor types are in-place families transferred as standards, while furniture content is stored as project-specific system families.
  3. Floor types are loadable families embedded by category, while furniture content must always be recreated in each project.
  4. Floor types and furniture are both system families, but only furniture categories permit external backup files.
Explanation: Whenever you see a question about transferring content between Revit projects, the key distinction to recognize is the difference between system families and loadable families — because each type lives in a completely different place and moves through a completely different workflow. System families (like floors, walls, roofs, and ceilings) exist only inside a Revit project file. They cannot be saved as standalone files. Because they live within the project, Transfer Project Standards is the correct tool for moving them between projects — it reaches into one open project and copies those definitions into another. Floor types fall squarely into this category, which is exactly why A is correct: floor types are system-family types housed in the project, and furniture is a loadable family originally authored as an external RFA file that you load into any project on demand. B gets the descriptions backwards — floor types are not in-place families, and furniture is not a system family. In-place families are unique one-off geometry built inside a specific project, not standard floor assemblies. C is wrong because loadable families are not embedded by category and furniture doesn't need to be "recreated" — it's simply loaded from its RFA file. D is wrong because floors and furniture are emphatically not both system families; that false premise is the core misconception the question is testing. As a study tip, memorize the three Revit family types — system, loadable, and in-place — along with one clear example of each. Questions on this exam frequently test whether you can correctly categorize common elements like walls, floors, doors, and furniture into the right family type.

Question 3

Within one project, a designer duplicates a roof type to change its construction and duplicates a chair type to change type parameters. Both operations create new types visible in the Project Browser.

What can be concluded from these similar type-duplication workflows?

  1. Both items are system families because their types are duplicated inside the project environment.
  2. Both items are loadable families because each duplicated type can control instance geometry.
  3. The roof is in-place and the chair is system-based because both appear in the Project Browser.
  4. Type duplication alone does not determine classification; the roof is system-based and the chair can be loadable. (correct answer)
Explanation: Whenever you see a question about Revit family classification, remember that the workflow of working with families doesn't automatically reveal what kind of family they are. The key distinction is between system families (walls, roofs, floors — defined entirely within the project, never loaded from external files) and loadable families (furniture, doors, fixtures — created in the Family Editor as .rfa files and loaded into projects). Both system and loadable families support type duplication inside the project environment. A roof type can be duplicated to adjust its layer construction, and a chair family's type can be duplicated to change dimensions or materials — and both new types appear in the Project Browser. The fact that duplication works the same way tells you nothing definitive about classification. That's exactly what D captures: type duplication is a shared workflow, not a classifier. The roof is system-based (you cannot load a roof family from an .rfa file the way you load furniture), while the chair is almost certainly a loadable family loaded from an external file. Choice A is wrong because loadable families also support type duplication inside the project — being duplicatable doesn't make something a system family. Choice B is wrong for the inverse reason: system families support type duplication too, so duplication doesn't prove something is loadable. Choice C introduces in-place families, which is an entirely different category (geometry modeled directly inside the project for one-off conditions) and has nothing to do with what's described here. As a study strategy, always ask yourself: Can this family type exist as a standalone .rfa file? If yes, it's loadable; if it only exists within the project, it's system-based.

Question 4

A custom canopy was first modeled as an in-place family for a single building. The design is now approved for repeated use in many buildings, and the team wants one source definition that can be revised and reloaded.

Which change best aligns the content strategy with the new requirement?

  1. Keep copying the in-place family because repeated placement converts it into centrally managed system content.
  2. Rebuild it as a loadable family because an external source can support reuse and controlled updates. (correct answer)
  3. Convert it into a system family because any component used in several projects becomes system-defined.
  4. Create a separate in-place family in each project because external families cannot contain custom geometry.
Explanation: Whenever you see a question about content strategy in Revit, focus on the distinction between in-place families, loadable families, and system families — each serves a fundamentally different purpose. When a design moves from a one-off solution to something repeated across multiple projects, the key requirement becomes a single, centrally managed source that can be updated and reloaded wherever it's placed. That's exactly what a loadable family (.rfa file) provides: it lives outside any project file, can be revised in the Family Editor, and reloaded into as many projects as needed — making B the correct approach. Rebuilding the canopy as a loadable family gives your team one authoritative definition with full version control. Choice A is wrong because copying an in-place family doesn't convert it into anything centrally managed — each copy remains embedded in its host project with no shared source. Editing one copy has zero effect on others. Choice C reflects a fundamental misconception: system families (walls, floors, roofs) are built into Revit's architecture and defined by the software itself. You cannot convert a custom modeled component into a system family, nor does repeated use trigger that classification. Choice D is doubly wrong — creating separate in-place families per project multiplies the maintenance burden, and the claim that "external families cannot contain custom geometry" is false; loadable families support highly complex custom geometry. As a study strategy, remember this rule of thumb: in-place = one place, loadable = many places. Any time a question mentions reuse across projects or controlled updates, loadable families are almost always the right answer.

Question 5

A project team evaluates three proposed workflows: (1) add a new partition assembly by duplicating an existing wall type, (2) create a reusable parametric light fixture in the Family Editor, and (3) model a one-off sculptural feature directly in the building project.

Which workflow sequence correctly matches system, loadable, and in-place family use?

  1. System for the partition, in-place for the light fixture, and loadable for the sculptural feature.
  2. Loadable for the partition, in-place for the light fixture, and system for the sculptural feature.
  3. In-place for the partition, system for the light fixture, and loadable for the sculptural feature.
  4. System for the partition, loadable for the light fixture, and in-place for the sculptural feature. (correct answer)
Explanation: When working with Revit families, you need to distinguish three fundamental categories based on how and where elements are created and used. System families (like walls, floors, and roofs) exist only within a project and are modified by duplicating and editing their type properties — they cannot be loaded from external files. Loadable families are built in the standalone Family Editor, saved as .rfa files, and imported into any project, making them ideal for reusable components like furniture, fixtures, and equipment. In-place families are modeled directly inside the project environment for unique, context-specific geometry that won't be reused elsewhere. Applying this to the scenario confirms that D is correct: duplicating an existing wall type is textbook system family behavior — walls are a built-in system family modified within the project. Creating a parametric light fixture in the Family Editor describes a loadable family, since it's built externally and can be shared across projects. Modeling a one-off sculptural feature directly in the building project is precisely the use case for an in-place family. Choice A wrongly swaps the light fixture and sculptural feature, assigning "in-place" to something meant to be reusable. Choice B misidentifies walls as loadable, which is impossible — you cannot load a wall type from an .rfa file. Choice C incorrectly calls the partition "in-place" and the light fixture a "system" family, reversing the logic entirely. A useful memory anchor: System = built-in and project-only, Loadable = portable .rfa, In-place = unique and context-bound. On exam questions, watch for the word "reusable" as a signal for loadable families.

Question 6

A model contains a custom in-place casework element. It was assigned to the Casework category, appears in a casework schedule, and can be tagged using category-compatible annotation.

Which conclusion about the element's family classification is valid?

  1. It becomes a loadable family because scheduling and tagging require an external family definition.
  2. It becomes a system family because category assignment places it under Revit's built-in content classes.
  3. It remains an in-place family because category behavior does not change where its definition was created. (correct answer)
  4. It has no family classification because only externally saved components can belong to a model category.
Explanation: When you see a question about Revit family types, anchor yourself to one core principle: a family's classification is determined by where and how its definition was created, not by how it behaves inside the model. In Revit, there are three family types — system families (walls, floors, roofs), loadable families (external .rfa files), and in-place families (created directly within the project using the "Create In-Place" tool). An in-place family lives entirely inside the project file; its geometry and parameters are embedded there, not in a separate file. Crucially, assigning an in-place element to a category like Casework simply tells Revit how to treat it for visibility, scheduling, and tagging purposes — it does not change the family's origin or classification. This is why C is correct: category assignment is a behavioral setting, not a reclassification mechanism. A is wrong because scheduling and tagging are not exclusive to loadable families. In-place families support both features when assigned to a compatible category — no external .rfa definition is required. B is wrong because system families are predefined host elements (walls, ceilings, stairs) built into Revit's core — you cannot "become" a system family through category assignment; that classification is fixed at a platform level. D is wrong because in-place families absolutely belong to model categories; category membership is what enables them to appear in schedules and accept tags in the first place. Study tip: On Revit exam questions, always ask yourself where was the definition created? Category, scheduling behavior, and tagging capability describe what a family does — not what type of family it is.

Question 7

A BIM manager is organizing office content. Exterior wall assemblies are defined and duplicated within project templates. Standard doors are stored as separate RFA files and loaded into projects. A sculptural reception desk is modeled directly in one project because it will not be used elsewhere.

Which classification correctly identifies the three kinds of content described?

  1. Walls are system families, doors are loadable families, and the reception desk is an in-place family. (correct answer)
  2. Walls are loadable families, doors are system families, and the reception desk is an in-place family.
  3. Walls are system families, doors are in-place families, and the reception desk is a loadable family.
  4. Walls are in-place families, doors are loadable families, and the reception desk is a system family.
Explanation: Whenever you see a Revit question about family types, anchor your thinking to three distinct categories: system families, loadable families, and in-place families. Each has a unique storage method and use case. System families are built into Revit and exist only within project files or templates — you cannot save them as standalone RFA files. Walls, floors, roofs, and ceilings all fall here. Their types are defined and duplicated inside the project or template itself, exactly as described with the exterior wall assemblies. Loadable families are created externally as RFA files and loaded into any project on demand. Standard doors, windows, furniture, and fixtures follow this pattern. The passage explicitly mentions doors stored as separate RFA files and loaded into projects — the textbook definition of a loadable family. In-place families are modeled directly within a single project for geometry that is unique to that context and won't be reused elsewhere. The sculptural reception desk, built inside one project with no intent to reuse it, fits perfectly. This makes A the correct answer. Choice B swaps walls and doors, incorrectly calling walls loadable and doors system families — the opposite of reality. Choice C misidentifies doors as in-place families and the reception desk as loadable, which contradicts the passage: the desk has no RFA file and is project-specific. Choice D makes the biggest error, calling walls in-place families and the reception desk a system family — in-place families cannot be built-in Revit constructs, and system families are never unique one-off models. Your study tip: memorize that walls = system, RFA files = loadable, one-project-only = in-place. Revit exam questions almost always test these three categories as a set.

Question 8

An architect duplicates a Basic Wall type, changes its compound structure, and then looks for a standalone RFA file containing the revised wall so it can be edited outside the project.

Why will the architect not find the revised wall as a normal standalone family file?

  1. The wall is an in-place family whose source geometry is embedded permanently in the active project.
  2. The wall is a system family whose types are defined in projects or templates rather than ordinary RFA files. (correct answer)
  3. The wall is a loadable family, but Revit conceals its RFA file while the type is used in a project.
  4. The wall is a nested family whose source file can be accessed only through its host component.
Explanation: Whenever you see a question about Revit families, your first instinct should be to identify which type of family is involved — because Revit has three distinct categories, each with fundamentally different behaviors. Basic Walls (along with Floors, Roofs, Stairs, and similar elements) are system families. Unlike loadable families, system families are not stored as external RFA files on disk. Instead, their type definitions live inside the project file (RVT) or template file (RTE). When you duplicate a Basic Wall type and modify its compound structure, that new type exists only within your project. There is no corresponding file to open in File Explorer because none was ever created — this is why B is correct. Choice A is wrong because in-place families are a specific subcategory of loadable families that you model directly inside a project for unique, one-off geometry. A duplicated Basic Wall type is not modeled in place; it's a system family type definition. Choice C is wrong because it describes an impossible behavior — Revit does not "hide" or conceal RFA files for active types. Loadable families always have an accessible source file; concealment simply isn't a Revit concept. Choice D is wrong because nested families are loadable families embedded inside another loadable family's RFA file. That scenario has nothing to do with wall types or system families. A useful way to remember this: if you can find it in the Load Family dialog, it's loadable and has an RFA. If it lives in the Type Properties of elements like walls, floors, or roofs, it's a system family — project-bound by design.

Question 9

A renovation project requires one irregular enclosure that follows existing warped construction. The enclosure will occur only once, must be modeled as solid geometry, and has no anticipated value in another project.

Assuming no suitable standard component or system-family tool can produce the required form, which approach is most appropriate?

  1. Create a loadable family because every solid model element must originate in an RFA file.
  2. Create an in-place family because the geometry is unique and is needed only in this project. (correct answer)
  3. Create a system family because any enclosure that affects a room must be project-defined.
  4. Create a system-family type because duplicating a type permits unrestricted custom solid geometry.
Explanation: When a question describes geometry that is unique, project-specific, and cannot be produced by standard tools, Revit is pointing you toward the in-place family workflow. The key diagnostic factors here are: one-time use, irregular/warped form, and no reuse value elsewhere. An in-place family (answer B) is created directly inside the project environment, uses the full solid-modeling toolkit (extrusions, sweeps, blends, voids), and lives permanently within that single project file. It is precisely designed for one-off conditions — like matching warped existing construction — where building a separate loadable family would add unnecessary complexity with no benefit. Answer A is a common misconception. Not every solid element requires an RFA file. In-place families produce genuine solid geometry without ever leaving the project file. The claim that solid models must originate in RFA files is simply false. Answer C misrepresents system families entirely. System families (walls, floors, roofs, ceilings) are built into Revit's core and cannot be created from scratch — they are configured, not authored. No "enclosure" condition forces you into a system family, and system families cannot produce arbitrary freeform solids. Answer D compounds the same misunderstanding. Duplicating a system-family type lets you adjust parameters like thickness or material, but it does not unlock freeform solid modeling. You cannot sculpt warped geometry by duplicating a wall type. Study tip: Memorize the three-part decision rule — loadable family for reusable components, system family for host-dependent elements (walls, floors, etc.), and in-place family for unique, project-only geometry that defies standard tools.

Question 10

A door is hosted by a wall, has several configurable sizes, and appears under the Doors category. A team member concludes that it must be a system family because it depends on a system-family wall.

Which response most accurately evaluates the team member's conclusion?

  1. It is correct because any component hosted by a system family becomes part of that system family.
  2. It is correct because categories such as Doors and Windows can contain only system-family elements.
  3. It is incorrect because a hosted door can remain a loadable family stored and edited as an RFA file. (correct answer)
  4. It is incorrect because all wall-hosted components are automatically created as project-specific in-place families.
Explanation: Whenever you see a question about Revit family types, anchor yourself to the three-family framework: system families (walls, floors, roofs — defined inside the project, no RFA file), loadable families (doors, windows, furniture — created in the Family Editor and saved as .RFA files), and in-place families (one-off geometry built directly in the project). The team member's error is confusing hosting relationship with family classification. A door being hosted by a wall simply means the door needs a wall to exist — it cuts an opening into that host. This is a placement dependency, not a classification rule. The door itself remains a loadable family: it was built in the Family Editor, saved as a .RFA file, and loaded into the project. You can edit it outside the project, share it across projects, and configure multiple type sizes within a single family file. That makes C correct — a hosted door is still a loadable family stored as an RFA. A is wrong because hosting is a geometric relationship, not a classification mechanism. Nothing a system family "hosts" inherits system-family status. B is wrong because the Doors and Windows categories absolutely contain loadable families — in fact, that is their primary population. Categories do not restrict family type. D is wrong because wall-hosted components are not automatically in-place families; in-place families require you to explicitly use the Create In-Place command, and they are project-specific by definition. Your study tip: always ask yourself where does the geometry live? If it lives in an RFA file and was loaded via the Load Family command, it is loadable — regardless of what hosts it.