Autodesk Revit Quiz: Revisions
10 questions · exam conditions
0:00
RevisionsQuestion 1 of 10

Revision numbering is set to Per Sheet. Sheet A101 contains revisions with the first and third project sequences. Sheet A102 contains revisions with the second and third project sequences. No revisions have custom numbering overrides.

How will the third project revision normally be numbered in the revision schedules on these two sheets?

It will be revision 3 on both A101 and A102 because its project sequence is third.
It will be revision 2 on both A101 and A102 because each sheet has two revisions.
It will be revision 2 on A101 and revision 3 on A102 because sequence 2 is absent from A101.
It will be revision 3 on A101 and revision 2 on A102 because sequence 1 is absent from A102.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Revisions

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

Revision numbering is set to Per Sheet. Sheet A101 contains revisions with the first and third project sequences. Sheet A102 contains revisions with the second and third project sequences. No revisions have custom numbering overrides.

How will the third project revision normally be numbered in the revision schedules on these two sheets?

  1. It will be revision 3 on both A101 and A102 because its project sequence is third.
  2. It will be revision 2 on both A101 and A102 because each sheet has two revisions. (correct answer)
  3. It will be revision 2 on A101 and revision 3 on A102 because sequence 2 is absent from A101.
  4. It will be revision 3 on A101 and revision 2 on A102 because sequence 1 is absent from A102.
Explanation: When Revit's revision numbering is set to Per Sheet, each sheet numbers its revisions independently based only on the revisions that appear on that specific sheet — the global project sequence number is irrelevant to the displayed number. Think of it this way: Revit looks at a sheet, collects only the revisions assigned to it, and then counts them in sequence order starting from 1. The number a revision receives is simply its rank among the revisions present on that sheet. Sheet A101 has project sequences 1 and 3. Because sequence 1 ranks first and sequence 3 ranks second among the revisions on that sheet, the third project revision becomes revision 2 on A101. Sheet A102 has project sequences 2 and 3. Sequence 2 ranks first, sequence 3 ranks second — so the third project revision is also revision 2 on A102. Both sheets independently arrive at 2, making B correct. Choice A is wrong because it confuses the project sequence number with the per-sheet number. "Per Sheet" mode explicitly ignores the global sequence when assigning displayed numbers. Choice C incorrectly assigns revision 2 to A101 (actually right for the wrong reason) but claims A102 shows revision 3, failing to recognize that A102 also has exactly two revisions, so its count also tops out at 2. Choice D makes the reverse error — it assumes the absence of sequence 1 from A102 somehow inflates A101's number to 3, which contradicts how per-sheet counting works. A handy tip: whenever a question mentions "Per Sheet" numbering, mentally re-index each sheet from 1 — the global project sequence is invisible to the sheet's revision schedule.

Question 2

A revision has been marked Issued. A designer then discovers that one of its existing revision clouds must be reshaped and its description corrected.

What is the appropriate Revit workflow for making these changes?

  1. Edit the cloud and description directly because the Issued setting affects printing only.
  2. Clear the Issued setting, make the required changes, and mark the revision issued again. (correct answer)
  3. Create a new revision, then edit the original issued revision through the new revision.
  4. Remove the revision from its sheets, make the changes, and add it back afterward.
Explanation: When working with revisions in Revit, understanding the purpose of the Issued flag is essential. It acts as a lock that protects finalized revision data from accidental changes — it doesn't merely affect printing behavior. This distinction is what this question is testing. Because the Issued setting genuinely restricts editing, the correct workflow (B) is to clear the Issued flag first, make your changes to the revision cloud geometry and description, and then re-mark the revision as Issued. Revit enforces this intentionally so that issued revisions remain traceable and reliable in a project's history. Once you uncheck Issued, the revision becomes editable again, and after your corrections are complete, you restore the locked state. Choice A is the most dangerous distractor — it incorrectly suggests the Issued flag is cosmetic, only affecting what prints. In reality, Revit will prevent you from editing clouds tied to an issued revision entirely, making this claim factually wrong. Choice C introduces unnecessary complexity; creating a new revision to access an old one is not a Revit feature and doesn't reflect how the revision system works. Choice D — removing the revision from sheets, editing, then re-adding — misunderstands the workflow. While detaching sheets might seem like a workaround, the Issued flag itself is what blocks editing, not the sheet association. Study tip: Think of the Issued flag as a commit in version control — it finalizes a state. To amend it, you must "uncommit," revise, and recommit. If you remember that Issued = locked (not just printed), you'll navigate revision management questions confidently.

