Autodesk Revit Quiz: Tags
10 questions · exam conditions
0:00
TagsQuestion 1 of 10

A project contains two loaded door tag types. The existing doors use the correct office-standard tag, but each new use of Tag by Category initially places the other door tag type.

Which action best corrects the default behavior without replacing the tags already placed?

Rename the office-standard tag type so it appears first alphabetically in the Project Browser.
Set the office-standard door tag in Loaded Tags and Symbols for the Doors category.
Select an existing standard tag and use Match Type Properties on every untagged door.
Unload the unwanted door tag family after changing all existing tags to the standard type.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Tags

Practice Tags 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 Tags, 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 project contains two loaded door tag types. The existing doors use the correct office-standard tag, but each new use of Tag by Category initially places the other door tag type.

Which action best corrects the default behavior without replacing the tags already placed?

  1. Rename the office-standard tag type so it appears first alphabetically in the Project Browser.
  2. Set the office-standard door tag in Loaded Tags and Symbols for the Doors category. (correct answer)
  3. Select an existing standard tag and use Match Type Properties on every untagged door.
  4. Unload the unwanted door tag family after changing all existing tags to the standard type.
Explanation: When you encounter questions about Revit's default behavior for annotation tools, think about where Revit stores those defaults — specifically, the Loaded Tags and Symbols dialog found under the Annotate tab. This dialog lets you designate which tag family type Revit will use by default when you run Tag by Category for each element category. That's precisely the setting this question is testing. Choosing option B is correct because navigating to Annotate → Tag → Loaded Tags and Symbols and selecting the office-standard door tag for the Doors category directly controls what Revit places by default on future tagging operations. It fixes the root cause without disturbing any tags already placed in the model. Option A is a misconception trap — alphabetical order in the Project Browser has no bearing on which tag type Revit selects by default. Renaming families is a workaround based on a misunderstanding of how Revit resolves defaults. Option C uses Match Type Properties, which copies type parameters from one element to another — useful for changing element types, but it applies to already-placed tags, not untagged doors, and still doesn't fix the default for future placements. Option D would prevent the unwanted tag from being placed again, but unloading a family is a heavy-handed approach that removes it from the project entirely, which may be undesirable if the tag is needed elsewhere or for coordination purposes. As a study tip, remember that Loaded Tags and Symbols is Revit's central control panel for annotation defaults by category. On the exam, whenever a question involves "what gets placed by default," this dialog is almost always the correct lever to pull.

Question 2

A project parameter named Asset Code is bound to the Doors category. In a newly created door tag family, the parameter is not available when a label is created. The tag must report the value stored on each door.

Which workflow will make Asset Code available to the tag while preserving an editable value on each door?

  1. Add Asset Code as a text parameter in the tag family, then match its spelling to the project parameter.
  2. Create Asset Code as a family parameter in every door family and as a separate family parameter in the tag.
  3. Create Asset Code as a shared instance parameter, bind it to Doors, and use that shared parameter in the tag label. (correct answer)
  4. Add Asset Code as static text in the tag family, then associate the text with each tagged door instance.
Explanation: Whenever you see a Revit question about tags reporting project parameter values, the core concept being tested is the difference between project parameters, family parameters, and shared parameters — and only one of these three can bridge the gap between a project and a family file. Project parameters (like the original Asset Code in this scenario) are stored internally in the project file and cannot be accessed by family files, including tag families. This is the fundamental limitation you need to recognize. The solution is to use a shared parameter: a definition stored in an external .txt file that both the project and any family can reference simultaneously. Because they share the same GUID-based definition, Revit treats them as the same parameter across contexts. Creating Asset Code as a shared instance parameter, binding it to the Doors category in the project, and inserting it into the tag label is the only workflow that allows the tag to read and display the value stored on each door instance — making C correct. A is a common trap: naming a tag's text parameter identically to a project parameter does not link them. Revit does not match parameters by spelling; it matches by shared GUID. B misunderstands the architecture — family parameters in door families are not accessible to tag families, and having two separate family parameters in different families still creates no connection between them. D confuses static text (hardcoded labels) with dynamic parameter-driven values; static text cannot report per-instance data. Your study tip: whenever a tag must report a project value, ask yourself "Is this a shared parameter?" If it isn't shared, the tag cannot see it.

Question 3

A floor plan contains 1212 doors. Two visible doors already have door tags, three other doors are hidden in that view by a view filter, and the remaining visible doors are untagged. The user runs Tag All Not Tagged and selects only the Doors category.

