Levels - Autodesk Revit

1. What should occur after the type setting is changed?
   Answer: The level remains fixed, while its displayed elevation changes to approximately $110\text{ ft}$. When working with levels in Revit, it's critical to distinguish between a level's physical position in the model and its displayed elevation label. The Elevation Base property on a level type controls only how the annotation label is calculated — it does not move the level geometry. Here's the logic: your level sits physically at $10\text{ ft}$ above the project base point. The survey point sits $100\text{ ft}$ below that, at a project-relative elevation of $-100\text{ ft}$, which means the level is $110\text{ ft}$ above the survey point. When you switch Elevation Base from "Project" to "Survey," Revit recalculates the displayed number using the survey point as the new zero reference: $10 - (-100) = 110\text{ ft}$. The level plane itself doesn't budge — only the label updates. That's exactly what answer B describes, making it correct. Answer A is wrong because it suggests the level moves to $110\text{ ft}$ — Elevation Base is a display setting, not a geometric one. Answer C compounds that error further by implying the level physically drops $100\text{ ft}$, which would shift the entire floor geometry and displace hosted elements — none of that happens here. Answer D correctly identifies that the level stays fixed but incorrectly claims the label stays at $10\text{ ft}$; the whole point of changing Elevation Base is that the label does change. A useful rule of thumb: in Revit, type-level display properties change what you see, not where elements live. Whenever a question mentions Elevation Base, ask yourself, "Is this about geometry or annotation?" — it's always annotation.
2. Which statement best describes the required workflow?
   Answer: Create a Level 3 floor plan, then copy appropriate annotations from the duplicate. When working with floor plan views in Revit, it's critical to understand that a view's Associated Level is a fixed, read-only property — it cannot be manually edited after the view is created. This property defines which level the view cuts through and organizes under in the Project Browser. Questions like this test whether you know the boundaries of view duplication and what annotations can truly "travel" with a view. The correct approach is C: create a proper Level 3 floor plan view (using the Plan Views tool), then manually copy the annotations from the duplicated view into it. This is the only workflow that gives you a legitimate Level 3 view while preserving the detail work. A is the most tempting distractor, but it describes something Revit simply doesn't allow. The Associated Level field is not editable — you cannot reassign a view from Level 2 to Level 3 by changing a property. Many students assume this is possible because other properties (like View Name or View Range) are editable. B misunderstands the View Range parameter entirely. Adjusting the cut plane or top/bottom boundaries changes what geometry is visible, not which level the view is associated with. These are entirely separate concepts. D is also a common misconception. Renaming a view changes only its display name in the Project Browser — it has zero effect on the Associated Level. A view named "Level 3" can still be fully associated with Level 2. As a study tip: remember that in Revit, Associated Level is set at creation and cannot be changed — any workflow that claims otherwise is a trap.
3. What should be done in the enlarged wall section?
   Answer: Change the level to a 2D extent in that view, then drag the affected endpoint. Whenever you see a Revit question about adjusting level or grid line appearance in one view without affecting others, you need to think about 2D vs. 3D extents. Level datums (and grids) have two extent modes: 3D extents are shared across all parallel views, while 2D extents are view-specific, letting you independently reposition the bubble endpoint in just that one view. In this scenario, you need the bubble to move only in the enlarged wall section — the model elevation must stay fixed and no other view should be disturbed. The correct approach, answer A, is to switch the level to a 2D extent in that specific view, then drag the affected endpoint away from the annotation. The small 3D/2D toggle appears near the endpoint of the level line when it's selected. Once switched to 2D, dragging the endpoint only affects that view, leaving every other section untouched and the actual elevation unchanged. Answer B is the classic trap: dragging a level endpoint while it's still on 3D extents will shift that endpoint across all views that share the 3D extent — exactly the problem the scenario forbids. Answer C is destructive; moving the level vertically changes the actual model elevation, which is explicitly prohibited. Answer D gets it backwards — Propagate Extents pushes your current 2D adjustments out to other views, which is the opposite of isolating a change to one view. A helpful memory rule: "2D = this view only, 3D = all views." Any time a question asks you to adjust a datum's appearance in a single view without side effects, switching to 2D extents first is always your starting move.
