Autodesk Revit Quiz: Doors And Windows

10 questions · exam conditions

0:00

Doors And WindowsQuestion 1 of 10

An exterior facade is modeled as a curtain wall. A designer attempts to place a standard wall-hosted door by clicking an existing glazed curtain panel, but Revit does not accept the placement.

What is the appropriate workflow for adding the door at that location?

Place the standard door on a curtain grid line, then align it to the panel

Convert the curtain wall to a basic wall, place the door, and convert it back

Load a curtain-wall door family and replace the appropriate curtain panel with it

Place the standard door unhosted, then use Pick New Host on the curtain panel

← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Doors And Windows

Practice Doors And Windows 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 Doors And Windows, 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

An exterior facade is modeled as a curtain wall. A designer attempts to place a standard wall-hosted door by clicking an existing glazed curtain panel, but Revit does not accept the placement.

What is the appropriate workflow for adding the door at that location?

Place the standard door on a curtain grid line, then align it to the panel
Convert the curtain wall to a basic wall, place the door, and convert it back
Load a curtain-wall door family and replace the appropriate curtain panel with it (correct answer)
Place the standard door unhosted, then use Pick New Host on the curtain panel

Explanation: Whenever you see a question about placing doors or windows in Revit, you need to recognize the fundamental distinction between basic walls and curtain walls — they follow completely different hosting rules. Curtain walls in Revit are not just stylized basic walls. They are panel-grid systems where each glazed unit is an individual panel family. Because of this architecture, standard wall-hosted door families cannot recognize a curtain panel as a valid host — the hosting mechanism simply doesn't apply. The correct approach is to load a curtain-wall door family (a panel-based family type) and then swap it in by selecting the target panel and using "Replace Panel" or by directly placing the curtain panel door into an empty panel slot. This replaces the glazed panel with a door panel that lives natively within the curtain system, which is answer C. Answer A is wrong because curtain grid lines are structural divisions of the curtain system, not wall faces — you cannot host a standard door on a grid line, and aligning afterward doesn't resolve the incompatible hosting type. Answer B describes a destructive workaround that would collapse all the curtain wall geometry, detailing, and panel data, and "converting back" isn't a reliable Revit workflow — this is a common trap for students who don't know the proper method. Answer D is wrong because "Pick New Host" allows re-hosting between compatible hosts (like moving a door from one basic wall to another), but a curtain panel still cannot host a standard wall-based door family regardless of the command used. A good study tip: whenever Revit rejects a placement, ask yourself "is the family type compatible with the host type?" Curtain walls always require curtain-panel families, not wall-hosted ones.

Question 2

A basic wall contains several hosted doors and windows. The wall must move $600\text{ mm}$ while preserving the openings' positions relative to the wall.

Which workflow is most appropriate?

Move the wall; its hosted doors and windows normally move with the host (correct answer)
Unhost every opening, move the wall, and then assign the wall as host again
Delete the wall, move the openings, and draw a replacement wall through them
Pin every opening, move the wall, and then unpin the openings afterward

Explanation: Whenever you see a Revit question about moving walls that contain doors or windows, think about the host-element relationship. In Revit, doors and windows are hosted elements — they are parametrically dependent on a wall and cannot exist independently of it. This relationship is not just visual; it is structural to the Revit data model. Because hosted elements are bound to their host, when you move a wall using the Move tool, all doors and windows embedded in that wall travel with it automatically, maintaining their exact positions relative to the wall. This makes A the correct and most efficient workflow — no extra steps required. Option B is unnecessarily complex and actually risky. Unhosting openings (face-based or work-plane-based workarounds) breaks the parametric relationship entirely and can cause the elements to lose their cut behavior in the wall, requiring manual cleanup. Option C is the most destructive approach — deleting the wall forces you to lose wall properties, hosted element associations, and any attached elements like floors or roofs. Drawing a replacement wall is time-consuming and error-prone. Option D reflects a misunderstanding of what pinning does in Revit. Pinning locks an element in place in the project so it cannot be moved — it does not transfer or override the host relationship. Pinning the doors would actually prevent them from moving with the wall, which is the opposite of what you want. As a study tip, remember that in Revit, hosted elements always follow their host. If a question asks how to preserve opening positions while moving a wall, the answer is almost always: just move the wall.

Question 3

A selected window has instance Mark W-17 and instance Comments set to "Verify field opening." The user changes the window to another loaded type by using the Type Selector. The replacement type has different Width and Height values.

Which result should normally be expected?

