Autodesk Revit Quiz: Family Parameters
10 questions · exam conditions
0:00
Family ParametersQuestion 1 of 10

A casework family has a labeled depth dimension. In the project, every placed cabinet of the same family type currently changes when the depth is edited. The designer now wants individual cabinets of that type to have different depths without creating additional types.

Which modification to the family best provides the required behavior?

Change the existing depth parameter from Type to Instance, then flex and reload the family.
Keep the depth parameter as Type and enable reporting behavior for the labeled dimension.
Replace the labeled dimension with a locked dimension, then edit each cabinet in the project.
Create a new family type for the depth and assign that type to every individual cabinet.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Family Parameters

Practice Family Parameters 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 Parameters, 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 casework family has a labeled depth dimension. In the project, every placed cabinet of the same family type currently changes when the depth is edited. The designer now wants individual cabinets of that type to have different depths without creating additional types.

Which modification to the family best provides the required behavior?

  1. Change the existing depth parameter from Type to Instance, then flex and reload the family. (correct answer)
  2. Keep the depth parameter as Type and enable reporting behavior for the labeled dimension.
  3. Replace the labeled dimension with a locked dimension, then edit each cabinet in the project.
  4. Create a new family type for the depth and assign that type to every individual cabinet.
Explanation: Whenever you see a Revit question about controlling parameter values per placed instance without multiplying family types, you're being tested on the Type vs. Instance parameter distinction — one of the most fundamental concepts in Revit family authoring. In a Revit family, a Type parameter stores a single value shared by every element of that type in the project. Change it once, and every cabinet updates simultaneously — exactly the behavior described in the scenario. Converting that parameter to an Instance parameter means each placed cabinet holds its own independent value, so you can give cabinet A a 24" depth and cabinet B an 18" depth while both remain the same family type. After switching the parameter scope in the Family Editor, you flex the dimension to confirm the geometry still responds correctly, then reload into the project. That process is precisely what answer A describes, making it correct. Answer B is wrong because "reporting" behavior on a labeled dimension is used to read a driven dimension value and pass it to a parameter — it doesn't allow per-instance control of depth, and it doesn't change whether the parameter is Type or Instance. Answer C is wrong because locking a dimension removes its parametric flexibility entirely, preventing any future edits regardless of where they originate — the opposite of what's needed. Answer D is wrong because creating a new family type for each depth value is exactly what the designer wants to avoid. That approach multiplies types rather than leveraging instance flexibility. Study tip: On Revit family questions, the phrase "without creating additional types" is a strong signal that the answer involves converting a Type parameter to an Instance parameter.

Question 2

A face-based support family must measure the distance from its hosting face to a constrained connection point. That measured distance changes with host conditions and will be used in a formula that calculates the cut length of a rod.

How should the distance dimension be parameterized?

  1. Label it with a normal Type parameter so the family drives the host-dependent distance.
  2. Label it with a reporting Length parameter and reference that value in the rod formula. (correct answer)
  3. Lock the dimension without a label and use its displayed value in the rod formula.
  4. Label it with an Integer parameter and convert the measured value within the rod formula.
Explanation: Whenever you see a Revit family question involving a dimension that reads a real-world condition rather than driving geometry, you're being tested on the distinction between driving parameters and reporting parameters — a critical concept for face-based and adaptive families. In this scenario, the distance between the hosting face and a connection point isn't something the family controls; it varies based on where the family is placed. That's exactly what a Reporting parameter is designed for. When you label a dimension with a Reporting Length parameter, Revit reads the current dimension value and feeds it into the parameter — making it available for use in formulas. Your rod formula can then reference that parameter directly to calculate the correct cut length dynamically, no matter how host conditions change. Answer B is correct for this reason. A is wrong because a normal Type parameter drives the dimension — it pushes a fixed value onto the geometry rather than reading from it. Using a Type parameter here would override the host-dependent distance, defeating the entire purpose. C fails because locking a dimension without a label makes it invisible to any formula. You cannot reference an unlabeled dimension value in a calculation; it's simply not exposed as a parameter. D is wrong on two counts: Integer parameters store whole numbers only, which would truncate precision critical in length calculations, and no parameter type — Integer or otherwise — can passively read a dimension value unless it is specifically designated as a Reporting parameter. A useful rule of thumb: if a dimension measures something the host controls, use a Reporting parameter; if the family controls it, use a standard parameter.