4. Which workflow creates the required floor plan without replacing or duplicating the existing level?
   Answer: Open View > Plan Views > Floor Plan, select Mezzanine, and create the view. When a level exists in Revit but was created without a corresponding plan view (because Make Plan View was unchecked), the level itself is perfectly valid — it just lacks a view associated with it. Revit tracks levels and views as separate objects, so you can always add a view for an existing level after the fact. That's the core concept this question tests. The correct path is A: navigating to View > Plan Views > Floor Plan opens a dialog listing all levels that do not yet have a floor plan. Mezzanine will appear there precisely because no plan view was generated at creation. Selecting it creates the view while leaving the level — and all elements constrained to it — completely untouched. B is flawed because duplicating a view creates a copy tied to its original level; you cannot reassign a plan view's Associated Level after creation. That property is read-only once the view exists. C is dangerous: drawing a second level at the same elevation introduces a duplicate datum that would conflict with hosted elements and constraints, and deleting the original would break all the relationships you were told already exist. D sounds plausible, but Make Plan View is a creation-time option in the level dialog — it is not an editable instance property of a level you can toggle retroactively in the Properties palette. As a study tip, remember that in Revit, levels and their associated plan views are created together by default but are not permanently locked together — you can always generate a missing plan view through the View menu without touching the level at all.
5. Which action should be completed before deleting the mistaken level?
   Answer: Reassign eligible element constraints and preserve needed view annotations before accepting the deletion warning. When working with levels in Revit, think of them as anchors — elements like walls, floors, and components are often constrained to a level, and views (floor plans, ceiling plans) are hosted by a level. Deleting a level triggers a cascade of consequences, so your preparation before deletion is everything. The correct approach, A, reflects this two-step discipline: first, manually reassign any walls, level-based components, or element constraints to the correct level using the Properties palette or element constraints. Then, before accepting Revit's deletion warning dialog, choose to preserve the associated plan views rather than deleting them — Revit gives you this option in the warning. This way, you retain your annotations and views while cleanly migrating elements to the correct level. B is backwards. Once you delete the level, Revit also deletes its associated views by default — you can't "then" reassign what no longer exists. Acting after deletion means losing critical data. C describes a nonexistent feature. Revit does not merge level datums when you rename one to match another. You'd simply have two levels with the same name and potentially conflicting elevations, creating confusion rather than solving it. D misrepresents how visibility works. Hiding a level in an elevation view is purely a display toggle — it has no effect on element constraints or view associations whatsoever. As a study tip: whenever a Revit question involves deleting a model element that hosts views or constrains other elements, always ask yourself what's dependent on it. Revit's deletion warnings are powerful tools, but preparation before the warning is what protects your model.
6. At what absolute elevation is the cut plane after the level is raised?
   Answer: It moves to $18\text{ ft}$ because the offset remains relative to the level. Whenever you see a question about Revit view range, the key concept to hold onto is that view range offsets are relative to the associated level — they are not pinned to absolute project elevations. Think of the level as the anchor, and the cut plane as a shadow that always floats a fixed distance above it. Here's the logic: the cut plane is defined as $\text{Level Elevation} + \text{Offset}$. Originally, that gives $12\text{ ft} + 4\text{ ft} = 16\text{ ft}$. When the level rises to $14\text{ ft}$ and the offset remains unchanged at $4\text{ ft}$, the new cut plane sits at $14\text{ ft} + 4\text{ ft} = 18\text{ ft}$. The settings weren't edited, but the absolute position still changed because the anchor moved. D is correct. A is wrong because it correctly calculates the original absolute elevation of $16\text{ ft}$, but incorrectly assumes view range planes are frozen to absolute project coordinates. They are not — they track the level. B incorrectly adds the $2\text{ ft}$ level change twice — once to the level and once to the offset — arriving at $20\text{ ft}$. The offset itself does not increase; only the level moves. C describes a reset behavior that doesn't exist in Revit. The offset value is preserved exactly as set; it doesn't zero out or recalculate when a level is repositioned. As a study tip: always ask yourself "relative to what?" when working with Revit elevations. View range values are relative to their associated level, while things like element constraints behave similarly — understanding which references are absolute versus relative will serve you across many Revit exam questions.
7. What is the resulting relationship between the level and the existing plan views?
   Answer: The level becomes Penthouse, while the associated plan views remain named Roof. When working with Revit levels and views, it's important to understand that levels and their associated plan views are linked but independent objects. Renaming a level does not automatically rename its views — Revit simply offers you the option to do so through a dialog prompt. When you rename the Roof level to Penthouse in an elevation, Revit detects that plan views share that name and asks if you'd like to rename them too. Selecting No means you're declining that optional synchronization — the level rename still completes. So the level becomes Penthouse, while both the floor plan and reflected ceiling plan views retain their original name, Roof. That makes B the correct answer. A is wrong because selecting "No" does not cancel the rename operation — it only declines the offer to propagate the name change to associated views. The level rename proceeds regardless. C is incorrect because Revit never deletes views simply because a level is renamed; no data is destroyed by this action. D is a plausible-sounding trap, but Revit's rename dialog applies to all associated plan views collectively — it doesn't selectively rename the floor plan while leaving the ceiling plan unchanged. A useful rule of thumb: in Revit, the rename prompt for views is always all-or-nothing and optional. The level itself is always renamed when you confirm the input — your choice in that dialog only controls whether the views follow. Remember this distinction, and questions about level/view naming will become straightforward.