Question 3

The project title block's revision schedule displays Revision Number, Date, and Description. The office standard requires the schedule to display Issued To as an additional column on every sheet that uses this title block.

Which workflow most directly implements the change while retaining Revit's automatic revision data?

  1. Edit each sheet's revision schedule instance and insert an Issued To column manually.
  2. Create a regular project schedule, filter it by sheet number, and overlay it on each title block.
  3. Edit the title block family, modify its revision schedule fields, and reload the family. (correct answer)
  4. Add a shared parameter to the sheet category and place a text label beside each schedule.
Explanation: Whenever you see a question about title blocks and revision schedules in Revit, remember that the revision schedule embedded in a title block is a family element — it lives inside the title block family, not on individual sheets. This means any change to its column structure must be made at the family level. Editing the title block family, modifying its revision schedule fields to include "Issued To," and then reloading the family into the project is the correct workflow (C). This approach propagates the change automatically to every sheet using that title block, and because it uses Revit's native revision schedule component, all revision data remains linked to the project's revision tracking system without any manual duplication. Choice A fails because revision schedule instances on sheets are not independently editable the way standard schedule views are — you cannot simply insert a column into each instance. This reflects a common misconception that sheet-level elements behave like standalone views. Choice B introduces an unnecessary workaround. A regular project schedule filtered by sheet number cannot replicate Revit's automatic revision tracking behavior, and overlaying it on a title block would require manual positioning on every sheet — defeating the "office standard on every sheet" requirement. Choice D conflates two separate tools. Shared parameters added to the sheet category would appear in sheet lists, not within the revision schedule itself. Placing a text label beside the schedule is purely cosmetic and breaks the connection to Revit's revision data entirely. The key study tip here: title block content = family editor. Any time a question asks you to globally change what appears inside a title block, the answer almost always involves editing and reloading the family.

Question 4

After an issue is completed, the BIM manager changes a revision's Show setting from Cloud and Tag to None. The revision still has clouds on several sheets, and none of those sheets is otherwise modified.

What should be expected when the affected sheets are displayed or printed?

  1. The clouds and tags are hidden, but the revision can remain listed in each applicable revision schedule. (correct answer)
  2. The clouds are hidden, and the revision is removed from every applicable revision schedule.
  3. The tags remain visible, but the clouds and revision-schedule rows are hidden.
  4. The clouds remain visible, but their tags and revision-schedule rows are hidden.
Explanation: Whenever you see a question about Revit's revision system, think about the two independent controls it gives you: visibility (the Show setting) and scheduling (whether a revision appears in the title block's revision schedule). These are separate mechanisms, and the exam loves to test whether you understand that distinction. When a BIM manager changes a revision's Show setting from Cloud and Tag to None, Revit suppresses the graphical display of both the revision clouds and their associated tags on every sheet where they exist. The clouds and tags become invisible — but the revision itself still exists in the project's revision list, and the title block's revision schedule reads from that list based on whether a revision cloud is placed on the sheet, not whether that cloud is currently visible. Because the clouds are still technically placed on those sheets (just hidden), the revision rows remain in each sheet's revision schedule. That makes A the correct answer: clouds and tags are hidden, but the revision stays listed in the applicable revision schedules. Choice B is wrong because changing Show to None does not delete the revision clouds or remove the revision from the schedule — it only hides their display. Choice C incorrectly claims tags remain visible while clouds are hidden; the None setting suppresses both simultaneously, not selectively. Choice D is similarly backwards — clouds don't stay visible while tags disappear; None hides everything graphical. A useful rule of thumb: visibility ≠ existence in Revit's revision workflow. The Show setting controls what you see, while schedule inclusion is controlled by cloud placement. Keep those two levers mentally separate on exam day.