How many new door tags should Revit place in that view?

  1. 77 new tags, because only visible and currently untagged doors qualify. (correct answer)
  2. 99 new tags, because existing tags are excluded but hidden doors still qualify.
  3. 1010 new tags, because visibility is considered but existing tags are replaced.
  4. 1212 new tags, because the command processes every door assigned to the level.
Explanation: When working with Tag All Not Tagged in Revit, the key principle to keep in mind is that the command does exactly what its name says — it tags elements that are both visible in the current view and currently untagged. Both conditions must be true simultaneously. Let's walk through the math. You start with 1212 total doors. Three are hidden by a view filter, leaving 99 visible doors. Of those 99 visible doors, 22 already have tags. That leaves 9−2=79 - 2 = 7 doors that are visible and untagged — and those are precisely the ones Tag All Not Tagged will act on. Answer A is correct. Answer B is tempting if you forget that view filters suppress elements from the command's scope. Revit treats hidden elements as nonexistent for tagging purposes, so those 33 hidden doors are completely ignored, making 99 the wrong starting point for new tags. Answer C introduces a false premise — Tag All Not Tagged never replaces existing tags; it only adds tags where none exist, so 1010 is both arithmetically and conceptually wrong. Answer D would be correct only if the command operated at the project or level level rather than the view level, but it strictly respects the current view's visibility state, ruling out all 1212 doors. A useful study tip: whenever you see a question about Tag All Not Tagged, build a quick two-filter mental checklist — "Is the element visible in this view? Does it already have a tag?" Only elements that pass both filters get tagged.

Question 4

A coordinated floor plan contains room, door, and window tags. A second plan is needed with the same model visibility and an independent copy of all current tags so that the copied annotations can later be edited without changing the original plan.

Which view-creation method most directly produces the required result?

  1. Create a dependent duplicate so the copied tags remain synchronized with the primary view.
  2. Use Duplicate with Detailing so the annotation elements are copied into an independent view. (correct answer)
  3. Use Duplicate so all model and annotation elements are copied into an independent view.
  4. Create a new plan at the same level so Revit automatically regenerates matching tags.
Explanation: Whenever you see a question about duplicating views in Revit, the key distinction to understand is what gets copied — model elements, annotation elements, or both — and whether those copies stay linked to the original view or become independent. In Revit, Duplicate with Detailing (answer B) copies the view along with all its annotation elements — tags, dimensions, text notes, detail lines, and so on — into a fully independent view. "Independent" here means you can edit those tags in the new view without touching the originals, which is exactly what the scenario requires. The model visibility (what categories are shown, with what graphics) is inherited through view template settings or simply matched, and the annotations become your own working copies. Answer A, creating a dependent duplicate, does the opposite of what's needed. Dependent views share annotation elements with their primary view — changes in one reflect in the other — so editing tags in the copy would alter the original, violating the scenario's requirement. Answer C, plain Duplicate, copies the view's model visibility settings but intentionally excludes all annotation elements. You'd start with a blank slate of tags, meaning no copied annotations exist to edit at all. Answer D is a trap for students unfamiliar with Revit's behavior. Creating a new plan at the same level does not auto-generate matching tags. Tags must be placed manually; Revit has no mechanism to automatically regenerate the previous view's annotation work. A useful rule of thumb: think of the three duplicate options as a spectrum — Duplicate (model only) → Duplicate with Detailing (model + annotations) → Dependent Duplicate (shared annotations). Match the option to what the scenario needs copied and how independently.

Question 5

A door tag has a leader. The documentation standard requires the leader endpoint to be positioned at a specific graphic location near the door rather than remain attached to the tagged element's boundary.

Which modification provides the required leader behavior while keeping the tag associated with the door?

  1. Pin the tag head and drag the leader endpoint to the required graphic location.
  2. Change the leader condition to Free End, then reposition the endpoint at the required location. (correct answer)
  3. Add a leader elbow and align the elbow with the required endpoint location.
  4. Convert the tag to a text note and draw a separate detail line as its leader.
Explanation: When working with tags in Revit, understanding leader attachment types is essential. Tags can have leaders that are either attached to the element's boundary or set to a "Free End," which lets you place the leader endpoint anywhere independently of the element geometry. Questions like this test whether you know how to control that behavior without breaking the tag's association with its host element. The key to this question is the phrase "specific graphic location near the door rather than remain attached to the tagged element's boundary." That language signals you need a Free End leader — Revit's built-in option that decouples the arrowhead endpoint from the element edge while keeping the tag fully associated with the door. You access this by selecting the tag, then changing the Leader property in the Properties palette from "Attached End" to "Free End." Once set, you can drag the endpoint precisely where your documentation standard requires. This is exactly what B describes, making it the correct answer. A is a trap — pinning locks the tag's position but does nothing to control where the leader endpoint sits; the endpoint remains constrained to the element boundary. C is a partial understanding of leader behavior. Adding an elbow reshapes the leader's path but still doesn't free the endpoint from the element; you're adjusting the middle, not the end. D destroys the parametric relationship entirely. Converting to a text note means the label is no longer a real tag — it won't update if the door mark changes, which defeats the purpose of tagging. Remember: whenever a leader endpoint needs to be repositioned freely, your first instinct should be Free End in the tag's leader settings.

