All questions
Question 1
A text note fits correctly on a sheet, but its text block overlaps a nearby dimension. The text height and note content must remain unchanged. There is enough vertical space for the note to occupy additional lines.
What should the user do to resolve the overlap with the least disruption?
- Reduce the text note type's width factor until the existing line fits beside the dimension.
- Drag the text note's width control inward so the content wraps onto additional lines. (correct answer)
- Reduce the text note type's text size and enlarge the text box to retain the current line breaks.
- Insert manual spaces into the note until the text shifts away from the nearby dimension.
Explanation: When working with text notes in Revit, it helps to separate two distinct controls: the type properties (which affect all instances of that text type) and the instance-level width grip (which controls only the selected note's line-wrapping). Questions about resolving overlap without changing content or text size are really asking you to identify the most localized, non-destructive adjustment available.
Dragging the width control grip inward — choice B — is exactly that adjustment. Every text note in Revit has a blue triangle grip at the right edge of its text block. Pulling it left narrows the text box, forcing the content to wrap onto additional lines. Because the passage confirms vertical space is available, the note simply grows taller rather than wider, clearing the dimension without touching the text height or the type definition.
Choice A modifies the type's width factor, a type property that rescales the horizontal stroke width of every character — effectively changing how the text looks, and applying that change to every note sharing that type. That violates the constraint that content and appearance must stay the same. Choice C explicitly reduces text size, which the question forbids outright. Choice D — padding the note with manual spaces — is an unreliable workaround; spaces are not a controlled layout mechanism and will behave unpredictably when the view scale or sheet layout changes.
As a study tip, remember that in Revit, instance grips change only the selected element, while type properties change all instances of that type. Exam questions that emphasize "least disruption" or "unchanged appearance" are almost always pointing you toward an instance-level control.
Question 2
A drafting detail includes a note for a temporary protection requirement. The note must use an entry from the project's keynote file, but it must not change automatically when the nearby model element or its material is replaced.
Which keynote type is most appropriate?
- An Element Keynote selected from the keynote assigned to the nearby element type.
- A Material Keynote selected from the keynote assigned to the element's finish material.
- A User Keynote selected directly from the project's available keynote entries. (correct answer)
- An Element Keynote assigned through the nearby element's instance Comments parameter.
Explanation: When working with keynotes in Revit, the critical distinction to understand is what controls the keynote value and what triggers it to change. Revit offers three keynote types, each with a different source of intelligence: Element Keynotes pull from the keynote assigned to an element's type, Material Keynotes pull from the keynote assigned to a material, and User Keynotes let you manually select any entry from the keynote file without tying the tag to any element or material property.
The scenario requires two things simultaneously: the note must draw from the project's keynote file (ensuring standardized numbering and descriptions), and it must remain stable even if the nearby element or its material is swapped out. A User Keynote satisfies both conditions. You browse the keynote file and pin a specific entry to the tag manually — that value is yours to control and won't shift because of model changes. This makes C the correct choice.
Choice A fails because an Element Keynote is directly linked to the element type's keynote property. Replace the element type, and the keynote value changes automatically — exactly what the scenario prohibits. Choice B has the same problem at the material level; a Material Keynote mirrors whatever keynote is assigned to the finish material, so swapping materials changes the note. Choice D is a distractor that doesn't reflect how Revit actually works — keynotes are not assigned through an instance's Comments parameter, so this option describes a nonexistent workflow.
A useful study tip: when a Revit question mentions "must not change automatically," that's your signal to look for the option that gives the user manual, persistent control — in keynotes, that's always the User Keynote.
Question 3
An office keynote file uses classification keys such as 07 21 00 and 09 29 00. The documentation manager requires a given key to display the same identifier on every sheet, regardless of the order in which tags are placed.
Which keynote numbering method should be selected?
- Use By Sheet, because it preserves the classification key as the identifier on every sheet.
- Use By Sheet with sequential numbering reset to 1 on each sheet, then manually align the numbers to the keys.
- Use By Sheet, but set the starting number to match the first classification key in the file.
- Use By Keynote, because the displayed identifier is based on the keynote file's key value. (correct answer)
Explanation: When you see a question about keynote numbering in Revit, focus on what controls the displayed identifier — the number or code the tag actually shows on the sheet. Revit offers two keynoting methods: By Sheet and By Keynote, and they behave very differently.
By Keynote uses the key value directly from the keynote file as the tag's displayed identifier. So if your keynote file assigns the key 07 21 00 to thermal insulation, every tag referencing that element will display 07 21 00 on every sheet, automatically and consistently — no manual intervention required. This is exactly what the documentation manager needs. D is correct.
Here's why the other choices fail: A is factually wrong in its reasoning — By Sheet does not preserve the classification key as the identifier. By Sheet assigns sequential integers (1, 2, 3…) based on the order tags appear on each sheet, so the same element could display a different number on different sheets. B acknowledges By Sheet's sequential nature and suggests a manual workaround, but this defeats the purpose of automation and is error-prone — it also cannot reliably force numbers to match arbitrary classification keys like 09 29 00. C contains a similar misconception: By Sheet's starting number is a sequential counter, not a mechanism to mirror alphanumeric classification keys from the keynote file.
As a study tip, remember this distinction: By Sheet = sequential integers per sheet (order-dependent), By Keynote = the actual key string from your file (order-independent). If consistency across sheets is required, By Keynote is almost always the answer.
Question 4
The same keynote legend view is placed on several sheets. Each sheet should list only the keynotes appearing in the views placed on that particular sheet, rather than every keynote used in the project.
Which change should be made to the keynote legend?
- Enable Filter by Sheet so each placed legend instance reports keynotes used on its host sheet. (correct answer)
- Apply a view filter that hides keynote tags whose element categories are absent from the sheet.
- Enable Crop View so the legend includes only keynotes inside the sheet's title block boundary.
- Create a phase filter that includes only keynote tags created in views placed on the sheet.
Explanation: Keynote legends in Revit have a built-in property designed exactly for sheet-specific filtering, so when you see a question about controlling what a legend displays per sheet, think about the legend's instance properties rather than workarounds like filters or phases.
The key setting is Filter by Sheet, which is an instance property available on each placed keynote legend. When enabled, Revit automatically scans the views hosted on that sheet and displays only the keynote tags that appear within those views. This means the same legend type can be placed on multiple sheets, yet each instance intelligently reports only the keynotes relevant to its sheet — no manual maintenance required. Answer A correctly identifies this built-in mechanism.
The distractors each represent plausible-sounding but fundamentally wrong approaches. Answer B describes a view filter, which controls element visibility within a model view — it cannot interrogate which keynotes appear across a sheet's collection of views or filter legend rows. Answer C confuses keynote legends with regular model views; crop regions apply to views showing geometry in 3D or 2D space, not to schedule-style legends, which don't have a spatial crop boundary. Answer D introduces phase filters, which govern element visibility based on construction phase — keynote tags aren't phase-dependent in a way that would isolate them by sheet placement.
A useful study tip: Revit often has a dedicated, purpose-built control for common documentation needs. Before reaching for workarounds like view filters or phases, check the element's Type and Instance Properties first — the solution is frequently already there, as it is with Filter by Sheet.
Question 5
A section detail requires identical blocking components distributed along a sloped boundary. The specified spacing is a maximum: the actual spacing may be reduced so the components fill the entire selected path, but it must not exceed the specified limit.
Which repeating detail layout option should be used?
- Use Fixed Distance so components remain at the exact specified spacing and any remainder stays unused.
- Use Fixed Number so the specified spacing directly determines how many components are placed.
- Use Maximum Spacing so Revit distributes components without exceeding the specified spacing limit. (correct answer)
- Use Fill Available Space so Revit stretches each component to occupy an equal portion of the path.
Explanation: When working with Repeating Detail Components in Revit, the key is matching the layout rule to the spacing constraint described. Ask yourself: does the scenario specify an exact count, a fixed gap, a maximum limit, or full coverage?
Here, the requirement is a maximum spacing — components must be distributed so the gap never exceeds the limit, but Revit is free to tighten the spacing as needed to fill the entire path evenly. That description maps directly to the Maximum Spacing option (C). Revit calculates how many components fit within the limit, then distributes them across the full length — potentially at a slightly smaller interval — ensuring complete coverage without violating the cap.
Choice A, Fixed Distance, places components at the exact spacing you specify and stops when the path runs out, leaving a potential gap at the end. That violates the "fill the entire path" requirement. Choice B, Fixed Number, takes a count as input — not a spacing value — so the specified spacing dimension wouldn't logically drive the number placed; this conflates two different inputs. Choice D, Fill Available Space, stretches or scales each component instance to divide the path into equal segments, which distorts the component geometry rather than adjusting spacing — inappropriate when you need identical, unmodified blocking pieces.
A useful memory rule: Maximum Spacing = flexible distribution with a hard ceiling. Whenever a question mentions "must not exceed" alongside "fill the entire length," that phrasing is the signature of Maximum Spacing. Watch for distractors that sound similar — Fixed Distance seems close, but it doesn't guarantee full-path coverage.
Question 6
In a wall section, a keynote must identify the exterior finish material rather than the wall assembly as a whole. The keynote should update when the finish material assigned to that layer is replaced with another material.
Which setup should be used?
- Assign a keynote to the wall type and place an Element Keynote on the exterior wall face.
- Assign a keynote to the finish material and place a Material Keynote on that material layer. (correct answer)
- Assign a keynote to the wall instance and place a User Keynote beside the exterior wall face.
- Assign a keynote to the wall category and place an Element Keynote on the wall instance.
Explanation: When working with keynotes in Revit, the key distinction is understanding the three keynote types and what drives automatic updates. Revit offers Element Keynotes (tied to the element's type), Material Keynotes (tied to a specific material), and User Keynotes (manually entered text). When a question asks about identifying a specific layer's material that should update automatically when that material changes, you should immediately think: Material Keynote.
Option B is correct because assigning a keynote directly to the finish material means the note travels with that material wherever it's used. When you place a Material Keynote tag on that wall layer, Revit reads the keynote from the material's properties — so if you swap the finish material for another, the tag updates automatically to reflect the new material's keynote. This is exactly the behavior the scenario requires.
Option A fails because an Element Keynote references the wall type as a whole, not an individual layer's material. It cannot distinguish between layers or reflect material-specific changes. Option C uses a User Keynote, which is a manually typed note with no parametric link to anything — it will never update automatically when materials change. Option D assigns the keynote to the wall category, which is even broader than the type; category-level keynotes apply globally and have no connection to material properties or individual layer composition.
A useful rule of thumb: match the keynote type to the level of specificity required. Material → Material Keynote, whole element → Element Keynote, freeform annotation → User Keynote. If the question mentions automatic updates tied to a material, B-type thinking (Material Keynote) is almost always correct.
Question 7
A specification editor changes the description associated with an existing key in the external keynote text file. The key itself is unchanged. Revit is still open, and existing keynote tags continue to display the old description in a keynote legend.
What should the Revit user do next?
- Reload the keynote file through Keynoting Settings so the existing key uses the revised description. (correct answer)
- Reload the tagged model families so their keynote labels acquire the revised description.
- Delete and recreate every keynote tag because existing tags store permanent copies of descriptions.
- Purge unused keynote entries and reopen each view containing a keynote legend.
Explanation: Whenever you see a question about Revit keynotes, think about where descriptions actually live — not inside the model, but in an external text file that Revit reads on demand. Keynote tags store only the key (a short alphanumeric code); the human-readable description is pulled from the linked keynote file each time Revit loads it. This separation is intentional: it lets specification teams update descriptions without anyone touching the model itself.
Because the description lives in the external file, the fix is simply telling Revit to re-read that file. You do this through Manage → Keynoting Settings → Reload, which is exactly what A describes. Once reloaded, every tag sharing that key instantly displays the updated description — no tag editing required.
B is wrong because the keynote description has nothing to do with the model families that are tagged. Reloading families would affect geometry, parameters, or type data — not the external keynote text file.
C reflects a fundamental misconception. Tags do not permanently embed descriptions; they reference the key, which points back to the file. Deleting and recreating tags is unnecessary busy work and would produce the same result as a simple reload.
D confuses two unrelated workflows. Purging unused elements removes objects that aren't referenced anywhere in the project — it has no mechanism for refreshing the content of an external keynote file, and reopening views changes nothing about what the file contains.
A useful rule of thumb: in Revit, anything linked externally (keynote files, CAD links, Revit links) requires a deliberate reload action to reflect outside changes. Keep that reload habit in mind for any question involving external file updates.
Question 8
A project contains many text notes that use the type 3 mm Arial. One note must use Calibri while retaining the same text height, border, background, and leader arrowhead. Other notes must remain unchanged.
Which workflow best satisfies the requirement?
- Duplicate the text note type, change the duplicate's font to Calibri, and assign it to the one note. (correct answer)
- Change the font property of the existing text note type, and override the other notes back to Arial.
- Edit the note, select all of its characters, and apply Calibri from the contextual text-formatting tools.
- Create a new text note with Calibri, then use Match Type Properties on the existing Arial notes.
Explanation: Whenever a Revit question asks you to change one instance's appearance while leaving all others untouched, your instinct should be to work at the type level — specifically by duplicating a type rather than modifying the original.
In Revit, text notes are type-based elements. Every property you see listed under "Edit Type" — font, size, border, background, leader arrowhead — belongs to the type, not the individual instance. If you want one note to look different, the cleanest solution is to duplicate the existing type, rename it (e.g., "3 mm Calibri"), change only the font, and assign that new type to the single note. All other notes keep their original 3 mm Arial type, completely untouched. That's exactly what A describes, and it's the correct workflow.
B is a trap: modifying the original type changes every note using it simultaneously. You'd then have to manually re-override dozens of other notes, which is error-prone and defeats Revit's type-management system.
C is tempting because it sounds like a local override, but Revit's in-editor text formatting toolbar only applies rich-text character formatting (bold, italic, underline) — not font family changes at the type level. Selecting characters and "applying Calibri" this way doesn't actually change the underlying type font.
D misunderstands Match Type Properties: it copies type properties from a source element onto targets. Using it on the Arial notes after creating a Calibri note would spread Calibri to all of them — the opposite of what you want.
Study tip: On Revit exam questions, if the change must be isolated to one element, always ask yourself: "Should I duplicate the type?" The answer is almost always yes.
Question 9
A drafter adds a two-dimensional flashing representation to a building section. It should appear only in that section. Later, the section view must be copied so the new view initially contains the same flashing, text notes, and keynotes.
Which combination of actions meets both requirements?
- Place a Generic Annotation family in the section, then create the new view using Duplicate as Dependent.
- Place a Generic Model family in the section, then create the new view using ordinary Duplicate.
- Place a Detail Component in the section, then create the new view using ordinary Duplicate.
- Place a Detail Component in the section, then create the new view using Duplicate with Detailing. (correct answer)
Explanation: Whenever you see a Revit question combining "view-specific 2D graphics" with "copying a view," you need to think about two separate decisions: what type of element to place, and which duplication method to use.
For 2D drafting elements — things like flashing representations, insulation lines, or detail lines — the correct family type is a Detail Component. Detail Components live only in the view where they're placed, which is exactly what the scenario requires ("appear only in that section"). This immediately rules out B, which suggests a Generic Model family. Generic Models are 3D elements that appear in any view that cuts or sees them — they would show up across multiple views, violating the "only in that section" requirement.
A is wrong because Generic Annotation families are tag-like elements used for symbols and labels, not for drafting representations like flashing. They're also not the right tool for this kind of linework-based detail.
C correctly identifies the Detail Component but pairs it with ordinary Duplicate. Here's the critical distinction: plain Duplicate copies the view and its settings but carries over no view-specific 2D content — no detail components, no text notes, no keynotes. The new view starts empty of all that drafting work.
D is correct because Duplicate with Detailing copies the view and all of its view-specific 2D elements — Detail Components, text, keynotes, detail lines, and filled regions — into the new view. That satisfies the second requirement perfectly.
Remember this rule: if you ever need a copied view to inherit its 2D drafting content, always choose Duplicate with Detailing, never plain Duplicate.
Question 10
A saved Revit project and its keynote text file will be issued together. The project may be copied to different drive letters on consultants' computers, but the same folder relationship between the model and keynote file will be preserved.
Which keynote file path option is best suited to this arrangement?
- Use an absolute path so every copy continues to reference the original drive and folder.
- Use a relative path so the reference follows the preserved relationship between the two files. (correct answer)
- Use an absolute path and embed the keynote descriptions in the project before issuing it.
- Use a library-location path so Revit searches every folder beside the copied project automatically.
Explanation: Whenever Revit questions mention file paths for linked files or keynote tables, you need to think about where the reference is anchored — to a fixed location on one machine, or to a relationship between files that travels with the project.
A relative path stores the location of the keynote file in relation to the project file itself — for example, "look in the same folder as this project, then go up one level." Because the scenario tells you the folder relationship between the model and the keynote file is preserved across copies, a relative path will always resolve correctly regardless of which drive letter or root directory the files land on. That makes B the right choice.
A is wrong because an absolute path is anchored to a specific drive letter and full folder chain (e.g., C:\Projects\Keynotes\). The moment a consultant copies the project to their D:\ drive or a different root folder, the reference breaks entirely — the whole point the scenario warns you about.
C compounds the error in A by combining a broken absolute path strategy with embedding descriptions, which isn't actually a standard Revit workflow for keynote files. It doesn't solve the portability problem and introduces a false step.
D is a fabricated option — Revit does not have a "library-location path" mode that automatically searches folders beside a copied project. Don't be tricked by plausible-sounding invented features.
The study tip: on Revit exam questions about linked files, keynotes, or CAD underlays, absolute = fixed machine, relative = portable relationship. If the question mentions copying or sharing across computers, relative paths are almost always the answer.