Question 5

A revision cloud assigned to revision 5 is visible in a floor-plan view placed on sheet A401. The cloud has not been tagged. Revision 5 is not manually selected in Revisions on Sheet.

What should happen in A401's revision schedule under normal revision-schedule settings?

  1. Revision 5 appears only after it is also selected manually in Revisions on Sheet.
  2. Revision 5 does not appear until a revision tag is attached to the visible cloud.
  3. Revision 5 appears because the visible cloud associates the revision with A401 even without a tag. (correct answer)
  4. Revision 5 does not appear because only clouds drawn directly on sheets affect schedules.
Explanation: When working with Revit's revision tracking system, the key principle to understand is what triggers a revision to appear on a sheet's revision schedule: it's the presence of a visible revision cloud in any view placed on that sheet — not a tag, and not a manual selection. Revit automatically associates a revision with a sheet the moment a cloud carrying that revision number becomes visible through any viewport on that sheet. This means revision 5 appears in A401's revision schedule simply because the floor-plan view containing that cloud is placed there. That's why C is correct — the visible cloud is sufficient to link revision 5 to A401, with no tag required. A is wrong because manual selection in "Revisions on Sheet" is an additive tool — it lets you include revisions that have no visible clouds on that sheet. It is not a prerequisite for revisions that already have visible clouds. B reflects a common misconception: tags are used to identify a cloud's location on a drawing for the reader, but they have no bearing on whether the revision appears in the schedule. The schedule responds to the cloud, not the tag. D is incorrect because clouds placed in model views (like floor plans) absolutely affect sheet schedules when those views are placed on the sheet — only clouds drawn directly on the sheet canvas bypass the viewport relationship, but both types still register. As a study tip, remember this hierarchy: cloud visible in a placed view → revision auto-appears on sheet. Tags and manual selection are supplemental tools, never gatekeepers.

Question 6

A sheet contains one cloud assigned to revision 2 and one cloud assigned to revision 3. Revision 2 is also included manually through Revisions on Sheet. The second cloud was assigned incorrectly and is changed from revision 3 to revision 4.

After the cloud's Revision parameter is changed, which revisions should be listed in the sheet's revision schedule?

  1. Revisions 2 and 3, because cloud reassignment changes its tag but not the schedule association.
  2. Revisions 2, 3, and 4, because changing a cloud preserves its previous revision assignment.
  3. Revision 4 only, because reassignment causes all earlier revisions to be removed from the sheet.
  4. Revisions 2 and 4, because revision 2 remains applicable and the changed cloud now creates revision 4. (correct answer)
Explanation: When working with Revit's revision tracking system, you need to understand the two ways a revision can appear on a sheet's schedule: automatically (through a revision cloud placed on the sheet) and manually (through the "Revisions on Sheet" dialog). These two mechanisms are independent, and that independence is the key to this question. Here's what happens step by step: Revision 2 appears on the schedule for two reasons — a cloud assigned to it AND a manual "Revisions on Sheet" entry. Revision 3 appears only because of its cloud. When that cloud's Revision parameter is changed from 3 to 4, the cloud no longer represents revision 3 — it now represents revision 4. Revision 3 drops off the schedule because its only source (the cloud) is gone. Revision 4 now appears because the reassigned cloud references it. Revision 2 remains because its manual entry in "Revisions on Sheet" is untouched. The result is revisions 2 and 4, making D correct. Choice A is wrong because it assumes the cloud still contributes revision 3 to the schedule after reassignment — it doesn't. The cloud's revision parameter fully controls its schedule contribution. Choice B is wrong because Revit does not preserve a cloud's previous revision assignment; once changed, the old revision is gone unless another source references it. Choice C is wrong because it ignores revision 2's manual entry entirely — "Revisions on Sheet" independently keeps revision 2 active regardless of cloud changes. Remember this rule: a revision stays on a sheet's schedule only if at least one active source — a cloud or a manual entry — still references it.

