- Which workflow best isolates the crop change to the one plan?
Answer: Remove the scope-box assignment from the smaller plan, then edit that plan's crop region independently.
Whenever you see a question about scope boxes and crop regions in Revit, the key concept to keep in mind is that a scope box is a shared control — any change to it propagates to every view assigned to it. Your goal in this scenario is to isolate a crop change to just one view without disturbing the other.
The cleanest solution is B: remove the scope-box assignment from the smaller plan first, then edit that view's crop region independently. Once you detach a view from its scope box (by setting the Scope Box property to "None" in that view's Properties), the crop region becomes fully editable for that view alone. The second plan remains governed by the scope box, preserving its boundary without any manual restoration.
A is tempting but backwards — resizing the shared scope box changes it for both views simultaneously, meaning the second plan's boundary is immediately disrupted. You'd then have to manually fix it, which is error-prone and defeats the purpose of using a scope box.
C describes hiding the scope box in the smaller plan. Visibility controls affect only whether you see the scope box graphics, not whether the view is governed by it. The crop boundary would still be locked to the scope box dimensions, so dragging it would have no effect.
D is a distractor that confuses graphic overrides — which control line weight, color, and pattern — with actual crop geometry. You cannot change the functional size of a crop region through a graphic override.
As a study tip: always ask yourself whether a Revit action affects geometry/data or just display. Hiding and overriding affect display; assigning or removing scope boxes affects geometry.
- Which workflow produces the required result without creating a second door?
Answer: Move the door in a model view, then use Hide in View for that door in the life-safety plan.
Whenever you see a Revit question about visibility and model accuracy together, you need to think about one core principle: Revit is a single-model environment. Every view — plan, elevation, schedule — is simply a different window into the same underlying model. Moving an element in any model view moves it everywhere simultaneously.
With that in mind, option A is the correct workflow. Moving the door in a model view (any plan or elevation) relocates the actual model element, so that corrected position automatically propagates to every plan, elevation, and schedule — no extra steps needed. Then, using Hide in View in the life-safety plan suppresses only that door's visibility in that specific view, leaving the model itself untouched. The door remains correctly placed in the model; it simply doesn't display in that one view.
Option B is flawed because moving an element in the life-safety plan moves it in the model, which would relocate it incorrectly across all views. Temporary Hide/Isolate is also a session-based display tool — it resets when the view is closed and cannot be saved as a permanent visibility setting.
Option C is a trap. Graphic overrides change how an element looks (line weight, color, pattern) — they don't move it. You cannot relocate a door's actual position through a graphic override.
Option D describes deleting and replacing the door, which technically creates a second door element with a new element ID, breaking any existing tag, schedule row, or parameter data associated with the original.
Study tip: Remember that in Revit, "Hide in View" is a permanent per-view setting, while "Temporary Hide/Isolate" is session-only — that distinction appears frequently on this exam.
- Which modification best meets the requirement with the least model-wide impact?
Answer: Use Override Graphics in View for the unit in the coordination plan.
Whenever you see a Revit question about changing appearance for one view without affecting the rest of the project, you should immediately think about the difference between view-level overrides and project-level or family-level changes.
Revit gives you a powerful tool called Override Graphics in View (found by right-clicking an element or through the Visibility/Graphics dialog), which lets you change how a specific element looks — its lines, patterns, transparency, and halftone — within a single view only. Everything else in the project remains untouched. This is exactly what the scenario demands: lighter appearance in one coordination plan, standard appearance everywhere else. Option C is the correct approach because it is scoped entirely to that one view.
Option A is wrong because changing a material's graphic settings updates it across the entire project — every view that displays that material would show the lighter appearance, violating the requirement. Option B is a deeper mistake: editing the family's geometry or linework changes the family definition itself, meaning the modification propagates to every placement of that family in every view throughout the model. Option D, editing Object Styles for the Mechanical Equipment category, is the broadest change of all — it redefines the default display for the entire category project-wide, affecting all elements in that category across all views.
A helpful rule of thumb: in Revit, overrides follow a hierarchy — Object Styles (project-wide) → Visibility/Graphics (view-wide by category) → Override Graphics in View (view-wide by element). When the question asks for the least model-wide impact on a single element in a single view, the answer almost always lives at the element-level, view-specific end of that hierarchy.
- What is the consequence of applying the temporary state to the view?
Answer: The isolated state becomes a persistent setting for that view, while the model and other views remain unchanged.
When working with visibility in Revit, it's important to distinguish between temporary and persistent visibility states. Temporary Hide/Isolate is a quick, in-session tool — notice the blue border that appears around your view when it's active. "Apply Hide/Isolate to View" is the command that graduates that temporary state into a permanent view-level setting.
When you apply the temporary isolation, Revit converts it into a View-Specific Override, permanently hiding the non-isolated elements in that view only. The model geometry itself is untouched — those elements still exist in the project and appear normally in all other views. This makes A correct: the isolated state becomes a persistent setting scoped exclusively to that view.
B is wrong because Revit's visibility tools never delete model elements — hiding something is purely a display override. Deleting would remove the geometry from the entire project, which is a destructive, irreversible action completely unrelated to Hide/Isolate. C is wrong because Revit's view visibility settings are view-specific by default — they don't propagate or cascade to other views automatically, even if those views share the same level. There's no "inheritance" mechanism for Hide/Isolate overrides. D describes what happens when you click Reset Temporary Hide/Isolate instead — that discards the temporary state and restores original visibility without applying anything permanently.
A good study tip: whenever you see Revit visibility questions, ask yourself which scope is affected — element, view, or project-wide. Hide/Isolate always operates at the view level, never modifying the model or other views.
- How should this change be classified?
Answer: It is a view-display change propagated to multiple views, not a change to wall geometry or data.
When working with Revit, you need to distinguish between changes that affect what exists in the model versus changes that affect how views display it. This question tests that boundary.
A view template is a collection of view-specific display settings — things like detail level, visibility/graphics overrides, and halftone assignments. When you set the Walls category to halftone inside a view template, you are telling Revit how to draw walls on screen in any view governed by that template. The walls themselves — their geometry, type, instance parameters, and material assignments — remain completely untouched. Because the template is a shared definition, every linked view inherits the updated display rule simultaneously. That makes D the correct classification: a view-display change propagated to multiple views, with no alteration to wall geometry or data.
Choice A misidentifies the scope. The word "model change" implies something stored in the model database — like moving a wall or changing its type. Updating a view template is purely a display configuration, even if many views are affected at once.
Choice B confuses halftone with material rendering. Halftone is a graphics override that makes elements appear faded in a view; it does not alter the material definition assigned to a wall's layers or affect any rendered output.
Choice C describes instance-level element overrides, which are stored on individual elements and appear in all views by default. A view template override works the opposite way — it is stored on the view, not on the wall instances.
As a study habit, remember: if the change lives in View Properties or Visibility/Graphics, it is a view-display change, not a model change.
- Which approach best matches that intent?
Answer: Create model lines on an appropriate work plane so relevant model views can display them.
Whenever you see a question about placing geometry that needs to appear across multiple model views in Revit, you should immediately distinguish between model elements and view-specific elements. Model elements exist in 3D space and appear in any view whose scope intersects them; view-specific elements live only in the view where they were created.
Model lines are true model elements drawn on a defined work plane. Because they occupy real 3D space, they automatically appear in every plan, section, elevation, or 3D view that cuts through or displays that area — which is exactly what the canopy edge scenario requires. Option B is correct because it respects Revit's fundamental distinction: model geometry propagates across views by design.
Option A fails because detail lines are view-specific. Manually copying them to every view is a workaround that defeats Revit's purpose, creates maintenance headaches whenever the design changes, and risks inconsistency between views. Option C misuses filled regions — their sketch boundaries are also view-specific draft geometry and cannot be exposed in other project views as model references. Filled regions represent 2D patterned areas, not spatial edges. Option D describes symbolic lines, which are used inside families to represent geometry in specific view directions; they are also view-specific and tied to family contexts, not standalone model space.
A good study habit for the Revit exam: when a question mentions geometry that must be "available in multiple model views," immediately think model lines or model elements. If a question mentions geometry that exists only for documentation in one view, think detail lines, filled regions, or symbolic lines.
- Which action most directly satisfies this requirement?
Answer: Turn off the Furniture category in the permit plan's Visibility/Graphics settings.
Whenever you see a Revit question about controlling visibility for one specific view without affecting others, your focus should immediately go to view-level settings versus project-level settings — that distinction is the heart of this question.
Revit's Visibility/Graphics Overrides (V/G) are view-specific, meaning any change you make applies only to the active view. Turning off the Furniture category in the permit plan's Visibility/Graphics settings — answer A — hides that category exclusively in that view, leaving the presentation plan completely untouched. This is the most direct, non-destructive, and professionally appropriate solution.
Here's why the other options fall short: B is the classic trap on this topic. Object Styles is a project-wide setting, so hiding the Furniture category there would suppress it in every view across the entire project, including the presentation plan — the opposite of what the requirement demands. C clearing the Visible parameter on individual furniture instances is tedious and still view-agnostic by default; it affects element visibility globally unless combined with phase or filter logic, and it risks permanently altering elements rather than just their display in one view. D is simply destructive — deleting furniture removes it from the project entirely, meaning it would vanish from the presentation plan as well, directly violating the requirement to leave that view unchanged.
The study tip here: whenever a question specifies that a change should affect only one view, the answer almost always lives in Visibility/Graphics Overrides (V/G shortcut). Project-wide tools like Object Styles or deleting elements should immediately raise a red flag.
- What should the user expect?
Answer: The endpoint adjustment affects that elevation only, while the level's elevation and 3D datum extents remain unchanged.
Whenever you see a question about datum extents in Revit, think about the fundamental distinction between 3D extents and 2D extents — this is one of Revit's most tested visibility concepts.
In Revit, levels and grids have two extent modes. 3D extents are model-wide and affect how the datum appears across all views simultaneously. 2D extents, by contrast, are view-specific overrides. When you switch a level to 2D extents in a particular elevation and drag an endpoint, you're only adjusting how that datum displays in that single view — you're not moving the level itself or affecting any other view. This makes C the correct answer: the adjustment is purely cosmetic and local to that elevation, leaving the level's actual elevation and its 3D extents completely intact.
A is wrong because dragging a 2D extent endpoint never changes the level's elevation. Elevation is a property of the datum itself, not its graphical representation in a view. Confusing display with data is a classic Revit trap. B is wrong because it describes the behavior of 3D extents, not 2D extents — if the user had stayed in 3D extent mode and dragged the endpoint, it would propagate across parallel views. The whole point of switching to 2D is to isolate the change. D is wrong because adjusting a 2D endpoint shortens the visible line segment — it doesn't hide the level in other views or trigger any project-wide visibility override.
Your study tip: always ask yourself which extent mode is active before predicting how a datum change will behave. 3D = global, 2D = local to that view.
- Which statement best describes the consequence of editing the Mark value through the tag?
Answer: The edit changes the door's model parameter, so schedules and all other tags reading Mark also update.
Whenever you see a question about tags and parameter values in Revit, the critical distinction to keep in mind is whether a value is stored in the model element or purely in the annotation. Tags in Revit are not independent containers of data — they are reporters. A tag reads and displays a parameter value that lives on the actual element in the model database.
The Mark parameter is an instance parameter stored directly on each door element. When you click a tag and edit the value it displays, you are editing that underlying instance parameter on the door itself — not some localized annotation text. Because the parameter lives on the model element, every schedule row, every tag in every other view, and every schedule that reads Mark will immediately reflect the new value. That's why D is correct: the change propagates everywhere Mark is read, which is exactly the problem the scenario is trying to avoid.
A is wrong because tags do not store their own independent text values — they are parameter-driven. There is no such thing as "view-specific annotation text" for a tag's parameter display. B is wrong because editing a tag value has nothing to do with view templates; view templates control visibility and graphic settings, not element parameter data. C is wrong because Mark is an instance parameter, not a type parameter — each door instance can have a unique Mark, so it would not change every door of the same type.
For the exam, remember this rule: if a tag displays a parameter, editing through the tag edits the parameter itself. The only way to show a different identifier in one view without affecting others is to use a view-specific annotation like a text note or a separate shared parameter tied to a view filter.
- What is the expected project result?
Answer: The wall is removed from the model, while the masking region is removed from its owning view.
Whenever you see a question about deleting elements in Revit, the key distinction to understand is the difference between model elements and view-specific elements. Model elements (like walls, floors, doors) exist in the project database and appear across multiple views. View-specific elements (like masking regions, detail lines, and filled regions) belong to a single view and only exist within it.
When you delete a wall, you're removing a model element from the entire project — it disappears from every floor plan, section, elevation, and 3D view that displayed it. When you delete a masking region, you're removing a view-specific element that was created in and owned by one particular view. So deleting both simultaneously produces exactly what answer B describes: the wall is gone project-wide, and the masking region is gone from its owning view only.
Answer A is wrong because it implies the wall is also only deleted from the active view — but walls are model elements, and deleting them removes them from the entire project, not just one view. Answer C incorrectly states the masking region is removed project-wide, but view-specific elements don't propagate across views, so there's nothing to remove elsewhere. Answer D overgeneralizes by claiming Delete always operates at the project level — this is false precisely because view-specific elements are scoped to their view.
A helpful rule of thumb: ask yourself "was this element created in the model or drawn in a view?" If it was drawn in a view (masking regions, detail components, revision clouds), deletion is view-scoped. If it was modeled (walls, doors, structural elements), deletion is project-wide.