8. Assuming the wall is not attached to other geometry, what are its new top elevation and height?
   Answer: The top is $13\text{ ft}$ and the height is $12\text{ ft}$. Whenever you see a wall constraint question in Revit, your job is to track two things separately: the base and the top elevations, each composed of a level elevation plus an offset. Here's the framework. The wall's actual base elevation = Level 1 elevation + base offset = $0 + 1 = 1\text{ ft}$. The wall's actual top elevation = Level 2 elevation + top offset = $12 + (-0.5) = 11.5\text{ ft}$. So the original height = $11.5 - 1 = 10.5\text{ ft}$. Now Level 2 rises by $1.5\text{ ft}$, moving from $12\text{ ft}$ to $13.5\text{ ft}$. Because the wall's top is constrained to Level 2, Revit automatically adjusts the top elevation: $13.5 + (-0.5) = 13\text{ ft}$. Level 1 stays fixed, so the base remains at $1\text{ ft}$. New height = $13 - 1 = 12\text{ ft}$. That confirms B. Choice A (top = $11.5\text{ ft}$, height = $10.5\text{ ft}$) reflects the original values before Level 2 moved — it ignores the level change entirely. Choice C (top = $13.5\text{ ft}$, height = $12.5\text{ ft}$) forgets to apply the $-0.5\text{ ft}$ top offset after the level moves, using the raw level elevation instead. Choice D (top = $14\text{ ft}$, height = $13\text{ ft}$) incorrectly adds the offset rather than subtracting it, reversing its sign. As a study tip: always compute wall elevations as level + offset, and remember that offsets are fixed values — they don't change when the level moves, but they still apply to the new level elevation.
9. How do the walls respond to the level modification?
   Answer: Wall A grows by $2\text{ ft}$, while Wall B keeps its unconnected height. Whenever you see a Revit question about level modifications and wall heights, the key concept to focus on is how each wall's Top Constraint is defined — because that determines whether the wall "follows" a level or stays independent. Wall A has its Top Constraint set to Level 2, meaning its height is parametrically linked to that level. When Level 2 rises by $2\text{ ft}$, Revit automatically stretches Wall A to maintain that connection — its height increases from, say, $10\text{ ft}$ to $12\text{ ft}$. Wall B, by contrast, is set to Unconnected with a fixed height of $10\text{ ft}$. That value is stored independently of any level, so no level change can affect it. Wall B stays exactly $10\text{ ft}$ tall. This makes D correct. A is wrong because sharing a base level (Level 1) has no bearing on how the top of a wall behaves — the top constraint is what matters, not the bottom. B is a common misconception: moving a level in Revit absolutely does affect geometry (walls, floors, ceilings) that reference it — it doesn't merely rename plan views. C reverses the logic entirely; it's Wall A (the level-constrained wall) that grows, not Wall B. Study tip: On the Revit exam, always read wall constraint settings carefully — "Unconnected Height" acts like a hard-coded number, immune to level changes, while any constraint tied to a named level means the wall is "listening" to that level. When in doubt, ask yourself: is the top of this wall anchored to a level or to a fixed number?
10. What base offset should be used after changing the component's level reference to Level 2?
    Answer: Use an offset of $-9\text{ ft}$ to preserve the absolute base elevation. When working with level-based constraints in Revit, the key principle to remember is that a component's absolute elevation is always the sum of its reference level's elevation plus its base offset. Changing which level a component references doesn't move the component — but it does require you to recalculate the offset to preserve that same physical position. Here's the math: the component currently sits at an absolute elevation of $0\text{ ft} + 1\text{ ft} = 1\text{ ft}$. After switching the reference to Level 2 (elevation $10\text{ ft}$), you need an offset that satisfies: $10\text{ ft} + \text{offset} = 1\text{ ft}$. Solving gives $\text{offset} = 1 - 10 = -9\text{ ft}$. That makes C correct — a $-9\text{ ft}$ offset keeps the component exactly where it was physically. A is wrong because offsets do not remain unchanged when you switch levels. Keeping the offset at $1\text{ ft}$ would place the component at $10 + 1 = 11\text{ ft}$, moving it upward by $10\text{ ft}$. B is a common trap — negating the original offset to $-1\text{ ft}$ gives an absolute elevation of $10 - 1 = 9\text{ ft}$, which doesn't match the original position. D sounds intuitive ("account for the difference") but applying a positive $9\text{ ft}$ offset yields $10 + 9 = 19\text{ ft}$, which is far off. A useful habit: always verify by checking $\text{Level Elevation} + \text{Offset} = \text{Target Absolute Elevation}$ before and after any level reassignment.

Start this quiz