Autodesk Revit Quiz: View Specific Vs Model Changes
10 questions · exam conditions
0:00
View Specific Vs Model ChangesQuestion 1 of 10

A door is incorrectly located in the model. It must be relocated in every plan, elevation, and schedule, but it should not appear in a separate life-safety plan.

Which workflow produces the required result without creating a second door?

Move the door in a model view, then use Hide in View for that door in the life-safety plan.
Move the door in the life-safety plan, then use Temporary Hide/Isolate in each remaining project view.
Override the door graphics in the life-safety plan, then move its symbolic representation in another plan.
Delete the door from the life-safety plan, then place a replacement door at the corrected model location.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: View Specific Vs Model Changes

Practice View Specific Vs Model Changes 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 View Specific Vs Model Changes, 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 door is incorrectly located in the model. It must be relocated in every plan, elevation, and schedule, but it should not appear in a separate life-safety plan.

Which workflow produces the required result without creating a second door?

  1. Move the door in a model view, then use Hide in View for that door in the life-safety plan. (correct answer)
  2. Move the door in the life-safety plan, then use Temporary Hide/Isolate in each remaining project view.
  3. Override the door graphics in the life-safety plan, then move its symbolic representation in another plan.
  4. Delete the door from the life-safety plan, then place a replacement door at the corrected model location.
Explanation: 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.

Question 2

Two independent floor plan views currently display furniture. Only the permit plan should stop displaying the Furniture category; the presentation plan must remain unchanged.

Which action most directly satisfies this requirement?

  1. Turn off the Furniture category in the permit plan's Visibility/Graphics settings. (correct answer)
  2. Change the Furniture category to hidden in the project's Object Styles settings.
  3. Select all furniture in the permit plan and clear each instance's Visible parameter.
  4. Delete the furniture while the permit plan is active and retain it in the presentation plan.
Explanation: 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.

Question 3

While coordinating a crowded plan, a user temporarily isolates structural columns. After confirming the layout, the user chooses Apply Hide/Isolate to View.

What is the consequence of applying the temporary state to the view?

  1. The isolated state becomes a persistent setting for that view, while the model and other views remain unchanged. (correct answer)
  2. All nonisolated elements are deleted from the model, while the columns remain visible in every project view.
  3. The isolated state becomes a project-wide visibility rule that is inherited by every plan of the same level.
  4. The temporary state is discarded immediately, restoring the view to its visibility settings before isolation.
Explanation: 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.

Question 4

A mechanical unit appears too dark in one coordination plan, but its standard appearance must remain unchanged in all other plans and elevations.

Which modification best meets the requirement with the least model-wide impact?

  1. Change the unit's material graphics so the lighter appearance is used throughout the project.
  2. Edit the unit family's geometry and assign lighter projection linework to the family.
  3. Use Override Graphics in View for the unit in the coordination plan. (correct answer)
  4. Edit Object Styles for the Mechanical Equipment category in the project settings.
Explanation: 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.

Question 5

A level datum appears in several parallel elevation views. In one elevation, a user switches the datum to 2D extents and drags one endpoint inward to avoid overlapping annotations.

What should the user expect?

  1. The endpoint adjustment changes the level elevation because dragging any part of a level relocates the datum vertically.
  2. The endpoint adjustment shortens the level in every parallel elevation because all datum extents are model-wide.
  3. The endpoint adjustment affects that elevation only, while the level's elevation and 3D datum extents remain unchanged. (correct answer)
  4. The endpoint adjustment hides the level in other elevations because 2D extents override the datum's project visibility.
Explanation: 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.

Question 6

A door tag in one plan displays the door's Mark value. A user wants a different identifier to appear only in that plan, but the door schedule and tags in other views must retain the current value.

Which statement best describes the consequence of editing the Mark value through the tag?

  1. The edit changes only the selected tag because tag values are stored as view-specific annotation text.
  2. The edit changes the active view's template because tag values are controlled through annotation settings.
  3. The edit changes every door of the same type because Mark is always a type parameter.
  4. The edit changes the door's model parameter, so schedules and all other tags reading Mark also update. (correct answer)
Explanation: 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.

Question 7

Several floor plans use the same view template. A user edits that template to set the Walls category to halftone, and all plans controlled by the template update.

How should this change be classified?

  1. It is a model change because multiple views update from a single project-level definition.
  2. It is a material change because halftone modifies the rendered appearance assigned to the walls.
  3. It is an element override stored on every wall instance and therefore visible in all project views.
  4. It is a view-display change propagated to multiple views, not a change to wall geometry or data. (correct answer)
Explanation: 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.

Question 8

Two floor plans are assigned to the same scope box. Their crop boundaries align. The user now needs one plan to show a smaller area while the other plan must retain the shared scope-box boundary.

Which workflow best isolates the crop change to the one plan?

  1. Resize the shared scope box while the smaller plan is active, then restore the second plan's crop manually.
  2. Remove the scope-box assignment from the smaller plan, then edit that plan's crop region independently. (correct answer)
  3. Hide the scope box in the smaller plan, then drag the assigned crop boundary to the required size.
  4. Apply a graphic override to the crop region in the smaller plan, then reduce its displayed line length.
Explanation: 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.

Question 9

In a floor plan, a user selects a wall and a masking region placed over part of that wall, then deletes both selected elements.

What is the expected project result?

  1. Both elements disappear only from the active plan because they were deleted from a view.
  2. The wall is removed from the model, while the masking region is removed from its owning view. (correct answer)
  3. The masking region is removed project-wide, while the wall remains visible in other model views.
  4. Both elements are removed from every view because Delete always operates at the project level.
Explanation: 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.

Question 10

A designer needs reference lines that represent a proposed canopy edge. The lines should be available in multiple appropriate model views and should not exist only as drafting information in one plan.

Which approach best matches that intent?

  1. Create detail lines in the plan and copy them to every view where the canopy is documented.
  2. Create model lines on an appropriate work plane so relevant model views can display them. (correct answer)
  3. Create a filled region boundary in the plan and expose its sketch in the other project views.
  4. Create symbolic lines in the plan and assign them to the canopy's model category.
Explanation: 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.