Question 3

A linear lighting family uses an array of identical nested lamps. The first and last lamps must remain at two fixed reference planes as the overall fixture length changes. A user-controlled parameter must change the number of lamps while keeping them equally distributed between those endpoints.

Which array and parameter configuration best meets the requirement?

  1. Use Move To: Last, lock every individual member to its own reference plane, and label the overall fixture length with a reporting parameter.
  2. Use Move To: 2nd, constrain only the second member to a reference plane, and label the member spacing with a Length parameter.
  3. Use Move To: Last, constrain the first and last members to the fixed reference planes, and label the array count with an Integer parameter. (correct answer)
  4. Use Move To: 2nd, constrain the first and last members to the fixed reference planes, and label the array count with a Length parameter.
Explanation: When working with linear lighting families in Revit, the key concept being tested is how array behavior and parameter types interact to produce flexible, constrained geometry. Ask yourself: which array mode keeps endpoints fixed, and which parameter type controls count? Revit arrays offer two modes: Move To: Last and Move To: 2nd. "Move To: Last" means the final member stays pinned at its position while intermediate members distribute evenly between the first and last — exactly what you need when both endpoints must anchor to fixed reference planes. "Move To: 2nd" instead controls the spacing between the first and second members, cascading outward, which means the last member's position floats freely as count changes. Answer C is correct because it combines all three requirements correctly: "Move To: Last" locks the array between two fixed endpoints, constraining the first and last members to their respective reference planes ensures the fixture always spans exactly that distance, and labeling the count with an Integer parameter is appropriate since lamp count is a whole number — not a continuous dimension. Answer A fails because locking every individual member to its own reference plane defeats the purpose of an array; you'd need to manually manage each lamp's position as count changes. Answer B uses "Move To: 2nd," which lets the last lamp drift beyond the fixed endpoint, and labeling spacing rather than count gives the user the wrong kind of control. Answer D mixes "Move To: 2nd" (wrong mode for endpoint control) with a Length parameter for count — Length is a continuous distance type, not suitable for whole-number lamp counts. Remember: when endpoints must stay fixed and count must vary, Move To: Last + Integer parameter is your go-to combination in Revit array families.

Question 4

A door-panel family must display several opening positions in the project. The panel rotates about a fixed hinge point, and each placed door must be able to use a different opening angle without creating new family types.

Which setup provides the most reliable angular parametric behavior?

  1. Dimension the panel edge directly and label the angle with a Type reporting parameter.
  2. Constrain the panel to a fixed reference plane and label a linear dimension with an Instance Length parameter.
  3. Constrain the panel to a pivoting reference line and label an angular dimension with an Instance Angle parameter. (correct answer)
  4. Lock the panel to the family center planes and assign its rotation to a Type Angle parameter.
Explanation: When building parametric families in Revit, the key question to ask is: "What geometry drives the motion, and what parameter type matches that motion?" A door panel rotating about a hinge is fundamentally an angular behavior, so your family setup must reflect that from the ground up. The most reliable approach is C — constraining the panel to a pivoting reference line and labeling an angular dimension with an Instance Angle parameter. A reference line in Revit has inherent directionality and can pivot, making it the correct host for angular constraints. Labeling that angular dimension as an Instance parameter means each placed door instance can carry its own opening angle independently, without requiring a new family type. This directly satisfies the scenario's requirement for per-instance variation. Option A fails because a Type reporting parameter reads values rather than driving them — it can't control geometry. It also wouldn't allow per-instance variation since Type parameters are shared across all instances of that type. Option B applies a linear (Length) parameter to what is inherently a rotational relationship; a linear dimension cannot meaningfully describe an angle, so the geometry would either fail to constrain properly or produce unpredictable results. Option D uses a Type Angle parameter, which would force every door of that type to share the same angle — you'd need a new type for every opening position, directly violating the stated requirement. As a study strategy, remember this pairing rule: angular motion → reference line + angular dimension + Angle parameter, and Instance vs. Type is determined by whether variation should exist within a type or between types.

