- Which workflow adds the revision to A101 without creating a revision cloud?
Answer: Open Revisions on Sheet for A101 and select the Permit Addendum revision.
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.
- What is the appropriate Revit workflow for making these changes?
Answer: Clear the Issued setting, make the required changes, and mark the revision issued again.
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.
- What is the expected effect of deleting the revision?
Answer: The revision row, associated clouds, and associated revision tags are deleted from the project.
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.
- After the cloud's Revision parameter is changed, which revisions should be listed in the sheet's revision schedule?
Answer: Revisions 2 and 4, because revision 2 remains applicable and the changed cloud now creates revision 4.
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.
- What should happen in A401's revision schedule under normal revision-schedule settings?
Answer: Revision 5 appears because the visible cloud associates the revision with A401 even without a tag.
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.
- What should be expected when the affected sheets are displayed or printed?
Answer: The clouds and tags are hidden, but the revision can remain listed in each applicable revision schedule.
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.
- How will the third project revision normally be numbered in the revision schedules on these two sheets?
Answer: It will be revision 2 on both A101 and A102 because each sheet has two revisions.
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.
- How many schedule rows will these three clouds normally produce for revision sequence 4 on A301?
Answer: One row, because the schedule reports each applicable revision rather than each cloud.
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.
- Which workflow most directly implements the change while retaining Revit's automatic revision data?
Answer: Edit the title block family, modify its revision schedule fields, and reload the family.
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.
- Assuming no other changes are made, what happens to the cloud and its revision association?
Answer: The cloud remains on A201, and its revision remains associated with A201.
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.
