- Which workflow produces the required result with the least risk of unintended changes?
Answer: Duplicate Partition-100, modify the duplicate, and assign the 12 walls to the new type
Whenever Revit questions describe a scenario where some but not all instances of a type need different properties, your first instinct should be: this requires a new wall type, not a type edit. Because wall construction (layer thickness) is a type property in Revit, any change to a type propagates instantly to every wall using that type — including walls in views you haven't opened. That's the core risk the question is testing.
Duplicating Partition-100 and modifying the copy is the safest, most professional workflow. You create a new type (say, Partition-100-Thick), adjust only its gypsum layer, then reassign just the 12 target walls to it. The original 68 walls are never touched, and no views are accidentally affected. This is option B, the correct answer.
A is dangerous precisely because of the closed-views warning in the passage. Editing the live type first changes all 80 walls immediately, and manually restoring 68 of them is error-prone — you could easily miss walls in unopened views.
C sounds appealing, but wall layer thicknesses are type properties, not instance properties. Revit does not allow you to override individual layer dimensions at the instance level, so this option is technically impossible in standard wall workflows.
D creates unnecessary confusion: renaming the type and reassigning a name is roundabout and still risks touching walls in closed views during the renaming/modification process. It also introduces naming inconsistency across the project.
The study tip here: on the Revit exam, whenever a subset of instances needs a different type property, the answer almost always involves duplicating the type — never editing the shared one.
- Which statement correctly describes the final data for the three instances?
Answer: All three show a $500 Unit Cost, but only the first instance has Finish Code F2
Whenever you see a Revit question about parameters changing across multiple instances, your first instinct should be to identify whether each parameter is a type parameter or an instance parameter — because these behave in fundamentally opposite ways.
A type parameter is shared across every instance that uses the same family type. When you click "Edit Type" and modify a type parameter, you're editing the type definition itself, so every instance of that type inherits the change simultaneously. A instance parameter, by contrast, belongs only to that specific placed element. Changing it in the Properties palette affects only the selected instance, leaving all others untouched.
In this scenario, Unit Cost is a type parameter, so editing it to $500 via Edit Type propagates to all three furniture instances — they all now show $500. Finish Code is an instance parameter, so changing it from F1 to F2 on the first instance affects only that one element; the other two still carry F1. This makes A the correct answer: all three show $500 Unit Cost, but only the first instance has Finish Code F2.
B is wrong because it reverses the logic — it treats the type parameter as instance-only and the instance parameter as global. C is wrong because it assumes both changes propagate universally, ignoring that instance parameters are local. D is wrong because it treats the type parameter as if it only affects the selected instance, which is precisely what instance parameters do, not type parameters.
A reliable memory trick: Type = Team change, Instance = Individual change. On the Revit exam, this distinction appears frequently, so always check whether a parameter lives at the type or instance level before predicting how edits will spread.
- What is the resulting scope of the two changes?
Answer: Fire Rating changes for both doors, while Comments changes only for the selected door
Whenever you see a Revit question involving parameter changes, the first thing to ask yourself is: Is this a type parameter or an instance parameter? This distinction controls exactly how far a change will ripple through your project.
In Revit, a type parameter is shared by every element that uses the same family type. When you open Edit Type and modify a value there, you are editing the type definition itself — so every door, wall, or window of that type updates simultaneously. A Fire Rating stored as a type parameter means both doors inherit the change the moment you confirm it. An instance parameter, by contrast, belongs only to the individual element you have selected. Changing Comments in the Properties palette affects that one door and leaves all others untouched.
That logic confirms answer C: Fire Rating updates for both doors (type-level change), while Comments updates only for the selected door (instance-level change).
Answer A is wrong because it incorrectly treats both parameters as instance-scoped — the act of selecting a door does not limit a type parameter edit to that door alone. Answer B is wrong for the opposite reason: it incorrectly treats both parameters as type-scoped, ignoring that Comments is an instance parameter. Answer D perfectly reverses the correct logic, swapping which parameter is type-level and which is instance-level — a classic trap designed to catch students who confuse the two scopes.
As a study tip, always check the parameter definition in the Family Editor (or notice whether a value appears in Edit Type vs. the Properties palette) to determine scope before predicting what will change.
- After the edits, what should the coordinator expect in the schedule?
Answer: The new type comment appears for all six D1 doors, but the installation note changes only for door 101
Whenever you see a Revit schedule question involving edits to parameter values, the critical distinction to make is whether each parameter is a type parameter or an instance parameter — because this determines the scope of any change you make.
Type parameters are shared across every element that uses the same family type. When you edit a type parameter in a schedule — like Type Comments for door type D1 — Revit is essentially editing the type definition itself. Every door using D1 inherits that change automatically, so all six D1 doors will reflect the new value. Instance parameters, by contrast, belong exclusively to a single element. Editing Installation Note for door 101 only affects that one door, leaving the other five D1 doors untouched.
That logic confirms A as correct: the type comment propagates to all six D1 doors, while the installation note updates only door 101.
B is wrong because it assumes schedule rows act as isolated records — they don't. Type parameter edits ripple across all elements sharing that type, regardless of which row you click. C is wrong in the opposite direction: it overgeneralizes, claiming all schedule edits update the family type. Only type parameter edits do this; instance parameter edits remain local. D reverses the logic entirely, incorrectly assigning the broad scope to the instance parameter and the narrow scope to the type parameter — exactly backward.
A reliable study tip: when reviewing Revit parameters, always ask yourself "does this live on the type or the instance?" Type = shared, Instance = individual. That single question will resolve most schedule and parameter questions on the exam.
- How many chairs receive the new seat width, and why?
Answer: Exactly 8 chairs, because all current instances assigned to type B share its definition
Whenever you see a question about editing element types in Revit, the key concept to keep in mind is the difference between instances and types. An instance is one specific element placed in the model; a type is the shared definition that governs all instances assigned to it. Editing a type property changes every instance that belongs to that type — past, present, and the three newly reassigned ones.
Here's how the logic flows: when the designer reassigns those 3 type A chairs to type B via the Type Selector, those chairs fully become type B instances. They are no longer type A in any sense. At that moment, type B has 5 original chairs plus 3 reassigned chairs — 8 total. When the designer opens Edit Type from any one of those chairs and changes the seat width, that modification applies to the type definition itself, not to any individual chair. All 8 instances sharing that definition immediately reflect the change. That makes C correct.
Choice A is wrong because Edit Type doesn't work on selections — it modifies the type definition, which propagates to all instances regardless of what was selected. Choice B misunderstands the Type Selector; once you reassign an instance to type B, it is definitively type B before Edit Type is ever opened — the reassignment is complete and immediate. Choice D overstates the scope: Edit Type only affects the specific type being edited (type B), not every type in the family. Type A's 9 remaining chairs are untouched.
As a study tip, remember this rule: Instance properties affect one element; Type properties affect all elements sharing that type. This distinction appears constantly on Revit exam questions.
- Which modification most directly supports the requirement without creating another casework type?
Answer: Redefine Show Backsplash as an instance parameter and control it on each placement
Whenever you see a question about controlling visibility differently across instances of the same family type, you need to think about the fundamental distinction between type parameters and instance parameters in Revit families.
A type parameter stores a single value shared by every instance of that type — if you change it, every placement updates simultaneously. An instance parameter, by contrast, stores a value per placement, letting each instance behave independently without requiring a new type.
Since the goal is to show the backsplash on only one of three identical casework instances — without creating a new type — the solution is to redefine Show Backsplash as an instance parameter inside the family editor. Once saved and reloaded, you can toggle the parameter on or off for each placed instance individually. This is exactly what B describes, making it the correct answer.
A is the most common trap here: you cannot override a type parameter at the instance level. Type parameters are locked to the type — there is no per-instance override available in the Properties palette for them.
C is also incorrect. Schedules can display type parameter values, but they cannot split a single type's parameter into different values per instance. Editing a type field in a schedule still changes every instance of that type.
D misunderstands reporting parameters entirely. Reporting parameters are read-only values that capture dimensional data driven by geometry — they cannot be manually set or toggled for visibility control.
As a study strategy, remember this rule: if behavior needs to vary per placement, it must be an instance parameter. Any time a question says "without creating another type," think instance parameters first.
- Assuming the value is edited in Type Properties, which elements receive the new classification?
Answer: All four P-100 pumps, because they reference the edited type's parameter value
Whenever you see a question about Revit parameters, the first thing to identify is whether the parameter is instance-bound or type-bound — this single distinction determines how widely a value propagates.
A type-bound parameter stores its value at the type level, meaning every element that shares that type references the same value. When you open Type Properties for a P-100 pump and edit a type-bound parameter, you are modifying the type definition itself — not the individual element you clicked on. Because all four P-100 pumps reference that same type, they all immediately reflect the updated value. That makes D the correct answer.
Here's why the other choices miss the mark. A is wrong because it confuses type parameters with instance parameters. Instance parameters are element-specific; type parameters are shared across all instances of that type — editing them in Type Properties is the clearest signal that you're working at the type level, not the instance level. B introduces a view-visibility rule that simply doesn't exist in Revit's parameter system; view visibility controls what you see, not what gets updated when type data changes. C is tempting because the parameter is bound to the Mechanical Equipment category, but that only means it appears on all elements in that category — it doesn't flatten the distinction between types. P-200 pumps belong to a different type, so editing P-100's type definition leaves P-200 untouched.
A good study habit here: when a Revit question mentions "Type Properties," immediately think all instances of that type are affected — that's the core rule, and exam questions frequently test whether you confuse type scope with category scope or instance scope.
- What is the expected effect on the door tags?
Answer: All type A door tags display the new value, while type B door tags remain unchanged
Whenever you see a question about tags and parameters in Revit, the first thing to ask yourself is: is this a type parameter or an instance parameter? That distinction drives everything.
In Revit, type parameters are shared across all elements of the same family type. If four doors all use "Type A," they are literally the same type — meaning they share one set of type parameter values. When you edit a type parameter from any one of those doors (even through its tag), you are editing the type itself, not just that individual door. Every element belonging to that type immediately reflects the change. That's exactly why D is correct: all four Type A doors update, while the two Type B doors — belonging to a different type with its own parameter value — remain untouched.
Answer A is wrong because it confuses type parameters with instance parameters. Instance parameters would affect only the edited element, but Type Mark here is explicitly a type parameter. Answer B is wrong because type parameters have nothing to do with view visibility — they are project-wide data, not view-specific settings. Changing a type parameter updates the value everywhere in the project, across all views. Answer C is wrong because the tag family is irrelevant to the scope of the change; all six doors share the same tag family, but they belong to two different door types, so they won't all display the same new value.
Your study tip: memorize the mantra — type parameters change the type, instance parameters change the individual. This rule applies universally across families, tags, and schedules in Revit.
- Which walls are affected after the designer confirms the type change?
Answer: All 36 walls assigned to Exterior-200, including hidden and option-specific walls
Whenever you see a question about Type Properties in Revit, anchor your thinking to one core principle: type parameters are shared by every element assigned to that type, across the entire project, no exceptions.
In Revit's parametric framework, wall types like Exterior-200 act as a single shared definition. Every wall instance that references that type inherits its compound structure — including layer thicknesses. When you edit the type's insulation layer in the Type Properties dialog, you're modifying the definition itself, not any individual wall. Revit then propagates that change to all 36 walls simultaneously. Hidden walls are simply invisible in the current view but still exist in the model and remain linked to the same type. Walls inside a design option belong to an alternate design scenario but are still assigned to Exterior-200, so they're updated too. Answer B is correct.
A is wrong because view visibility has no bearing on type definitions. Hiding a wall in a view doesn't disconnect it from its type — it's just a display setting.
C reflects a common misconception: layer thickness lives in Type Properties, not Instance Properties. Instance parameters (like wall height or base offset) vary per element, but compound structure is always type-level. There's no way to change insulation thickness for just one wall without creating a new type.
D is wrong because the change is scoped to walls assigned specifically to Exterior-200. Walls of a different type — say, Exterior-300 — are completely unaffected.
Study tip: On Revit exam questions, always ask yourself "is this parameter type-level or instance-level?" Type edits ripple everywhere; instance edits affect only that one element.
- What is the most appropriate family-parameter change if the depth must remain independently editable on each placed fixture?
Answer: Change Housing Depth to an instance parameter and verify that the family flexes independently
When working with Revit families, one of the most important distinctions you need to understand is the difference between type parameters and instance parameters. Type parameters apply uniformly to every placed instance of a given type — changing one changes all ten fixtures simultaneously. Instance parameters, by contrast, allow each placed element to hold its own independent value while still belonging to the same type.
This scenario is the classic use case for converting a type parameter to an instance parameter. Since two fixtures need unique depths while sharing the same photometric data (meaning they should stay the same type), the only clean solution is to make Housing Depth an instance parameter. Once converted and the family is reloaded, you can select each of those two fixtures individually and enter a different depth without affecting the other eight. Choice A is correct — and the extra step of verifying the family "flexes" independently is good practice to confirm no constraints break during the conversion.
Choice B is wrong because type parameters cannot be edited per-fixture from the Properties palette; changing a type parameter always propagates to every instance of that type, which would alter all ten fixtures, not just two. Choice C misunderstands reporting parameters entirely — they read a value driven by geometry (like a measurement), they cannot be used to input or drive a dimension. Choice D is a workaround that would create duplicate family types for just a depth change, which clutters the project and defeats proper parametric workflow.
A good study rule: whenever a question involves some but not all instances needing unique values, your answer almost always involves instance parameters.