Mark is replaced by the new type's Type Mark; Comments and dimensions remain unchanged
Mark and Comments are cleared; Width and Height are retained from the original type
Mark and Comments are retained; Width and Height update to the replacement type's values (correct answer)
All instance and type values reset to defaults because the Type Selector creates a new instance

Explanation: When working with Revit's Type Selector, the key concept to understand is the distinction between instance parameters and type parameters, and how each behaves when you swap a family type. Instance parameters — like Mark and Comments — belong exclusively to the placed element. They represent data you've assigned to that specific instance in your project. When you switch types using the Type Selector, Revit is simply reassigning which type definition the instance references; it doesn't touch the instance's own properties. So Mark stays "W-17" and Comments retains "Verify field opening." Width and Height, however, are type parameters — they're defined by the type itself, not the instance. Swapping to a new type means the instance now inherits that new type's dimensional values. This makes C the correct answer: instance data persists, type-driven data updates. Choice A is wrong because Mark is an instance parameter, not derived from the Type Mark (a separate type parameter) — they aren't linked or swapped automatically. Choice B has it completely backwards: Mark and Comments, being instance parameters, are the ones that survive the type change, while dimensions update. Choice D describes a behavior that doesn't exist in Revit — the Type Selector modifies the existing instance's type reference rather than deleting and recreating it, so nothing resets to defaults. A helpful study tip: whenever a Revit question involves swapping types, ask yourself "is this value stored on the instance or on the type?" Instance values travel with the element; type values come from whichever type is currently assigned.

Question 4

A door has already been placed and has the correct type and width. A temporary dimension appears between the door opening and the end of its host wall. The user edits that temporary dimension from $1800\text{ mm}$ to $2100\text{ mm}$ .

What is the expected effect of editing the temporary dimension?

The door moves $300\text{ mm}$ along the wall while retaining its current type and width (correct answer)
The door width increases $300\text{ mm}$ while its center remains fixed on the wall
The wall length increases $300\text{ mm}$ while the door remains in its original location
A new door type is created with an offset value of $2100\text{ mm}$

Explanation: When working with placed elements in Revit, it's important to understand what temporary dimensions actually control. Temporary dimensions appear automatically when you select an element, and they measure the position of that element relative to nearby references — not the element's own size or the host's length. In this scenario, the temporary dimension measures the gap between the door opening and the end of its host wall — essentially telling you where the door sits along the wall. When you change that value from

1800\text{ mm}

2100\text{ mm}

, you're instructing Revit to reposition the door so that it now sits

2100\text{ mm}

from the wall end, a shift of

300\text{ mm}

. The door type, width, and host wall all remain completely unchanged. That makes A the correct answer. B is wrong because temporary dimensions never modify an element's type parameters like width — you'd need to edit the door's type properties or instance properties for that. C is wrong because Revit moves the selected element (the door) to satisfy the new dimension, not the host wall; the wall length is independent of door placement. D is wrong because Revit does not create new types based on dimension edits — type creation happens through the Type Properties dialog, not through geometry manipulation on the canvas. A useful rule of thumb: in Revit, temporary dimensions control location, while type/instance properties control size. When a question describes editing a dimension on a selected element, always ask yourself whether that dimension describes position or a property — the answer almost always points to movement, not modification.

Question 5

A window type has a fixed Height of $1200\text{ mm}$ . One instance has a Sill Height of $900\text{ mm}$ , so its head is at $2100\text{ mm}$ above the associated level. The Sill Height of that instance is changed to $1050\text{ mm}$ without editing the type.

What should happen to that window instance?

Its head rises to $2250\text{ mm}$ while its height remains $1200\text{ mm}$ (correct answer)
Its head remains at $2100\text{ mm}$ while its height decreases to $1050\text{ mm}$
Its head rises to $2250\text{ mm}$ and every window of the type moves with it
Its sill remains at $900\text{ mm}$ because sill height is controlled by the type

Explanation: Whenever you see a Revit question mixing type parameters and instance parameters, your first move should be to classify which parameters belong to which category — because that determines what changes affect one element versus all elements. In Revit, a window's Height is a type parameter, meaning it is shared by every window of that family type. Sill Height, however, is an instance parameter, meaning it can be set independently for each placed window. When you raise the Sill Height from

900\text{ mm}

1050\text{ mm}

, you are moving the bottom of the window up by

150\text{ mm}

. Because the Height (

1200\text{ mm}

) is locked at the type level and you haven't edited the type, the window simply shifts upward as a unit: the new head height becomes