Question 5

A parametric equipment family flexes correctly in the Family Editor. Its geometry is locked to left and right reference planes, and the distance between those planes is labeled Width. After loading the family, project users cannot reliably select the intended planes when aligning or dimensioning to the equipment.

Which family change most directly addresses the project-side problem without changing the width formula?

  1. Set the controlling planes' Is Reference property to Strong Reference or an appropriate named reference. (correct answer)
  2. Change Width from a Length parameter to a reporting parameter and reload the family.
  3. Remove the alignment locks and dimension directly to the equipment's visible solid edges.
  4. Set the controlling planes to Not a Reference and define both planes as the family origin.
Explanation: When building Revit families, reference planes serve two distinct roles: they drive geometry and they act as snap/selection targets in the project environment. The Is Reference property controls how visible and "catchable" a plane is to tools like Align, Dimension, and snapping. This question tests whether you understand that a family can flex perfectly while still being frustrating to use in a project if its planes aren't properly exposed. Option A is correct because setting the controlling planes' Is Reference property to Strong Reference (or a named reference like Left, Right, Center) makes those planes reliably selectable in the project. Revit prioritizes Strong References when users click near geometry, so the planes snap cleanly during alignment and dimensioning — exactly the missing behavior described. Crucially, this change is purely a reference-plane property; it doesn't touch the Width formula or any constraints. Option B is a trap. Reporting parameters read a measurement driven by geometry — they can't control dimensions. Converting Width to a reporting parameter would break the family's parametric behavior, not fix selection issues. Option C trades parametric control for a workaround. Locking geometry to reference planes is a best practice; removing those locks just to expose solid edges undermines the family's integrity and still doesn't give users reliable, intentional reference targets. Option D contradicts itself. Only one plane can be the family origin, and setting both controlling planes to Not a Reference makes them invisible to project-side tools — the exact opposite of the fix needed. Study tip: On Revit exam questions, distinguish between what makes a family flex (constraints and formulas) and what makes it usable in a project (Is Reference settings). These are independent systems that both deserve attention.

Question 6

A family already has a dimension between two reference planes labeled Overall Width. A second value named Nominal Width must always equal Overall Width for data use. A designer places another dimension between the same planes and labels it Nominal Width, causing a constraint conflict.

What is the best correction?

  1. Keep both labeled dimensions and change Nominal Width from Length to Integer.
  2. Unlock both reference planes and keep the two parameters independently editable.
  3. Delete the Overall Width label and make both dimensions reporting parameters instead.
  4. Remove the second dimension and set the Nominal Width formula to Overall WidthOverall\ Width. (correct answer)
Explanation: Whenever you see a question about Revit family parameters and constraints, ask yourself: how should these values relate to each other, and what is the cleanest way to enforce that relationship? Revit uses labeled dimensions to drive geometry, and applying two separate labeled dimensions to the exact same pair of reference planes creates a redundant constraint — Revit cannot satisfy two independent drivers controlling one distance simultaneously, which causes the conflict described. The cleanest fix is answer D: delete the second dimension entirely and use a formula in the Nominal Width parameter definition so that Nominal Width=Overall WidthNominal\ Width = Overall\ Width. This way, one dimension drives the geometry, while Nominal Width remains a parameter that updates automatically, stays synchronized, and is available for schedules and data extraction — with zero constraint conflict. Answer A fails because changing a parameter's type from Length to Integer does nothing to resolve the geometric over-constraint; two labeled dimensions on the same planes still fight each other regardless of data type. Answer B is dangerous: unlocking the reference planes removes the geometric constraint entirely, meaning the model could flex in unintended ways and the two parameters would no longer be guaranteed to match. Answer C is counterproductive — reporting parameters are read-only values that report a dimension without driving it, so deleting Overall Width and making both reporting would strip you of any ability to control the width through parameters at all. The study tip here: in Revit families, when two parameters must share the same value, always use a formula (ParamA=ParamBParamA = ParamB) rather than duplicating the driving dimension. One dimension drives geometry; formulas handle dependent relationships.

