All questions
Question 1
An overall floor plan is already placed on a sheet and contains extensive dimensions and tags. A second sheet needs a code-analysis version of the same plan. The new version must initially retain the existing annotations, but its visibility settings, crop, and annotations must later be editable independently.
What should be done before placing the code-analysis plan on the second sheet?
- Create a dependent duplicate of the plan and modify its visibility and annotations after placement.
- Duplicate the plan with detailing, rename the duplicate, and place the duplicate on the second sheet. (correct answer)
- Place the original plan again, then assign a different viewport type and crop boundary.
- Duplicate the sheet containing the plan, then delete the unwanted title block and sheet annotations.
Explanation: Whenever you see a question about reusing views in Revit, focus on two critical needs: independence and annotation retention. Ask yourself — does the new view need to start with existing annotations, and must it later diverge from the original?
Revit offers three duplication methods. A plain Duplicate copies the view geometry but strips all view-specific annotations. A Duplicate as Dependent creates a child view that inherits and stays synchronized with the parent's crop and properties — changes to one affect the other, which eliminates true independence. Duplicate with Detailing copies both the view geometry and all view-specific elements (dimensions, tags, text), while creating a fully independent view. That's exactly what the scenario demands: start with all existing annotations intact, then freely modify visibility settings, crop, and annotations on the new version without affecting the original.
Choice B is correct because duplicating with detailing preserves the annotations from the start, and once renamed, the duplicate can be placed on the second sheet and edited entirely independently.
Choice A is tempting but wrong — a dependent duplicate remains linked to its parent. Any crop or annotation change on the parent cascades to the dependent view, so true independence is never achieved.
Choice C is incorrect because placing the original view on a second sheet is not allowed in Revit — each view can only appear on one sheet at a time.
Choice D is a workflow shortcut, not a view management solution. Duplicating sheets copies sheet-level content, not the view itself, and doesn't create an independent view instance.
Study tip: Memorize the three duplication modes and their annotation/independence behavior — this distinction appears frequently on Revit certification questions.
Question 2
Four floor-plan sheets use the same title block. The plan viewports have different crop sizes, but a particular grid intersection in each plan must appear at the same printed location relative to the title block.
Which workflow most reliably produces the required alignment across the sheets?
- Assign the same guide grid to each sheet and align the matching model grid intersection in every viewport. (correct answer)
- Give every viewport the same viewport type and enter identical center coordinates in the view properties.
- Apply the same scope box to every plan and use Align to constrain each viewport to the title block.
- Use identical crop-region dimensions in every view and center each viewport within the printable sheet area.
Explanation: When you need a specific model element — like a grid intersection — to land at the same printed position across multiple sheets, you need a tool that creates a shared spatial reference between the model and the sheet. That's exactly what guide grids do in Revit.
A guide grid is a sheet-level overlay grid that you assign to individual sheets. When you assign the same guide grid to several sheets and then move each viewport so that the target grid intersection snaps to the same guide grid point, every sheet will print that intersection at an identical location relative to the title block — regardless of how large or small each viewport's crop region is. This is the core mechanism tested here, making A the correct workflow.
Choice B is tempting but flawed: "center coordinates" in viewport properties don't exist as a native Revit parameter for aligning model content to a sheet position. You can set a viewport's sheet location, but that controls where the viewport box sits, not where a specific model point within it lands.
Choice C confuses two separate tools. Scope boxes control which datums (grids, levels) are visible in a view — they don't help position model geometry at a consistent printed location on a sheet. The Align command doesn't constrain viewports to title blocks in a persistent way either.
Choice D fails because identical crop dimensions only work if every plan view spans the exact same model area, which contradicts the premise that crop sizes differ.
Study tip: Whenever a Revit question mentions consistent printed position across sheets with varying viewport sizes, think "guide grid" — it's the only sheet-level alignment tool built specifically for that purpose.
Question 3
A detail view is correctly placed on a sheet, but its viewport title and horizontal title line overlap nearby notes. The view name, scale, crop, and detail content must remain unchanged, and other viewports should continue displaying their titles.
What is the most appropriate correction?
- Select the viewport and assign a viewport type configured without a visible title or title line. (correct answer)
- Activate the detail view and hide the view title category through Visibility/Graphics settings.
- Rename the detail view with a blank value so the viewport label and line are suppressed.
- Delete the viewport title family from the project and reload the detail view onto the sheet.
Explanation: When working with viewport presentation in Revit, it helps to think in terms of viewport types — reusable configurations that control whether a title bar and line appear. This question tests whether you know how to suppress a viewport title non-destructively, without altering the view itself or affecting other viewports.
The cleanest solution is A: select the viewport on the sheet and assign it a viewport type that has the title and title line turned off. Revit allows multiple viewport types within a single project (e.g., "Title w/ Line," "No Title," "Title Only"), so you can apply a "no title" type to just that one viewport while every other viewport retains its own type assignment. The view name, scale, crop region, and detail content stay completely intact — you're only changing how that instance is displayed on the sheet.
B is wrong because using Visibility/Graphics inside the activated view would suppress the title category globally for that view, potentially affecting how it appears in other contexts — and it doesn't elegantly isolate the problem to a single sheet placement. C is a common misconception: renaming the view to a blank value changes the actual view name in the project browser and affects any other references to that view (schedules, callout labels, etc.), which violates the constraint that the view name must remain unchanged. D is far too destructive — deleting the viewport title family would break title display across the entire project, not just one viewport.
A useful rule of thumb: when a problem is instance-specific (one viewport on one sheet), the solution should also be instance-specific — and viewport types give you exactly that control.
Question 4
A viewport is correctly configured but must move slightly on its sheet to clear a revision schedule. Attempts to move it fail, and its selection indicates that the viewport is pinned. No model geometry or annotations inside the view should change.
Which sequence should the user follow?
- Activate the view, unpin all visible model elements, and move the crop region within the model view.
- Select the viewport on the sheet, unpin the viewport, and use Move to reposition it. (correct answer)
- Select the title block, unpin the sheet, and move the entire sheet composition around the viewport.
- Duplicate the placed view, delete the pinned viewport, and place the duplicate at the new location.
Explanation: Whenever you see a question about sheet composition in Revit, it helps to distinguish between the sheet environment and the view environment. A viewport is a container placed on a sheet — it can be selected, moved, and pinned independently of the view content it displays. Pinning a viewport locks its position on the sheet to prevent accidental displacement, which is exactly what happened here.
The solution in B is correct because it targets the problem directly: the viewport is pinned, so you simply unpin it (via the pushpin icon in the ribbon or right-click menu), then use the Move command to reposition it on the sheet. Since you're operating in the sheet environment — not inside the activated view — no model geometry or annotations are touched.
A is wrong because activating the view takes you inside the model environment. Moving the crop region shifts what portion of the model is visible, which changes the view content — exactly what the scenario says to avoid. It also doesn't address the pinned viewport at all.
C confuses the hierarchy. You can't move the entire sheet composition "around" a fixed viewport by selecting the title block. Title blocks don't control viewport positions, and this approach would misalign every other element on the sheet.
D is a destructive workaround that wastes time. Duplicating the view, deleting the viewport, and re-placing creates unnecessary view instances and risks losing view-specific settings. The pin feature exists precisely so you don't need this.
As a study habit, remember: pin = position lock on the sheet. Unpin first, then move — don't rebuild what you can simply unlock.
Question 5
A project manager created placeholder sheets in a sheet list for several future drawing packages. One placeholder already has the required sheet number and sheet name. The sheet must now become an actual sheet with the office title block while retaining that placeholder information.
Which workflow should be used to create the actual sheet?
- Open the New Sheet dialog, select the existing placeholder sheet, and assign the required title block. (correct answer)
- Create a standard sheet with the title block, then enter the placeholder's existing sheet number and name.
- Duplicate the sheet list, convert the duplicated schedule row to a sheet, and load the required title block.
- Place the title block in a drafting view, then rename that view with the placeholder's number and name.
Explanation: When working with placeholder sheets in Revit, the key concept to understand is that placeholders are intentional "reservations" in a sheet list — they hold numbering and naming information before the actual drawing sheet exists. The workflow question here tests whether you know how Revit bridges that gap without losing the data already entered.
The correct approach is A: when you open the New Sheet dialog, Revit gives you the option to select an existing placeholder sheet rather than creating a brand-new one. By choosing that placeholder, Revit converts it into a full sheet and prompts you to assign a title block — all while preserving the sheet number and name already stored in the placeholder. This is the purpose-built workflow Revit provides for exactly this situation.
B is tempting but creates a separate, unlinked sheet. Manually retyping the sheet number risks duplication errors and doesn't actually "convert" the placeholder — the original placeholder remains in the schedule as an orphan. C describes a process that doesn't exist in Revit; you cannot convert a schedule row by duplicating the sheet list, and that workflow would never produce a real sheet with a title block. D confuses drafting views with sheets entirely — drafting views are for 2D detail content, not sheet layouts, and renaming one wouldn't create a sheet or attach a title block.
As a study tip, remember that in Revit, placeholder sheets exist specifically to be promoted to real sheets through the New Sheet dialog. Any time an exam question asks about converting or activating a placeholder, look for the answer that uses that same dialog rather than manual workarounds.
Question 6
A section view was accidentally placed on the wrong sheet. Its crop, annotations, and visibility settings are correct, so the view must be preserved exactly and placed on the intended sheet instead.
Which action accomplishes this with the fewest changes?
- Cut the viewport to the Clipboard, open the intended sheet, and use Paste Aligned to Same Place.
- Delete the section view from the Project Browser, recreate it, and place the replacement on the intended sheet.
- Duplicate the section with detailing, place the duplicate on the correct sheet, and hide the original viewport.
- Delete the viewport from the wrong sheet, then place the existing section view on the intended sheet. (correct answer)
Explanation: Whenever you see a Revit question about moving a view between sheets, the key distinction to understand is that views and viewports are separate things. A view lives in the Project Browser and holds all your settings — crop region, annotations, visibility overrides. A viewport is simply the container that displays a view on a sheet. Removing a viewport from a sheet does not delete the underlying view.
That's exactly why D is correct. Deleting the viewport from the wrong sheet removes only that container, leaving the section view — with all its crop, annotation, and visibility settings intact — in the Project Browser. You then drag or place that same view onto the intended sheet. Nothing about the view changes; you've simply relocated its display. Fewest steps, zero data loss.
A is tempting but flawed. "Cut and Paste Aligned to Same Place" is a valid technique for moving viewports, but it requires both sheets to be open simultaneously and works best for keeping a viewport's exact position on the sheet — not the primary concern here. It also introduces unnecessary clipboard dependency when the simpler approach is available.
B is the worst option. Deleting the view from the Project Browser destroys it entirely, forcing you to recreate all crop regions, annotations, and visibility settings from scratch — the exact problem the question tells you to avoid.
C creates unnecessary redundancy. Duplicating with detailing copies annotations but produces a second, separate view that must be managed going forward, and hiding the original is a workaround, not a solution.
Study tip: In Revit, always ask yourself whether you're acting on a view or a viewport — that distinction resolves most sheet-management questions quickly.
Question 7
A sheet must be created immediately so that views can be organized and numbered, but the client has not yet approved the title-block size. The project may later use a title block that has not yet been loaded.
Which workflow avoids committing the sheet to a temporary title-block family?
- Create the sheet with any available title block, then change the title block's family category after approval.
- Create a drafting view as a temporary sheet, then convert that drafting view after the title block is approved.
- Create a placeholder sheet, place views on it, then convert it to an actual sheet after the title block is approved.
- Create the sheet using None for the title block, place views on it, and load the approved title block later. (correct answer)
Explanation: When Revit sheet workflow questions involve an unresolved title block, the key concept to focus on is how Revit handles the None title-block option — a built-in placeholder that lets you create a fully functional sheet without committing to any specific family.
Revit allows you to create a sheet and select None as the title block during setup. The sheet exists in the project browser, can be named and numbered, and views can be placed on it just like any other sheet. When the approved title block is later loaded into the project, you simply edit the sheet and swap in the correct family — no data is lost, no views need to be reassigned. This makes option D the correct workflow.
Option A is wrong because you cannot change a title block's family category — that's not an editable property in Revit. Swapping a title block family is possible, but reframing it as changing the "category" reflects a fundamental misunderstanding of how family types work. Option B is wrong because drafting views are used for 2D detail work and cannot be "converted" into sheets — Revit has no such conversion tool. This is a tempting distractor if you're thinking loosely about workarounds, but it doesn't reflect any actual Revit feature. Option C is similarly fictitious; Revit has no "placeholder sheet" object type that later converts into a real sheet.
A good study tip: when exam questions describe a Revit problem involving missing or pending content, look for answers that use None or a blank/placeholder option that Revit natively supports — these are almost always the intended workflow.
Question 8
While editing a new sheet, a user selects Place View but cannot find the required floor plan in the list. The plan still exists in the Project Browser and is not a template.
What is the most likely reason the floor plan does not appear in the Place View list?
- The plan is filtered out by the current Project Browser organization settings.
- The plan is already placed on another sheet and cannot be placed a second time as-is. (correct answer)
- The plan uses a title block that is incompatible with the current sheet's title block family.
- The plan's crop region is disabled, preventing it from appearing in the placement list.
Explanation: When working with sheets and views in Revit, it's important to understand a core rule: each view can only be placed on one sheet at a time. The Place View dialog filters out views that are already hosted on a sheet, because Revit treats each view as a unique instance — placing it twice would create conflicting sheet references and break the automatic sheet number callouts that appear in section markers, callout bubbles, and elevation tags.
This is exactly why B is correct. If a floor plan doesn't appear in the Place View list despite existing in the Project Browser, the most likely culprit is that it's already placed on another sheet. You can confirm this by right-clicking the view in the Project Browser — if it's placed, you'll see an "Open Sheet" option.
As for the distractors: A is incorrect because Project Browser organization settings affect how views are displayed and grouped in the browser, not whether they appear in the Place View dialog. C is a fabricated constraint — Revit does not check title block compatibility when listing available views for placement. Any view can be placed on any sheet regardless of title block family. D is also incorrect; a disabled crop region affects how the view looks on a sheet (it shows without a cropped boundary), but it has no bearing on whether the view appears in the placement list.
A useful tip: whenever a view seems "missing" from Place View, your first instinct should be to search the Project Browser for a sheet icon nested beneath that view — that's Revit's visual indicator that the view is already placed somewhere.
Question 9
A general-notes legend has been created and placed on the first architectural sheet. The identical legend must appear on twelve additional sheets, and all thirteen instances must reflect future edits made to the legend.
Which approach meets the requirement with the least maintenance?
- Duplicate the legend with detailing for each sheet and place one duplicate on every remaining sheet.
- Copy the legend's annotation elements into separate drafting views and place one view on each sheet.
- Place the same legend view on each additional sheet and position each resulting viewport as required. (correct answer)
- Duplicate the first sheet twelve times and replace its other viewports with the required project views.
Explanation: When working with legends in Revit, the critical concept to understand is that legends behave differently from almost every other view type — they are the only views that can be placed on multiple sheets simultaneously. This makes them uniquely powerful for repeated general notes, symbols, or schedules that must stay synchronized across a project.
Because a single legend view can live on multiple sheets at once, any edit you make to that legend — adding a note, changing text, reordering items — instantly updates every sheet where that viewport appears. This is exactly what the scenario demands: thirteen identical, always-synchronized instances. Option C leverages this native Revit behavior by placing the same legend view on each additional sheet, requiring zero duplication and zero ongoing maintenance.
Option A is wrong because duplicating a legend with detailing creates independent copies. Each duplicate becomes its own view, so edits to one do not propagate to the others — you'd have to manually update all thirteen instances, which is precisely the maintenance burden the question asks you to avoid.
Option B has the same fundamental flaw as A. Drafting views are independent; copying annotation elements into separate drafting views means thirteen disconnected views that diverge the moment any edit is made.
Option D is a project-management disaster. Duplicating the sheet multiplies everything on it, forcing you to swap out unrelated viewports and manage sheet numbers — it creates far more work, not less.
The study tip here: whenever a Revit question mentions content that must appear identically on multiple sheets, think "legend" first. It's Revit's built-in solution for exactly that workflow.
Question 10
A plan viewport extends beyond the usable sheet area because the view includes unnecessary model extents on one side. The required printed scale must remain unchanged, and the model elements themselves must not be moved.
What should the user do to make the viewport fit?
- Reduce the view scale until the viewport boundary fits inside the usable sheet area.
- Resize the viewport boundary by dragging its sheet handles while keeping the view inactive.
- Edit the view's crop region to exclude the unnecessary extents, then reposition the viewport if needed. (correct answer)
- Move the model elements toward the viewport center, then restore their dimensions after printing.
Explanation: When a viewport extends beyond the sheet boundary in Revit, the question is really asking how you control what portion of the model is visible without violating the two constraints given: the scale must stay fixed, and model elements must not move. This is exactly what the crop region is designed for.
The crop region is a masking boundary attached to the view itself — not the sheet. By activating the view and dragging or reshaping its crop boundary, you trim the visible extents of the model without touching the model geometry or changing the view scale. Once cropped, the viewport naturally becomes smaller on the sheet, and you can reposition it to fit cleanly within the usable area. This makes C the correct approach.
A is tempting but violates the stated constraint that the printed scale must remain unchanged. Reducing the scale would shrink the viewport, but it changes how the drawing communicates dimensions and detail — a critical error in construction documents.
B describes dragging the viewport's sheet handles while the view is inactive. Doing this only moves or stretches the viewport frame on the sheet; it does not crop the view content. The model view inside remains unchanged, so overflowing content is simply clipped visually without truly being removed from the view.
D directly violates the other constraint — model elements must not be moved. Moving geometry to fit a sheet is never an acceptable documentation practice, and restoring dimensions afterward introduces risk of error.
As a study tip: in Revit, always distinguish between view properties (crop region, scale, visibility) and sheet properties (viewport position, title block). Questions about fitting viewports almost always live in the view layer, not the sheet layer.