Question 7

An unissued test revision was created accidentally and assigned to several revision clouds and tags. The BIM manager selects that revision in the Sheet Issues/Revisions dialog and deletes it.

What is the expected effect of deleting the revision?

  1. The revision row is deleted, while its clouds and tags become unassigned annotations.
  2. The revision remains in the project but is automatically changed to an unissued hidden state.
  3. The revision is removed from schedules, while its clouds and tags retain the deleted number.
  4. The revision row, associated clouds, and associated revision tags are deleted from the project. (correct answer)
Explanation: When working with revisions in Revit, it helps to understand that the Sheet Issues/Revisions dialog manages revisions as complete, interconnected units — not just labels. Revisions aren't simply metadata tags floating independently from their associated clouds and tags; they form a parent-child relationship where the revision row is the controlling element. When you delete a revision row in this dialog, Revit treats the deletion as removing the entire revision system — the row itself, every revision cloud assigned to that revision, and every revision tag linked to those clouds. This is exactly what happens in the scenario described, making D the correct answer. Because the revision was unissued and test-only, Revit has no reason to preserve orphaned annotation elements, so everything tied to that revision is purged cleanly from the project. Answer A is a tempting trap because it sounds like a reasonable "safe" behavior — keeping the clouds and tags as unassigned annotations — but Revit doesn't orphan those elements. They are dependent on the revision and are deleted along with it. Answer B confuses deletion with the hidden visibility toggle, which is a separate option in the dialog that hides a revision from schedules and title blocks without removing it. Answer C mixes up behaviors: revision clouds don't retain a deleted number because the number source (the row) no longer exists. As a study tip, remember that in Revit, deleting a revision is a cascading action — always assume associated clouds and tags follow the revision row. If you only want to hide a revision from output, use the hidden state instead of deletion.

Question 8

While sheet A201 is active, a designer draws a revision cloud directly on the sheet around a floor-plan viewport. The floor-plan viewport is later removed from A201 and placed on A202.

Assuming no other changes are made, what happens to the cloud and its revision association?

  1. The cloud moves with the viewport, and the revision transfers automatically to A202.
  2. The cloud remains on A201, and its revision remains associated with A201. (correct answer)
  3. The cloud remains on A201, but the revision transfers automatically to A202.
  4. The cloud is deleted because its host viewport was removed from A201.
Explanation: When working with Revit sheets and revisions, the key principle to understand is where an object lives determines where it belongs. A revision cloud drawn directly on a sheet is a sheet-hosted element — it exists on that sheet's canvas, completely independent of any viewport or model content visible through that viewport. When the designer draws the cloud on A201, Revit anchors it to A201 as a sheet annotation. The cloud's revision tag therefore registers against A201's revision schedule. The viewport below it is simply a window into a view — moving that viewport to A202 relocates the view display, not anything drawn on the sheet itself. The cloud stays exactly where it was drawn, and its revision association remains tied to A201. That makes B the correct answer. A is wrong because revision clouds don't follow viewports. The cloud has no parent-child relationship with the viewport — only with the sheet it was placed on. C shares the same viewport-following misconception, adding the false idea that the revision "transfers" automatically to A202; revisions don't migrate based on viewport movement. D is wrong because the cloud's host is the sheet, not the viewport. Removing a viewport never deletes sheet-level annotations that happen to overlap it visually. A useful study tip: always ask yourself "Was this element placed in a view, or placed on a sheet?" Revision clouds, title blocks, and sheet-level text live on the sheet; dimensions, tags, and detail lines placed inside a viewport live in the view. That distinction controls nearly every hosting and behavior question you'll encounter on this topic.