1050 + 1200 = 2250\text{ mm}

. This confirms A is correct. B is wrong because it assumes the head is fixed and the height shrinks — that would only happen if Head Height were the constrained instance parameter, which it is not by default. C is wrong for two reasons: the head does rise to

2250\text{ mm}

(correct math), but changing an instance parameter never affects other instances of the same type — only editing the type itself would do that. D is wrong because Sill Height is definitively an instance parameter, not a type parameter, so it can be changed per window without touching the type. Your study tip: memorize that Height = type (shared) and Sill Height = instance (individual). This distinction appears repeatedly in Revit exam questions and drives nearly all window-placement behavior.

Question 6

A wall has a Base Constraint of Level 1 and extends above Level 3. While working in the Level 2 floor plan, you place a wall-hosted door in that wall.

Which level will normally be assigned to the new door?

Level 1, because the door inherits the host wall's Base Constraint
Level 2, because the door is placed while working in the Level 2 floor plan (correct answer)
Level 3, because the host wall's upper extent reaches above that level
No level, because wall-hosted doors are associated only with their host wall

Explanation: When placing hosted elements in Revit, understanding how levels get assigned is critical. The key principle here is that Revit uses the active view's associated level — not the host element's constraints — to determine the level assigned to a newly placed hosted element like a door or window. When you place a door while working in the Level 2 floor plan, Revit automatically assigns Level 2 as the door's reference level. This happens regardless of where the host wall's constraints begin or end. The door's offset is then calculated from that level. So B is correct — the active floor plan view governs the level assignment. Choice A is a tempting trap because it sounds logical: the wall lives on Level 1, so shouldn't its hosted elements inherit that? No — the wall's Base Constraint defines where the wall starts, not the level reference for elements placed within it. A door is an independent element with its own level parameter. Choice C is similarly flawed. The wall's upper extent reaching above Level 3 is irrelevant to how Revit assigns the door's level. Upper constraints define wall height, nothing more. Choice D is incorrect because doors absolutely have a level association — you can see and modify it in the door's instance properties. Doors are not level-agnostic just because they're wall-hosted. Study tip: Whenever a Revit question mentions placing elements while working in a specific floor plan view, that view's level is almost always the answer for level assignment questions. The active view is Revit's frame of reference for placement.

Question 7

Twenty identical doors share one type. Each door requires a unique identifier in a door schedule, while the type itself must retain a common designation that can also be scheduled.

Which parameter strategy best supports both requirements?

Enter unique values in Type Mark and one common value in Mark
Enter unique values in Type Comments and one common value in Comments
Duplicate the door type for every opening and use only Type Mark
Enter unique values in Mark and one common value in Type Mark (correct answer)

Explanation: Whenever you see a question about Revit door schedules, you need to distinguish between instance parameters and type parameters. Instance parameters apply to one specific element placed in the model; type parameters apply to every element sharing that type. Mark is an instance parameter — it lives on each individual door and can hold a unique value per opening. Type Mark is a type parameter — it's shared across all doors of the same type, making it ideal for a common designation. This is exactly the combination the question describes: twenty doors needing unique identifiers (instance-level) plus a shared type designation (type-level). Entering unique values in Mark and one common value in Type Mark gives you both, confirming D is correct. A reverses the logic entirely — Type Mark is a type parameter and cannot hold unique per-door values without duplicating the type, while Mark is an instance parameter that shouldn't carry a single shared designation across all openings. B uses Comments and Type Comments, which do exist in Revit, but these fields are general-purpose notes fields and are not the standard, purpose-built identifiers for door scheduling. Schedulers and contractors expect Mark and Type Mark, not Comments fields, for door identification. C is the nuclear option — duplicating a type for every opening defeats the entire purpose of type-based management. You'd lose the efficiency of shared type properties and create a maintenance nightmare for twenty separate types. A reliable study tip: when you see "unique per element" think instance parameter (Mark); when you see "shared across a type" think type parameter (Type Mark). This pairing appears frequently on Revit certification questions.

Question 8

Six doors use the same door type. Without selecting all six doors, a user selects one of them, opens Edit Type, and changes the type's Width parameter.

What is the expected result after the user confirms the change?

Only the selected door changes because Edit Type was opened from that instance
All six doors of that type change because they share the edited type definition (correct answer)
A new type is created automatically and assigned only to the selected door
The selected door changes temporarily, but the others update only after regeneration

