- What should the designer do after opening the source file?
Answer: Use Save As to create a new RVT in a writable location, then continue work in that copy.
When working with read-only files in Revit, the key concept being tested is how to create an independent working copy without modifying a protected source. Think of this as a "branching" workflow — you want your own editable version while leaving the original untouched.
Save As is Revit's purpose-built tool for exactly this scenario. After opening the read-only source file, you use File > Save As > Project to write a new RVT to a location where you have write permissions. From that point forward, you work entirely in your copy, and the protected source file is never modified. Option A describes this correctly and completely.
Option B reflects a fundamental misunderstanding — Revit cannot and will not override file system permissions through repeated saving. If a folder is protected by the OS or network administrator, no amount of Save attempts will strip that read-only status. This is controlled at the system level, not the application level.
Option C is simply not possible. The Open dialog in Revit does not let you rename files on the file system; that would require Windows Explorer or similar tools. Even if you could rename it, you'd still be working in the same protected location.
Option D misuses the Save As > Template function. RTE template files are starting points for new projects (setting up families, settings, and standards), not containers for active modeling work. Continuing to model directly in a template file creates workflow and file-type problems down the line.
Remember this pattern: whenever a Revit question involves creating an independent copy of an existing project, Save As > Project to a writable location is always the correct workflow.
- Which result should the project team expect from this setting?
Answer: Revit retains up to three numbered backup versions in addition to the current project file.
When working with non-workshared Revit projects, it's important to understand how the Save As Options dialog controls file backup behavior — specifically what "Maximum backups" actually governs.
The Maximum backups setting controls how many numbered backup files Revit retains alongside your current project file. Each time you save, Revit creates a sequentially numbered backup (e.g., ProjectName.0001.rvt, ProjectName.0002.rvt). With a limit of 3, Revit keeps the three most recent backups and automatically purges older ones. The current .rvt file remains separate and is never counted among the backups. This is exactly what answer A describes — and it's the correct answer.
Answer B confuses "Maximum backups" with an auto-save interval. Revit does not have a native auto-save feature that triggers on a timed schedule; the backup setting has nothing to do with minutes or automatic saves.
Answer C describes an impossible behavior. Revit backup files are always stored as separate files in the same directory as the project — they are never embedded or nested inside the current RVT file itself. Each backup is a full standalone copy.
Answer D misrepresents how the purging logic works. Revit doesn't selectively retain only the third file and delete everything around it. Instead, it retains the most recent three backups in sequence, discarding only the oldest ones as new saves push the count above the limit.
A useful study tip: on Revit exam questions, always distinguish between workshared and non-workshared backup behavior — the mechanisms differ, and exam writers frequently use that distinction as a distractor.
- What is the appropriate first step for turning this file into a reusable Revit project template?
Answer: Remove unwanted project-specific content, then use Save As > Template to create an RTE file.
When turning an existing project file into a reusable firm standard, you need to think about two separate concerns: cleaning the content and saving in the correct format. Both steps matter, and skipping either one creates problems.
The right approach, captured in C, is to first strip out project-specific model elements — walls, rooms, schedules tied to a particular job — so they don't pollute every future project. Then you use File > Save As > Template, which saves the file with the .rte extension and signals to Revit that this file is a template, not an active project. This preserves your view templates, title blocks, object styles, and project settings while giving you a clean starting point.
A is tempting but wrong in two ways: Save As > Project keeps the .rvt extension, so the file behaves as a project, not a template. More critically, it tells you to retain the existing project data — exactly the content you want to remove before standardizing.
B is a dead end. Exporting to IFC and reimporting is a geometry-translation workflow used for interoperability with other software. It does not preserve Revit-native settings like view templates or object styles, and it produces no usable template.
D describes a common misconception — that a file extension rename is all it takes. Revit file types are not interchangeable; the internal file structure differs between .rvt and .rte. Simply renaming the extension produces a corrupt or unrecognized file.
A good study tip: on Revit exam questions about templates, always check whether the answer addresses both content cleanup and the correct Save As method — questions often isolate one or the other to create plausible distractors.
- Which sequence most directly addresses both objectives?
Answer: Open the RVT with Audit selected, then use Save As with Compact File selected.
When troubleshooting bloated or corrupted Revit files, you need two distinct tools working together: a diagnostic check during opening, and a file reorganization during saving. Revit provides dedicated options for both, and recognizing them is exactly what this question tests.
The Audit option, available in the Open dialog, instructs Revit to scan the model's internal database for inconsistencies and errors as it loads — it's your diagnostic pass. Once the file is open and checked, Save As with Compact File enabled rewrites the file structure from scratch, eliminating fragmentation and dead data that accumulate over time. Together, these two steps directly match both objectives: checking during opening and producing a clean, reorganized separate copy. That makes A the correct answer.
B is a trap because opening as read-only prevents you from making any meaningful repairs, and limiting backups to one has nothing to do with file integrity or compaction — it just controls backup count.
C misunderstands the Save As > Template workflow. Saving as an RTE (template) and renaming it doesn't invoke any file reorganization or compaction; it just changes the file type label and strips project-specific data.
D introduces an IFC round-trip, which is a destructive, lossy process. IFC translation strips Revit-native data, family parameters, and element IDs — it's not a repair tool and creates far bigger problems than it solves.
A useful study tip: on Revit exam questions about file maintenance, always pair Audit (open-time check) with Compact File (save-time cleanup). These two options are Revit's official repair workflow and frequently appear together in exam scenarios.
- Which method should the team member use?
Answer: In the Open dialog, select the central RVT and enable the Create New Local option to generate a personal local copy.
When working with workshared Revit projects, you need to understand the difference between a local file and the central model. The central model lives on the network and is the single source of truth. Each team member works in their own local copy, which stays linked to the central model so they can synchronize changes back and forth using Synchronize with Central (SWC).
The correct approach is D: when opening the central model, you check the Create New Local option in the Open dialog. Revit automatically generates a personal local copy in your designated local directory, names it appropriately, and maintains the live connection to the central model — exactly what's needed for SWC workflows.
A is a common beginner mistake. Copying the RVT file through Windows Explorer breaks all worksharing metadata. Revit won't recognize the copy as a properly linked local file, and you risk corrupting the central model relationship. Renaming it as a template makes this even more inappropriate — templates are for starting new projects, not worksharing.
B detaches the file from the central model entirely. While "preserve worksets" keeps your workset structure intact for reuse, the detached file has no connection to the central model and cannot sync — the opposite of what you need.
C is worse than B: it detaches and discards worksets, destroying both the central model link and the workset configuration.
As a study tip, remember: Create New Local = stay connected; Detach from Central = go independent. Any question asking about maintaining SWC connectivity points directly to the Create New Local workflow.
- Which workflow best protects the original while producing an editable Revit 2026 project?
Answer: Open the file in Revit 2026, allow the upgrade, and use Save As to create a separate RVT file.
Whenever you see a Revit version-compatibility question, focus on two priorities: preserving the original file and producing a fully editable native file in the new version. These two goals together point you toward the right workflow.
The safest approach is exactly what D describes. When you open a Revit 2024 file in Revit 2026, Revit prompts you to upgrade the model — this is expected and unavoidable when crossing versions. The critical move is then using Save As to write a new RVT file, leaving the original 2024 file completely untouched on disk. Your team gets a fully native Revit 2026 project they can edit freely, and the consultant's file is never overwritten.
A is a trap because saving as an RTE creates a project template, not a project file. Templates are starting points for new projects, not containers for existing model data — you'd lose the consultant's geometry and data in that conversion.
B is the most dangerous option. Using a plain Save (not Save As) overwrites the original 2024 file with the upgraded 2026 version. Once overwritten, Revit 2024 cannot open a 2026 file — the consultant's copy is permanently destroyed.
C exports to IFC, which is an interoperability format, not a native Revit file. IFC imports back into Revit as a linked or imported reference with significant data loss — families, parameters, and editability are largely stripped away.
Remember this rule: upgrade → Save As. Any Revit version-migration question that omits "Save As" is almost certainly describing a workflow that destroys the original.
- What happens the next time Project Alpha.rvt is opened?
Answer: The project remains unchanged because it does not maintain a live association with its source RTE file.
When working with Revit templates and projects, it's essential to understand the difference between a template file (.rte) and a project file (.rvt). The relationship between them is a one-time transaction, not an ongoing connection.
When a project is created from a template, Revit copies the template's settings, families, view templates, and standards into the new RVT file at that moment. After creation, the RVT is completely independent — it has no live link back to the source RTE. This is why A is correct: opening Project Alpha.rvt a week later will show exactly what it contained when it was saved, regardless of any changes made to Corporate_2026.rte afterward. The updated view template and new families simply don't exist in Alpha's environment.
B is wrong because Revit does not check or "phone home" to the source template on open — no such synchronization mechanism exists for RTE-based projects. C is wrong for the same reason, and also introduces a false distinction; neither view templates nor families travel automatically post-creation, so the idea that one type stays linked while the other doesn't is fabricated. D is wrong because Revit doesn't prompt users to accept or reject template differences — that concept conflates RTE behavior with how linked RVT files or Worksharing Central models behave.
A helpful memory anchor: think of an RTE like a cookie cutter. Once you've cut the dough (created the RVT), reshaping the cutter doesn't change the cookies already made. On the exam, any answer implying an ongoing live connection between an RVT and its source RTE should immediately raise a red flag.
- What should the BIM manager update on each workstation or through the firm's deployment settings?
Answer: The project template entries under Revit's File Locations settings, pointing them to the revised RTE file.
When a question asks why a new template isn't appearing in Revit's New > Project dialog, you should immediately think about where Revit looks to populate that list — and that's the File Locations settings inside Revit Options. This tab contains a "Project Template Files" table where administrators register the paths to RTE files that should appear as default choices. If a revised template lives on the network but isn't listed there, users simply won't see it in the standard dialog, even though they could browse to it manually. Updating those File Locations entries on each workstation — or pushing the change through a deployment configuration — is exactly what resolves this. That's why B is correct.
Choice A is a trap that misrepresents Revit's backup system. The maximum-backup setting controls how many incremental copies of an RVT are saved; it has no relationship to template files whatsoever, and you cannot "point" a backup folder to an RTE file.
Choice C confuses the issue entirely. Relative vs. absolute path types apply to linked models (RVT-to-RVT links), not to project templates. Changing those paths does nothing to the New Project dialog.
Choice D mistakes a template for a central model. A central model is a shared collaborative file; an RTE template is a starting point for new projects. Replacing a central model path with an RTE path would break the project, not fix the template problem — and the passage explicitly says existing RVT files must remain unchanged.
As a study tip: on Revit exam questions, anytime something doesn't appear in the New > Project template list, your first thought should be Revit Options > File Locations.
- Which workflow best meets both requirements?
Answer: Choose New > Project, select Office_Architecture.rte, and create a new project from it.
Whenever you see a question about Revit templates, focus on the distinction between a template file (.rte) and a project file (.rvt). Templates exist as reusable starting points — the entire purpose is to keep them intact while spinning off new projects.
The cleanest, intended workflow in Revit is option B: using File > New > Project and selecting your .rte file as the basis. Revit reads the template, generates a brand-new .rvt project file, and leaves the original .rte completely untouched. This is exactly what templates are designed for — your firm's standards stay protected, and your new model has a proper project file from the very first save.
Each wrong answer has a specific flaw worth understanding. Option A opens the template itself, so any accidental Save overwrites the .rte file — the firm's standard is immediately at risk. Option C might seem clever, but simply renaming a file doesn't change its internal file type; Revit tracks file format internally, and this workaround is unnecessary, unreliable, and bypasses Revit's proper template workflow entirely. Option D shares the same dangerous starting point as A — working directly inside the .rte — and the idea of "exporting to RVT" at the end isn't a standard Revit function; Revit uses Save As to change format, not export, making this doubly incorrect.
As a study tip, remember that on Revit exam questions, any workflow that opens a .rte file directly is a red flag — the correct approach almost always goes through the New > Project dialog to preserve the template.
- Which opening and saving workflow best produces the required archive?
Answer: Detach from Central, discard worksets, and save the result as a new standalone RVT.
When archiving a workshared Revit model, your goal is to sever all ties to the central model while preserving the model's content. The key concept here is the Detach from Central workflow, which breaks the synchronization link that connects a local file to its central model.
Detaching from Central gives you two options: preserve worksets or discard them. Preserving worksets keeps the workset structure intact, which still leaves the file configured as a workshared model — users could theoretically re-establish a central model relationship. Discarding worksets, however, strips out the worksharing infrastructure entirely, producing a clean, standalone RVT with no central model connection. That's exactly what option C does, making it the correct archive workflow.
Option A fails because saving a local file under a new name doesn't remove its link to the central model — it's still a local file that points back to central, and anyone opening it could attempt to synchronize. Option B is closer but wrong in a subtle way: detaching and preserving worksets still leaves a workshared file structure in place. The archive would retain workset definitions and could be re-enabled as a central model, which doesn't meet the "non-workshared" requirement. Option D is dangerous and incorrect — opening the central model as read-only and overwriting it would corrupt or destroy the live central model, which is the opposite of safe archiving.
A useful rule of thumb: whenever a question asks you to produce a non-workshared file from a workshared source, the answer almost always involves Detach from Central + Discard Worksets. That combination is the only workflow that guarantees a truly standalone result.