Question 9

Sheet A301 contains three revision clouds assigned to revision sequence 4: one cloud directly on the sheet and two clouds inside views placed on that sheet. The title block contains a standard revision schedule.

How many schedule rows will these three clouds normally produce for revision sequence 4 on A301?

  1. One row, because the schedule reports each applicable revision rather than each cloud. (correct answer)
  2. Two rows, because sheet clouds and view clouds are reported as separate groups.
  3. Three rows, because every revision cloud creates an independent schedule record.
  4. Four rows, because the revision sequence adds a summary row to the cloud rows.
Explanation: Whenever you see a question about Revit revision schedules, focus on how Revit tracks revisions — it tracks revision sequences, not individual clouds. This distinction is the heart of what's being tested here. In Revit, a title block's revision schedule displays one row per revision sequence that appears on a sheet — regardless of how many clouds belong to that sequence. So if sheet A301 has three clouds all tagged to revision sequence 4 (whether sitting directly on the sheet or inside viewport views), the schedule sees only one revision event: sequence 4. That produces one row for that sequence, making A the correct answer. Choice B is wrong because Revit does not separate "sheet clouds" from "view clouds" when generating schedule rows. Both types contribute equally to the presence of a revision sequence on the sheet, and neither creates a distinct category in the schedule. Choice C reflects a common and understandable misconception — it assumes the schedule is cloud-counting software, but it isn't. Three clouds do not mean three rows; the schedule is revision-aware, not cloud-aware. Choice D invents behavior that doesn't exist in Revit. There is no automatic "summary row" added on top of individual cloud rows; the schedule simply doesn't work that way. A useful way to remember this: think of revision clouds as evidence that a revision exists on a sheet, not as the items being scheduled. The schedule reports the revision itself. When studying for Revit certification, pay close attention to how revision visibility, cloud placement, and schedule population interact — it's a frequently tested workflow.

Question 10

A project revision named "Permit Addendum" must appear in the revision schedule on sheet A101. The sheet contains no revision clouds for this revision because the addendum applies to the entire issued set.

Which workflow adds the revision to A101 without creating a revision cloud?

  1. Open Revisions on Sheet for A101 and select the Permit Addendum revision. (correct answer)
  2. Edit the revision schedule and manually insert a row for Permit Addendum.
  3. Place a revision tag on A101 and assign it to Permit Addendum.
  4. Mark Permit Addendum as issued in the Sheet Issues/Revisions dialog.
Explanation: When a revision needs to appear on a sheet's title block schedule but no clouds exist to trigger it automatically, Revit gives you a manual override through the Revisions on Sheet dialog. This is the concept being tested — understanding that revision visibility on a sheet isn't exclusively cloud-driven. In Revit, open the sheet's properties and click Revisions on Sheet. This dialog lists all project revisions and lets you check individual ones to force them onto that sheet's revision schedule, regardless of whether any clouds are present. Selecting "Permit Addendum" here is exactly the right move — it adds the revision row to A101's schedule without requiring a cloud. Choice B is tempting but wrong — revision schedule rows in Revit are driven by the model data (clouds and the Revisions on Sheet setting). You cannot manually insert arbitrary rows into a revision schedule the way you would a regular drafting table; the schedule is parametric and model-controlled. Choice C describes placing a revision tag, but tags in Revit must be hosted by a revision cloud. Without a cloud, there's nothing to tag, and placing a tag wouldn't add a bare revision row anyway. Choice D — marking a revision as "Issued" in the Sheet Issues/Revisions dialog — controls whether a revision is locked from further editing project-wide. It doesn't add that revision to any particular sheet's schedule. The practical tip here: whenever a question mentions adding a revision to a sheet without a cloud, think Revisions on Sheet in the sheet properties. That dialog is specifically designed for this addendum-style scenario.