Question 6

An office wants one multi-category tag to report Asset ID for both furniture and mechanical equipment families. Separate non-shared family parameters named Asset ID already exist in those families.

Which revision is necessary for one multi-category tag to report the value reliably from both categories?

  1. Keep the existing family parameters and create a tag label with the same parameter name and data type.
  2. Replace the parameters with category-specific built-in Mark values and combine both values in one label.
  3. Use the same shared Asset ID parameter in both categories and add that shared parameter to the tag label. (correct answer)
  4. Create two nested category tags inside a generic annotation family and expose both Asset ID values.
Explanation: Whenever a tag needs to read parameter values across multiple categories in Revit, you need to understand the critical distinction between family parameters and shared parameters. Family parameters are internal to a single family file — they cannot be scheduled, tagged, or referenced externally. Shared parameters, by contrast, are defined in a shared parameter file and carry a unique GUID, which allows Revit to recognize them as the same parameter regardless of which family they live in. This is exactly why C is correct. A multi-category tag works by looking for a specific shared parameter GUID across all tagged elements. When both the furniture and mechanical equipment families use the same shared Asset ID parameter (same GUID, same data type), the tag label can reliably find and display that value from either category. The tag doesn't care what category the element belongs to — it just looks for the matching shared parameter. Choice A fails because even if two separate family parameters share an identical name and data type, they have no shared GUID. A multi-category tag cannot reconcile them as the same parameter — it will show no value or an error for one or both categories. Choice B is a workaround that misuses the built-in Mark parameter, which is a generic identifier not intended for custom asset tracking. It also doesn't solve the underlying parameter-recognition problem for a custom field like Asset ID. Choice D overcomplicates the solution entirely. Nested category tags inside a generic annotation family creates a fragile, maintenance-heavy workaround when a shared parameter solves the problem cleanly. Your key takeaway: whenever you see a question about tags or schedules spanning multiple categories, think shared parameters — they're the only parameter type that works across category boundaries in Revit.

Question 7

A user deletes every room tag from one floor plan. The rooms must remain in the model because they are listed in a room schedule and are tagged in another plan.

What is the expected result, and how can the annotations be restored efficiently?

  1. The rooms are deleted from the model; recreate them before using Tag All Not Tagged.
  2. The rooms become unplaced; place them again and reload the original room tag family.
  3. The rooms remain only in the schedule; drag each scheduled room back into the floor plan.
  4. The rooms remain in the model; use Tag All Not Tagged for Rooms in the affected plan. (correct answer)
Explanation: Whenever you see a question about deleting annotations in Revit, the key distinction to understand is the difference between model elements and view-specific annotations. Room tags are annotations — they exist only in the view where they were placed. Rooms themselves, however, are model elements that live in the project database independently of any tag or view. When you delete room tags from a floor plan, you are removing only the view-specific labels. The underlying room objects remain fully intact in the model, continue to appear in schedules, and stay tagged in any other view where tags were placed. This is why D is correct: the rooms are unaffected, and the fastest way to restore tags in that plan is to use Tag All Not Tagged (found under the Annotate tab), filtered for Rooms. Revit will automatically place tags on every room in the view that currently lacks one — no manual clicking required. A is wrong because rooms are not deleted when their tags are removed; deleting a tag never deletes its host model element. B is a trap — rooms only become "unplaced" if you explicitly remove them from a plan using the Room tool, not by deleting a tag. Reloading the tag family is also unnecessary here. C misunderstands how schedules work; rooms listed in a schedule are still fully placed in the model, and you cannot "drag" them from a schedule back into a view as if they were unplaced. As a study tip, remember this rule: tags are views, rooms are model. Any question testing deletion behavior should prompt you to ask which category the deleted element belongs to.

Question 8

A wall includes an exterior finish material and a concrete core material. Both materials have different Description values. In a view where the exterior face can be selected, a user places a material tag on that face.

If the material tag family labels the material Description parameter, which value should the tag report?

  1. The description of the wall type, because the wall is the element selected for tagging.
  2. The description of the concrete core, because structural materials take priority in compound walls.
  3. The description of the exterior finish material identified at the selected face location. (correct answer)
  4. The description of the wall's default material, regardless of the face selected during placement.
