All questions
Question 1
A project contains twelve sheets with two different title-block sizes. The client requires one PDF containing all twelve sheets in a specified order, while each page must retain the size associated with its title block.
Which export workflow best satisfies the client's requirements?
- Select the twelve sheets, enable automatic sheet-size detection, arrange the export order, and combine the selections into one PDF. (correct answer)
- Select the twelve sheets, choose one common paper size, arrange the export order, and create a separate PDF for each sheet.
- Open the first sheet, export the current window at fit-to-page, and append the remaining sheets through the PDF viewer.
- Select the twelve sheets, choose the largest paper size, use 100% zoom, and combine the selections into one PDF.
Explanation: When exporting sheets to PDF in Revit, the core challenge is preserving individual sheet sizes while still producing a single, correctly ordered file. This question tests whether you understand Revit's built-in PDF export controls, particularly the sheet-size detection feature.
Revit's PDF export dialog lets you select multiple sheets at once, define their output order, and — critically — enable automatic sheet-size detection, which reads each sheet's title block and assigns the correct paper size per page. This means a mix of A1 and A3 sheets, for example, will each export at their native size within one combined PDF. That's exactly what option A describes, making it the correct workflow.
Option B fails on two counts: choosing a single common paper size would force all sheets to the same dimensions, losing the size distinction the client requires, and creating separate PDFs per sheet contradicts the requirement for one combined file. Option C sidesteps Revit's export tools entirely and relies on manual appending in a PDF viewer — this introduces risk of ordering errors, inconsistent settings, and lost productivity, and "fit-to-page" from the current window view is not a reliable way to control output dimensions. Option D gets the "one PDF" part right but choosing the largest paper size uniformly would scale or crop smaller sheets incorrectly, violating the requirement that each page retains its own title-block size.
As a study tip, remember that Revit's multi-sheet PDF export is more powerful than many candidates realize — automatic sheet-size detection is the key feature that makes mixed-format, single-PDF output possible. When a question involves varied title-block sizes, that feature should immediately come to mind.
Question 2
A sheet's title block is designed for a particular paper size. During PDF review, the title block is centered but slightly reduced, and a measured dimension on the PDF is not at the sheet's intended printed scale.
Which pair of PDF export settings should be checked first?
- Verify the detected paper size and use 100% zoom rather than fitting the sheet to the page. (correct answer)
- Verify the detected paper size and use fit-to-page so the title block remains inside the margins.
- Select a larger paper size and use 100% zoom so every title-block line remains visible.
- Select a smaller paper size and use fit-to-page so the sheet is centered during export.
Explanation: When troubleshooting PDF export scale issues in Revit, you need to think about two independent settings working together: the paper size the exporter detects and the zoom/scaling method applied during export. A title block that appears centered but slightly reduced is a classic symptom of Revit's PDF exporter not matching the virtual paper size to the sheet's designed paper size, combined with a "fit-to-page" behavior that shrinks the content to avoid clipping.
Answer A is correct because it addresses both root causes simultaneously. First, confirming the detected paper size ensures the export driver recognizes the correct sheet dimensions (e.g., ANSI D 24×36"). Second, using 100% zoom — rather than fit-to-page — guarantees the content is exported at true 1:1 scale, preserving all printed dimensions. When both settings align with the sheet's intended size, dimensions on the PDF will match the title block's design scale.
Answer B is tempting but wrong: fit-to-page is precisely what causes the scaling problem. Even if the paper size is correct, fit-to-page will still shrink or stretch content to fill the page, corrupting measured dimensions.
Answer C is incorrect because selecting a larger paper size when the sheet is already correct introduces unnecessary distortion and does not fix the scale issue — it compounds it.
Answer D fails on both counts: a smaller paper size would further mismatch the sheet geometry, and fit-to-page would again rescale the content rather than preserve it.
As a study tip, remember: paper size + 100% zoom = true scale. Any time a Revit PDF question mentions dimensions not matching, check those two settings first.
Question 3
A team exports selected sheets as separate PDF files. The recipient requires filenames such as A101 - FLOOR PLAN.pdf and A201 - BUILDING ELEVATIONS.pdf. Sheet numbers and sheet names may change before later issues.
What is the most reliable way to produce and maintain the required filenames?
- Define a PDF naming rule using the Sheet Number and Sheet Name parameters separated by a hyphen. (correct answer)
- Rename each exported PDF manually after every issue so the names match the current sheet list.
- Rename each Revit sheet view to the complete required filename before running every PDF export.
- Define a PDF naming rule using the View Type and project filename separated by a hyphen.
Explanation: When exporting PDFs in Revit, understanding the difference between automated naming rules and manual workarounds is essential. Ask yourself: does this solution scale reliably when sheet data changes?
Revit's PDF export dialog lets you define a naming rule by combining built-in parameters — like Sheet Number and Sheet Name — with separators. When you configure this rule using those two parameters joined by a hyphen, Revit automatically constructs filenames like A101 - FLOOR PLAN.pdf directly from the sheet's metadata. If a sheet number or name changes in the model, the next export automatically reflects the updated filename — no manual intervention required. That's why A is correct: it ties the filename to the live model data, making it both accurate and maintainable.
B fails because manually renaming files after every issue is error-prone and time-consuming. Human error is almost guaranteed across multiple sheets and multiple issues, and it doesn't scale on large projects.
C is particularly misleading — renaming the Revit view to the full filename would corrupt your sheet organization. View names serve navigation and scheduling purposes inside the model; overloading them with filename strings creates confusion and breaks standard naming conventions.
D uses the wrong parameters entirely. "View Type" produces generic labels like "Floor Plan" or "Elevation," and the project filename has nothing to do with individual sheet identity. The resulting filenames would be identical across all sheets of the same type — completely unusable.
The study takeaway: on Revit export questions, always favor solutions that leverage model parameters over manual steps. Automation tied to live data is always more reliable than post-export workarounds.
Question 4
A presentation sheet contains a hidden-line floor plan and a shaded perspective with shadows. The floor plan should remain as crisp and searchable as possible in the PDF, but the perspective must retain its visual effects.
Which approach provides the best balance of PDF quality and fidelity?
- Permit vector processing where supported and allow the perspective requiring visual effects to be raster processed. (correct answer)
- Force raster processing for the entire sheet at maximum resolution so both viewports use identical processing.
- Remove the perspective's shadows so every viewport can always be exported using vector processing only.
- Convert both viewports to raster images before export so their displayed appearance cannot change.
Explanation: When exporting Revit sheets to PDF, you need to understand that Revit offers two processing modes: vector and raster. Vector processing preserves crisp lines, searchable text, and small file sizes — ideal for technical drawings like floor plans. Raster processing converts the view to pixels, which is required for views containing visual effects like shadows, transparency, and ambient occlusion that cannot be mathematically described as vectors.
The key insight is that Revit can apply these modes per viewport on a single sheet. This means you don't have to compromise the entire sheet just because one viewport has complex visual effects. Answer A is correct because it leverages this flexibility: the hidden-line floor plan exports as sharp, scalable vector geometry while the shaded perspective with shadows is raster processed to preserve its visual fidelity — exactly the right tool for each job.
Answer B forces raster processing on everything, which unnecessarily degrades the floor plan with pixelation and inflates file size. The floor plan has no visual effects requiring raster treatment, so this is an unacceptable tradeoff. Answer C removes the shadows to enable pure vector export everywhere, but this defeats the entire purpose of having a rendered perspective on the sheet — you're solving the technical problem by eliminating the design intent. Answer D pre-converts both viewports to raster images before export, which is redundant, inflexible, and permanently degrades the floor plan with no benefit.
As a study tip: on Revit export questions, always ask yourself what does each viewport actually need? Mixed-content sheets almost always call for per-viewport settings rather than a one-size-fits-all approach.
Question 5
A civil consultant has supplied a site base using an established coordinate system. The Revit project's shared coordinates have been acquired and verified. The consultant will insert the exported DWG at its coordinate origin and will not manually move or rotate it.
Which DWG export coordinate basis should be used?
- Use the title-block origin so the exported geometry aligns according to the published sheet location.
- Use the project internal origin so the exported geometry aligns with the consultant without transformation.
- Use the current view's crop-region corner so the exported geometry has smaller coordinate values.
- Use shared coordinates so the exported geometry aligns with the consultant's established coordinate system. (correct answer)
Explanation: Whenever you see a question about exporting DWGs from Revit for coordination with external consultants, focus on how coordinate systems align between software environments. The central issue is: when the consultant inserts your DWG at coordinate origin (0,0,0) without moving it, your geometry must already be positioned correctly in that shared real-world coordinate space before export.
Shared coordinates in Revit represent the real-world coordinate system established through the survey point — the same system your civil consultant used to build their site base. Choosing shared coordinates (D) as the export basis means the DWG geometry is written out using those real-world values, so when the consultant places it at their origin, everything lands exactly where it belongs on their site plan. No manual repositioning required, no transformation errors introduced.
A is wrong because the title-block origin relates to sheet layout and plotting — it has no meaningful relationship to real-world geographic or project coordinates. Exporting from this basis would produce geometry floating at arbitrary, meaningless values relative to the consultant's file.
B is wrong because Revit's internal origin is the project's own local reference point, which almost never coincides with the shared/survey coordinate system. Geometry exported from the internal origin would be offset or rotated relative to the consultant's coordinate space, requiring them to manually reposition it — exactly what the question says they will not do.
C is wrong because crop-region corners are view-specific display tools, not legitimate coordinate bases for export. Using them would produce unpredictable geometry placement.
Study tip: Anytime a question mentions a consultant inserting a DWG "at origin without moving it," that's your signal that shared coordinates must be used — it's the only export option that maps to the real-world coordinate system both parties share.
Question 6
A CAD consultant uses an AutoCAD Color Index-based plotting standard. Exported Revit line colors must map to indexed CAD colors so the consultant's existing color-dependent plot style behaves predictably.
Which color export option should be selected in the DWG/DXF export setup?
- Black and white, so all exported objects are converted to monochrome, removing the category color distinctions required by the plot standard.
- True color, so exported objects retain exact RGB values independent of indexed plot styles.
- Index color, so exported colors are represented using the AutoCAD indexed color palette. (correct answer)
- Colors specified in the view, so exported objects carry their displayed view colors, which may not correspond to the consultant's required indexed palette values.
Explanation: When exporting Revit files to DWG/DXF format for a consultant using color-dependent plot styles, the critical concept is understanding how AutoCAD interprets color to drive plotting behavior. Color-dependent plot styles (CTB files) assign pen weights, linetypes, and other plot properties based on an object's AutoCAD Color Index (ACI) number — not its RGB value. This means the exported colors must map to specific indexed values (1–255) for the consultant's CTB file to behave predictably.
Selecting Index color (C) ensures that Revit's exported object colors are translated into the nearest matching ACI color. The consultant's plot style table can then recognize those indexed colors and apply the correct pen assignments, maintaining the intended plotting standard.
A is wrong because converting everything to black and white strips out all color distinctions entirely, which defeats the purpose of a color-dependent plot standard that relies on different colors triggering different plot behaviors. B is a common trap — true color exports retain exact RGB values, but CTB-based plot styles cannot map arbitrary RGB colors to pen settings; they only respond to ACI index numbers. D is similarly flawed: exporting "colors specified in the view" passes through Revit's display colors, which are RGB-based and may not correspond to any ACI value the consultant's CTB file recognizes.
As a study tip, remember the distinction: true color = RGB (exact but unindexed), index color = ACI palette (required for CTB compatibility). On Revit export questions involving CAD interoperability, always ask yourself what color system the receiving workflow depends on.
Question 7
A fabrication consultant requests a DWG of a Revit 3D view. The consultant wants supported building components to arrive as CAD solid geometry that can be used for solid operations, rather than as collections of triangulated faces.
Which solids export setting is most appropriate?
- Export all geometry as polymeshes, because triangulated mesh faces can be directly used for solid Boolean operations in CAD applications.
- Export supported geometry as ACIS solids rather than selecting the polymesh representation. (correct answer)
- Set the export to vector processing, because vector output automatically converts eligible geometry to editable ACIS solids in the DWG file.
- Export the 3D view as separate surface bodies, because individual surface patches are equivalent to ACIS solids for fabrication operations.
Explanation: When exporting a Revit 3D view to DWG for fabrication use, the critical distinction is between polymesh geometry and ACIS solids. Polymeshes represent curved and complex surfaces as collections of triangulated faces — lightweight for visualization, but unsuitable for Boolean operations like cutting, unioning, or subtracting geometry in CAD applications. ACIS solids, by contrast, are true parametric solid bodies that CAD tools can manipulate mathematically.
This is exactly why B is correct. Revit's DWG export settings include an option to export supported geometry as ACIS solids instead of polymeshes. When a fabrication consultant needs to perform solid operations, choosing the ACIS solid export ensures the resulting DWG contains geometry that CAD applications can recognize and operate on as true solids — not just visual approximations made of triangles.
A is the most tempting distractor, but it contains a fundamental misconception: triangulated polymesh faces cannot be directly used for solid Boolean operations. They are mesh representations, not solid bodies, and most CAD applications treat them as surfaces or display geometry only. C is incorrect because vector processing controls how Revit processes 2D linework and hidden lines — it has no bearing on whether 3D geometry exports as solids or meshes. D is wrong because surface patches (individual surface bodies) are open shells, not closed solids; they are geometrically incompatible with solid Boolean workflows and are not equivalent to ACIS solids.
As a study tip: whenever a Revit export question mentions fabrication or solid operations, immediately focus on the ACIS solids option — it's the only export format that preserves true solid geometry in DWG.
Question 8
A consultant's CAD standard requires Revit Walls to export to A-WALL, wall finish subcategories to A-WALL-FNSH, and door tags to A-ANNO-TAGS. The project must retain its existing Revit category and subcategory organization.
Where should these destination layer assignments be configured?
- In the sheet properties by assigning one destination CAD layer to each viewport placed on the sheet.
- In Object Styles by renaming the Revit categories and subcategories to match the required CAD layers.
- In Visibility/Graphics by applying view filters whose names match the required destination CAD layers.
- In the Layers tab of the DWG/DXF export setup by mapping categories and subcategories to CAD layers. (correct answer)
Explanation: When you need to export a Revit model to DWG/DXF format while controlling exactly which CAD layer each Revit category lands on, you're working inside Revit's Export Setup — a dedicated configuration tool that acts as a translation table between Revit's category system and CAD layer names.
The correct place to define these mappings is D — the Layers tab of the DWG/DXF Export Setup. Here, Revit lists every category and subcategory (Walls, Wall subcategories like finishes, Door Tags, etc.), and you explicitly assign each one a destination layer name such as A-WALL, A-WALL-FNSH, or A-ANNO-TAGS. This satisfies the consultant's CAD standard without touching anything in the Revit project itself.
The other options each confuse a different Revit feature with export control. A is wrong because sheet properties and viewports govern how views are arranged for printing — they have no layer-mapping functionality. B is wrong because Object Styles control how categories display inside Revit (line weight, color, pattern); renaming categories there would corrupt the project's internal organization, which the scenario explicitly prohibits. C is wrong because Visibility/Graphics and view filters control visibility of elements in a view — they don't translate to CAD layer names during export, and filter names are not recognized as layer assignments.
A useful study tip: whenever a Revit question involves DWG/DXF output, mentally separate what happens inside Revit (Object Styles, Visibility/Graphics) from what happens at the export boundary (Export Setup). Layer mapping always lives at that boundary — in the Export Setup dialog, Layers tab.
Question 9
A sheet containing three placed model views and one linked Revit model is exported to DWG. The CAD recipient wants the sheet drawing to reference separately generated files for the placed views and linked model, allowing those files to be reloaded independently.
Which export setting should be enabled?
- Merge layer modifiers so the sheet DWG stores each viewport and model link in an independent layer group.
- Preserve coincident lines so each placed view and linked model becomes a separately reloadable CAD file.
- Export views on sheets and links as external references so the sheet DWG references separate exported files. (correct answer)
- Export rooms and areas as polylines so the sheet DWG references the model views through closed boundaries.
Explanation: When exporting Revit sheets to DWG, you need to understand how Revit handles the relationship between the sheet file and its component views. By default, Revit can embed view geometry directly into the sheet DWG — but that prevents CAD users from reloading individual views independently. The key concept here is external references (XREFs), a standard CAD workflow where a master drawing file links to separate child files that can be updated without modifying the parent.
Enabling "Export views on sheets and links as external references" (answer C) tells Revit to export each placed view and linked Revit model as its own separate DWG file, then attach those files to the sheet DWG as XREFs. This is exactly what the CAD recipient needs — the ability to reload each view or linked model file independently.
Answer A describes "merge layer modifiers," which is a layer-naming setting that controls how Revit's layer modifiers are combined into DWG layer names. It has nothing to do with creating separately reloadable files. Answer B, "preserve coincident lines," is an export option that controls whether overlapping identical lines are kept or removed — it has no bearing on file referencing structure. Answer D, exporting "rooms and areas as polylines," is a setting that converts Revit room/area boundaries into CAD polylines for annotation or analysis purposes — completely unrelated to how views are referenced.
When you see exam questions about DWG export and file organization, look for XREF-related language. If the goal is independent reloading of components, the answer will always point to external references — that's the standard CAD mechanism for modular file management.
Question 10
A recipient requires DXF files compatible with AutoCAD 2013. The same layer mappings, units, coordinates, and file-version requirement will be used for monthly exports, while another consultant still needs the firm's current DWG settings.
Which workflow best avoids changing the other consultant's export configuration?
- Modify the existing current-version setup before each DXF export, then manually restore every setting afterward.
- Duplicate and name a DWG/DXF export setup, set its target version and other mappings, then use it for DXF exports. (correct answer)
- Export using the current DXF version and rename the file extension so AutoCAD 2013 recognizes the file.
- Export a PDF first and convert it to DXF so the existing DWG export setup remains unchanged.
Explanation: When working with Revit's DWG/DXF export system, the key concept being tested is named export setups — reusable configurations that store layer mappings, units, coordinates, file versions, and other settings independently of one another. Whenever a question describes recurring exports with specific requirements that must coexist alongside other configurations, think: create a separate named setup.
Option B is correct because Revit allows you to duplicate an existing export setup, give it a meaningful name (like "DXF-AutoCAD2013-Monthly"), and configure it independently — setting the file version to AutoCAD 2013, adjusting layer mappings, units, and coordinates as needed. Each subsequent monthly export simply recalls this saved setup, leaving every other configuration untouched.
Option A is a workflow antipattern: manually modifying a shared setup before each export creates risk. Human error during restoration can corrupt settings your colleague depends on, and it adds unnecessary repetitive labor. Option C misrepresents how file compatibility works — simply renaming a file extension doesn't alter the internal format version. A newer DXF written internally to a 2018 format will not behave like a 2013 file just because you rename it; AutoCAD reads the embedded version header, not the file extension label. Option D introduces an unnecessary and lossy conversion pipeline. PDF-to-DXF conversion degrades geometry, loses layers, and is entirely the wrong tool for this problem.
The study takeaway: on Revit export questions, named/duplicate setups are almost always the correct solution when the scenario involves multiple recipients, recurring exports, or conflicting format requirements. Look for that pattern — it appears frequently.