Explanation: Whenever you see a question about modifying parameters in Revit, the first thing to ask yourself is: am I changing a type parameter or an instance parameter? This distinction is fundamental to how Revit's parametric engine works. Revit organizes elements using a two-level hierarchy: types and instances. A type definition is a shared blueprint — every element assigned that type inherits its type parameters. Width, on a standard door family, is a type parameter, meaning it belongs to the type itself, not to any individual placement of it. When you open Edit Type (as opposed to simply editing properties in the Properties panel), you are directly modifying that shared blueprint. The result is that all six doors, which share the same type definition, update simultaneously — making B the correct answer. A is wrong because Edit Type does not scope changes to the element you happened to select. Selection is merely your entry point into the type dialog; it doesn't limit the change to that one instance. C describes what would happen if you used the Duplicate button inside Edit Type before changing the parameter — that workflow intentionally creates a new type for isolated changes, but the question states no duplication occurred. D is a fabricated behavior; Revit applies type changes immediately and globally upon confirmation, with no deferred regeneration step needed for other instances. A useful rule of thumb: if the parameter lives under Edit Type, changing it affects every element of that type. If it lives in the Properties panel (instance properties), it affects only the selected element.

Question 9

A project contains twelve windows of type Fixed 900 x 1200. One selected window must become 1000 mm wide while the other eleven must remain unchanged. Width is defined as a type parameter in the family.

Which procedure accomplishes the change without altering the other windows?

Edit the existing type, change Width to $1000\text{ mm}$ , and confirm the change
Duplicate the existing type, set Width to $1000\text{ mm}$ , and assign the duplicate to the selected window only (correct answer)
Override the selected window's instance Width to $1000\text{ mm}$ in the Properties palette
Reload the window family with Width set to $1000\text{ mm}$ as the default parameter

Explanation: Whenever Revit asks you to change one instance of a type while leaving others untouched, the central concept being tested is the Type vs. Instance parameter distinction — and what to do when the parameter you need to change is defined at the type level. In Revit, a type parameter applies uniformly to every element sharing that type. Width in this family is a type parameter, meaning you cannot simply override it for a single window the way you would an instance parameter. The only legitimate way to give one window a different width is to create a separate type that carries that width value. That is exactly what option B accomplishes: you duplicate the existing type (creating "Fixed 1000 x 1200," for example), set Width to

1000\text{ mm}

on the duplicate only, and then assign that new type exclusively to the selected window. The eleven remaining windows keep their original type and remain

900\text{ mm}

wide. Option A is the classic trap — editing the existing type changes Width for all twelve windows simultaneously, because every instance shares the same type definition. Option C sounds appealing, but Width is a type parameter, not an instance parameter, so no Width field appears in the instance Properties palette for an individual window; you simply cannot override it there. Option D reloading the family with a new default would affect the entire family definition and would not selectively target one window. The study tip to remember: when a parameter is at the type level, your only tool for selective change is duplication — spot that distinction immediately in any Revit exam question.

Question 10

A single-swing door has the correct wall location and must continue to swing into the room. However, its hinges must move from the left jamb to the right jamb.

Which modification most directly produces the required result?

Use Flip Facing to reverse the door's in/out swing while keeping the hinge side
Mirror the door about its center to reverse the hinge side independently of the host
Rotate the door 180° to swap the hinge side within its host wall
Use Flip Hand to move the hinge from one jamb to the other while preserving the swing direction (correct answer)

Explanation: When working with doors in Revit, you need to understand that every door instance has two independent flip controls: Flip Hand and Flip Facing. Flip Hand controls which jamb holds the hinges (left vs. right), while Flip Facing controls the swing direction (into vs. out of the room). Keeping these two controls mentally separate is the key to answering this question correctly. The scenario tells you the swing direction is already correct — the door swings into the room as required — but the hinge side needs to change. That is precisely what Flip Hand (D) does: it mirrors the hand of the door, moving the hinge from one jamb to the other, without altering which direction the door swings. It directly solves the problem with a single click. Choice A describes Flip Facing, which reverses the in/out swing — the opposite of what you want. Using it would fix nothing and actually break what's already correct. Choice B suggests mirroring the door about its center, which would affect the door's geometry but isn't the standard, controlled workflow Revit provides; it could also produce unintended results with the host wall relationship. Choice C, rotating 180°, would flip both the hand and the facing simultaneously, changing the swing direction you were specifically told to preserve — a classic double-change trap. Study tip: Memorize the phrase "Hand = hinge side, Facing = swing direction." On the exam, whenever a question specifies that only one of those two properties needs to change, immediately identify which flip control targets that property alone.