Autodesk Revit Quiz: Levels

10 questions · exam conditions

0:00

LevelsQuestion 1 of 10

A level named Mezzanine was created in an elevation view with Make Plan View cleared. The level is correctly positioned and several model elements are already constrained to it. A floor plan is now required for that level.

Which workflow creates the required floor plan without replacing or duplicating the existing level?

Open View > Plan Views > Floor Plan, select Mezzanine, and create the view.

Duplicate the plan below Mezzanine, then change its Associated Level property to Mezzanine.

Draw another level at the same elevation with Make Plan View selected, then delete the original.

Open the elevation, select Mezzanine, and enable Make Plan View in its instance properties.

← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Levels

Practice Levels 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 Levels, 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

Which workflow creates the required floor plan without replacing or duplicating the existing level?

Open View > Plan Views > Floor Plan, select Mezzanine, and create the view. (correct answer)
Duplicate the plan below Mezzanine, then change its Associated Level property to Mezzanine.
Draw another level at the same elevation with Make Plan View selected, then delete the original.
Open the elevation, select Mezzanine, and enable Make Plan View in its instance properties.

Explanation: 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.

Question 2

Two walls begin at Level 1, which remains fixed. Wall A has Top Constraint set to Level 2 with a zero offset. Wall B has Top Constraint set to Unconnected with an unconnected height of $10\text{ ft}$ . Neither wall is attached to a roof or floor. Level 2 is raised by $2\text{ ft}$ .

How do the walls respond to the level modification?

Both walls grow by $2\text{ ft}$ because they share the same base level.
Neither wall changes because moving a level affects only its plan views.
Wall A keeps its original height, while Wall B grows by $2\text{ ft}$ .
Wall A grows by $2\text{ ft}$ , while Wall B keeps its unconnected height. (correct answer)

Explanation: 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}

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?

Question 3

A wall has its base constrained to Level 1 at elevation $0$ with a base offset of $1\text{ ft}$ . Its top is constrained to Level 2 at elevation $12\text{ ft}$ with a top offset of $-0.5\text{ ft}$ . Level 2 is then raised by $1.5\text{ ft}$ , while Level 1 remains fixed.

Assuming the wall is not attached to other geometry, what are its new top elevation and height?

The top is $11.5\text{ ft}$ and the height is $10.5\text{ ft}$ .
The top is $13\text{ ft}$ and the height is $12\text{ ft}$ . (correct answer)
The top is $13.5\text{ ft}$ and the height is $12.5\text{ ft}$ .
The top is $14\text{ ft}$ and the height is $13\text{ ft}$ .

Explanation: 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}

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.

Question 4

A project has a detailed floor plan associated with Level 2. A user duplicates that view with detailing and intends to use the duplicate as the floor plan for Level 3, preserving all copied annotations.

Which statement best describes the required workflow?

Edit the duplicate's Associated Level property from Level 2 to Level 3.
Raise the duplicate's view range until its associated level automatically becomes Level 3.
Create a Level 3 floor plan, then copy appropriate annotations from the duplicate. (correct answer)
Rename the duplicate Level 3, which also changes its associated level to Level 3.

Explanation: 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.

Question 5

A level datum appears correctly across several sections. In one enlarged wall section, its bubble overlaps an annotation. The level's model elevation must remain unchanged, and its displayed endpoint must not move in any other view.

What should be done in the enlarged wall section?

Change the level to a 2D extent in that view, then drag the affected endpoint. (correct answer)
Leave the level at a 3D extent, then drag its endpoint to clear the annotation.
Move the entire level datum vertically, then correct its elevation value afterward.
Use Propagate Extents first, then drag the endpoint in the enlarged section.

Explanation: 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.

Question 6

A component's base is currently constrained to Level 1 at elevation $0\text{ ft}$ with a base offset of $1\text{ ft}$ , placing its base at absolute elevation $1\text{ ft}$ . The component must instead reference Level 2, which is at elevation $10\text{ ft}$ , without changing the component's physical position.

What base offset should be used after changing the component's level reference to Level 2?

Use an offset of $1\text{ ft}$ because offsets remain unchanged between levels.
Use an offset of $-1\text{ ft}$ to reverse the component's original offset.
Use an offset of $-9\text{ ft}$ to preserve the absolute base elevation. (correct answer)
Use an offset of $9\text{ ft}$ to account for the elevation difference.

Explanation: 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.

Question 7

A mistakenly created level has associated floor and ceiling plans. Some walls and level-based components reference it, but the design team wants those elements to use a nearby correct level. The annotations in the associated plans may still be needed.

Which action should be completed before deleting the mistaken level?

Reassign eligible element constraints and preserve needed view annotations before accepting the deletion warning. (correct answer)
Delete the level first, then reassign the deleted views and hosted elements to the correct level.
Rename the mistaken level to match the correct level, causing Revit to merge both level datums.
Hide the mistaken level in every elevation, which automatically transfers its views and constraints.

Explanation: 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.

Question 8

A level plane is physically located at $10\text{ ft}$ relative to the project base point. At the same location, the survey-based elevation is $110\text{ ft}$ . The level type currently reports elevations from the project base point. Its Elevation Base is changed to the survey point.

What should occur after the type setting is changed?

The level moves upward to $110\text{ ft}$ , while its displayed elevation remains $10\text{ ft}$ .
The level remains fixed, while its displayed elevation changes to approximately $110\text{ ft}$ . (correct answer)
The level moves downward by $100\text{ ft}$ , while constrained elements remain at their original locations.
The level remains fixed, while its displayed elevation continues to read $10\text{ ft}$ .

Explanation: 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.

Question 9

A floor plan is associated with a level at elevation $12\text{ ft}$ . Its view range cut plane has an offset of $4\text{ ft}$ from the associated level. The level is raised to elevation $14\text{ ft}$ , and the view range settings are not edited.

At what absolute elevation is the cut plane after the level is raised?

It remains at $16\text{ ft}$ because view range planes use fixed project elevations.
It moves to $20\text{ ft}$ because both the level and offset increase by $2\text{ ft}$ .
It moves to $14\text{ ft}$ because the cut offset resets when the level moves.
It moves to $18\text{ ft}$ because the offset remains relative to the level. (correct answer)

Explanation: 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.

Question 10

A level named Roof has associated floor and reflected ceiling plan views, both also named Roof. In an elevation, the level is renamed Penthouse. When Revit asks whether to rename corresponding views, the user selects No.

What is the resulting relationship between the level and the existing plan views?

The level and both plan views remain named Roof because the rename operation is canceled.
The level becomes Penthouse, while the associated plan views remain named Roof. (correct answer)
The level becomes Penthouse, and both associated plan views are automatically deleted.
The level and floor plan become Penthouse, while the ceiling plan remains named Roof.

Explanation: 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.