Question 7

A manufacturer family contains an extrusion whose width must be controlled by a parameter. The extrusion may later be replaced with more detailed geometry, but the same width parameter must continue to work reliably.

Which modeling sequence provides the most stable parametric behavior?

  1. Dimension the extrusion edges, label that dimension, and leave the reference planes unconstrained.
  2. Dimension two reference planes, label the dimension, and lock the extrusion edges to those planes. (correct answer)
  3. Lock the extrusion sketch dimensions, then place unlabeled reference planes at matching locations.
  4. Dimension symbolic lines, label the dimension, and align the extrusion loosely with those lines.
Explanation: When building parametric families in Revit, think of reference planes as the skeleton of your geometry. Parameters should live on that skeleton — not on the geometry itself — so that when geometry changes, the parameter structure remains intact. This is exactly why B is the right approach. By dimensioning two reference planes and labeling that dimension as your width parameter, you create a stable, geometry-independent control system. You then lock the extrusion edges to those planes using Align + Lock. Now if you later swap the extrusion for a more complex solid, you simply lock the new geometry's edges to the same planes — the parameter never breaks because it was never attached to the geometry in the first place. A fails because leaving reference planes unconstrained means your extrusion edges have no reliable anchor. Even if the dimension label works initially, the geometry can drift or fail to regenerate correctly when the family is loaded or the parameter is changed. C gets things backwards. Locking sketch dimensions internally constrains the geometry to itself, not to named reference planes. When you replace that extrusion, those locked sketch dimensions disappear with it, and your unlabeled reference planes provide no parametric continuity. D is a common trap. Symbolic lines exist only in specific views and carry no 3D geometry constraint. Aligning an extrusion "loosely" to them provides no reliable parametric link — the word "loosely" alone signals instability. Study tip: In Revit family modeling, always ask "Would this parameter survive if I deleted the geometry?" If the answer is no, your parameter is on the geometry, not the skeleton — and that's a problem waiting to happen.

Question 8

A shelving family has a total height of 2000 mm2000\text{ mm}. The first and last shelf centerlines are each inset 100 mm100\text{ mm} from the ends. An integer parameter named Count is 55, and all shelf centerlines must be equally spaced.

Which parameter setup correctly calculates the centerline spacing?

  1. Use a Length parameter with the formula Spacing=(Height−2×Inset)/CountSpacing=(Height-2\times Inset)/Count.
  2. Use a Length parameter with the formula Spacing=(Height−2×Inset)/(Count−1)Spacing=(Height-2\times Inset)/(Count-1). (correct answer)
  3. Use an Integer parameter with the formula Spacing=(Height−Inset)/(Count−1)Spacing=(Height-Inset)/(Count-1).
  4. Use a Length parameter with the formula Spacing=(Height−2×Inset)/(Count+1)Spacing=(Height-2\times Inset)/(Count+1).
Explanation: When spacing equally distributed shelves in a Revit family, you need to think carefully about the difference between the number of shelves and the number of gaps between them. This is a classic "fence post" problem: with 5 shelves, you have only 4 intervals separating them. Here's the geometry: the first shelf sits 100 mm100\text{ mm} from the bottom, the last sits 100 mm100\text{ mm} from the top, so the total span available between the outermost centerlines is 2000−2×100=1800 mm2000 - 2 \times 100 = 1800\text{ mm}. With 5 shelves occupying that span, there are 5−1=45 - 1 = 4 equal gaps, giving Spacing=1800/4=450 mmSpacing = 1800 / 4 = 450\text{ mm}. This matches the formula in B: Spacing=(Height−2×Inset)/(Count−1)Spacing = (Height - 2 \times Inset)/(Count - 1), and using a Length parameter is correct because spacing is a distance, not a unitless integer. A divides by CountCount (5) instead of Count−1Count - 1 (4), which would produce 360 mm360\text{ mm} — this incorrectly treats the number of gaps as equal to the number of shelves, placing the last shelf inside the boundary rather than on it. C uses an Integer parameter for spacing, which is wrong because spacing is a dimensional length value. It also subtracts only one inset instead of two, misrepresenting the available span. D divides by Count+1Count + 1 (6), a formula appropriate for equally spacing items between two boundaries without landing on them — not the scenario described here. A quick study tip: always ask yourself whether you're counting objects or intervals. In Revit parametric families, this distinction determines whether you divide by nn, n−1n-1, or n+1n+1.