Explanation: When working with material tags in Revit, it helps to understand that compound walls are made of multiple layers, each assigned its own material. A material tag doesn't report information about the wall type as a whole — it reports information about the specific material layer at the exact point where you place the tag. This is fundamentally different from an element tag, which reads type or instance parameters of the host element itself. Because the user places the tag on the exterior face, Revit identifies which wall layer exists at that location and pulls the Description parameter from that layer's material. In this case, that's the exterior finish material, making C the correct answer. A is wrong because a material tag bypasses the wall type entirely. The wall type has its own parameters, but a material tag is designed specifically to interrogate the material at the picked point — not the parent element's properties. B reflects a common misconception that structural layers have some kind of data priority in compound walls. Revit does use the structural core for certain calculations, but it does not override material tag behavior based on structural priority. The tag reports whichever layer you actually click. D is incorrect because there is no concept of a "default material" that overrides face-specific placement logic for material tags — the placement point is always the determining factor. As a study tip, remember the distinction: element tags read the host element's parameters, while material tags read the specific material layer at the placement point. Questions that mix these two concepts are a common trap on the Revit exam.

Question 9

Six doors are instances of the same door type. Their tags currently label Type Mark. After Type Mark is changed for one door type, all six tags display the new value. The project standard requires a different identifier for every door instance.

Which change best meets the project standard while retaining a single door type?

  1. Duplicate the door type six times and continue labeling the Type Mark parameter.
  2. Convert Type Mark from a type parameter to an instance parameter inside the tag family.
  3. Override the displayed text separately in each tag without changing the tagged doors.
  4. Revise the tag to label the instance-based Mark parameter and assign each door a unique value. (correct answer)
Explanation: Whenever Revit questions describe a value that updates identically across multiple elements, you're being tested on the distinction between type parameters and instance parameters. Type parameters are shared by every instance of a type — change one, change all. Instance parameters belong to individual elements and can hold unique values per door, wall, or window. The project standard here demands a unique identifier per door instance, not per door type. The built-in Mark parameter is exactly that — an instance-based parameter. By revising the tag family to label Mark instead of Type Mark, and then assigning each of the six doors its own Mark value, you get six distinct labels while all six doors remain the same single type. That's why D is correct: it solves the problem at the right level (the instance) without unnecessary duplication. A is tempting but wasteful — duplicating the type six times just to get unique Type Marks defeats the purpose of type-based families and bloats the project. You'd also have to manage six nearly identical types going forward. B sounds logical but reveals a misunderstanding: you cannot convert a type parameter into an instance parameter by editing the tag family. The tag only reads the parameter; the parameter's type/instance classification lives in the door family itself, and even then, core built-in parameters like Type Mark can't be freely reclassified. C is a workaround — overriding displayed text in tags is manual, error-prone, and breaks the live link between the tag and the element data, which undermines the whole point of parametric tagging. Your study tip: memorize which common parameters are type-based (Type Mark, Type Comments) versus instance-based (Mark, Comments). Exam questions frequently hinge on that distinction.

Question 10

An architect places door tags in a host-model plan by selecting doors contained in a linked Revit model. A consultant later opens the linked model directly and does not find those tags.

Which explanation best describes this result?

  1. The tags are view-specific annotations stored in the host model; tagging linked doors does not add annotations to the linked file. (correct answer)
  2. The tags are stored in the linked model but remain hidden there until the host model is opened at least once.
  3. The tags are model elements stored in the host model and should therefore appear automatically in every host view.
  4. The tags are temporary references to linked doors and are removed whenever either project file is closed.
Explanation: Whenever you see a question about tagging elements in linked Revit models, think about where annotations live in Revit's data structure. Revit separates model elements (walls, doors, floors) from annotation elements (tags, dimensions, text notes), and annotations are always view-specific — they exist only in the file and view where you placed them. When you tag a door in a linked model, Revit creates the tag inside your host model, associated with the current view. The tag references the linked door's data, but the annotation itself is stored in the host file. This is why A is correct: the consultant opens the linked file directly and finds no tags, because those tags were never written into the linked file — they live exclusively in the host model's view. B is wrong because tags don't have a "hidden until the host opens" state — this describes a behavior that simply doesn't exist in Revit. C is wrong on two counts: tags are annotation elements, not model elements, and even if they were model elements, they would not automatically appear in every view. D is wrong because tags are permanent annotations saved with the host file; they are not temporary references that disappear when files are closed. A useful study tip: remember the phrase "annotations stay home." No matter what you're tagging — a linked element, a room, a structural member — the tag always belongs to the file where you placed it, in the specific view you were working in. This principle applies to dimensions, keynotes, and text notes as well.