Question 9

A custom door family needs a parameter named Clear Opening. It must drive a labeled dimension, have one value per door type, and be available to a project tag created for the office standard.

Which parameter should be created in the family?

  1. A shared Length parameter configured as a Type parameter and assigned to the dimension label. (correct answer)
  2. A family Length parameter configured as an Instance parameter and assigned to the dimension label.
  3. A project Length parameter configured by category after the family is loaded into the project.
  4. A reporting Length parameter configured as a Type parameter and assigned to the dimension label.
Explanation: When a Revit family parameter needs to drive a dimension label and appear in project schedules or tags, you're being tested on the distinction between shared, family-only, and project parameters — and how each one behaves across the family-project boundary. A shared parameter is the only parameter type that carries its identity (via a shared parameter file GUID) from a family into the project, making it recognizable by tags and schedules. When you create a shared Length parameter, configure it as a Type parameter, and assign it to the dimension label inside the family editor, you satisfy all three requirements in the scenario: it drives geometry, it holds one value per door type, and it is available to a project tag. That makes A the correct choice. B fails on two counts: a plain family parameter (non-shared) is invisible to project tags, and configuring it as an Instance parameter means it varies per placement, not per type — contradicting "one value per door type." C describes a project parameter, which is added after loading and can feed schedules but cannot be assigned to a dimension label inside the family editor, nor can it be tagged with a standard tag. D uses a reporting parameter, which is a read-only parameter that reads a dimension value rather than driving it. Reporting parameters cannot be labeled on a dimension to control geometry — they only capture existing geometry values. A handy rule to memorize: shared = shareable across the family-project boundary for tagging; family-only = stays inside the family; project = stays inside the project. Whenever a question mentions tagging a custom family parameter, shared parameters are almost always the answer.

Question 10

A host panel family contains two occurrences of the same nested louver family. Within one placed panel, the left and right louvers must be able to have different widths. The host family has instance parameters named Left Width and Right Width.

Which setup allows the two nested louver widths to be controlled independently?

  1. Make the nested Width a Type parameter and associate both occurrences with Left Width.
  2. Leave the nested Width unassociated and label one host dimension across both louver occurrences.
  3. Make the nested Width a reporting parameter and associate both occurrences with Right Width.
  4. Make the nested Width an Instance parameter and associate each occurrence with its corresponding host parameter. (correct answer)
Explanation: When working with nested families in Revit, the key concept is parameter association: how values flow from the host family down to nested family instances. The critical distinction here is between Type and Instance parameters, and understanding that two occurrences of the same nested family can each be linked to different host parameters — but only if the nested parameter is set up correctly. To control two louver widths independently, the nested Width parameter must be an Instance parameter. This allows each placed occurrence of the louver family to hold its own value. You then associate the first occurrence's Width with the host's Left Width parameter, and the second occurrence's Width with Right Width. Each louver responds to its own host parameter independently — exactly what the scenario requires. That's why D is correct. A fails because a Type parameter is shared across all instances of that family type. If both louvers reference the same type, changing Width changes both simultaneously — you lose independent control entirely. B is incorrect because leaving the nested parameter unassociated means the host has no way to drive those widths at all. Labeling a single dimension across both occurrences would only capture a combined or average measurement, not separate control. C misuses Reporting parameters, which are read-only and designed to report a measured value back to the host — not to receive and apply a driven value. You cannot push a width value into a nested family through a reporting parameter. Study tip: On nested family questions, ask yourself: "Does each instance need its own value?" If yes, the nested parameter must be Instance type — Type parameters always lock all occurrences to the same value.