- Which action best satisfies the requirement?
Answer: Use the Linework tool on the three edges in that elevation and select the custom line style.
Whenever you see a Revit question about changing how something looks in only one specific view, you should immediately think about view-specific overrides rather than any tool that modifies categories, families, or type properties — those changes propagate project-wide.
The Linework tool (found on the Modify tab) is purpose-built for exactly this scenario: it lets you override the line style of individual edges in a single view without touching any underlying definition. You simply activate the tool, choose your custom line style from the Type Selector, and click each of the three wall edges in that elevation. The change is stored as a view-specific graphic override, meaning every other view remains completely untouched — which is precisely what the question requires.
Choice A is wrong because editing a wall family category rewrites how every wall edge appears across the entire project, the opposite of a view-isolated change. Choice B is equally broad — modifying Object Styles sets project-wide defaults for the entire Walls category, violating the requirement to leave the office standard intact. Choice C sounds targeted, but type properties in Revit affect every instance that shares that wall type across all views; there is also no direct "line style" parameter in wall type properties for individual edges, making this both incorrect in scope and inapplicable in practice.
The key study tip: whenever a question specifies "this view only" or "do not affect other views," the answer almost always involves a view-specific tool — Linework, Visibility/Graphics Overrides, or a Graphic Display Option — never a category-level or family-level setting.
- Which standards-management approach is most appropriate?
Answer: Create a clean project template containing the approved standards and use it when creating each new project.
When you see a question about firm-wide standards in Revit, think about the distinction between where standards live and how they propagate to new projects. The cleanest, most scalable solution is one that requires zero manual recreation and contains no leftover model geometry.
A project template (.rte file) is specifically designed for this scenario. It stores view templates, line styles, Object Styles, annotation families, and dozens of other settings while remaining completely free of model elements. When a new project is created from it, every approved standard is present from the first save — no extra steps, no risk of omission. That makes A the correct and most appropriate approach.
B is a workaround, not a solution. Copying a drafting view transfers only what's visible in that view (a handful of line samples), not Object Styles, view templates, or system-wide settings. It's fragile and incomplete.
C is the opposite of what the firm wants. Recreating standards "as modeling progresses" is error-prone, time-consuming, and virtually guarantees inconsistency across projects. The passage explicitly states standards should exist before any modeling begins.
D misrepresents how Revit links work. A linked model does not control or push its Object Styles, line styles, or view templates into the host project. Linked file graphics can be overridden in the host, but the host's own standards remain independent. This approach would not achieve the described goal.
Study tip: On Revit exam questions about standards and firm setup, the template (.rte) is almost always the answer when the requirement is "consistent settings, no model content." Memorize what a template stores versus what a transfer of project standards does — they're commonly tested together.
- What will normally happen to the fire-rated walls in a view assigned to this template?
Answer: They remain hidden because the entire Walls category is disabled in the view.
Whenever you see a question about Revit's view template visibility controls, you need to understand the strict hierarchy: category visibility is a prerequisite for everything else. Think of it as a gate — if the gate is closed, nothing gets through, regardless of what's waiting on the other side.
In Revit, view filters and Object Styles both operate within the visibility framework established by Model Categories. When the Walls category is turned off in a view template, Revit suppresses all wall geometry before any filter logic is even evaluated. The fire-rated wall filter never gets a chance to run because those elements are already hidden at the category level. This is why C is correct — the walls remain hidden entirely, regardless of the filter's settings.
A is wrong because there is no "cancellation" mechanism in Revit — category visibility and filter visibility don't negotiate or balance each other out. One simply gates the other. B is the most tempting distractor, and it reflects a common misconception. Filters do override Object Styles for properties like color and line weight, but they cannot override a category that has been completely disabled. The filter only controls how visible elements appear, not whether hidden elements reappear. D is wrong because individual element visibility (via the "Hide Element" command) is yet another layer of control, and it's irrelevant here — the category setting alone is sufficient to hide all walls.
Your study tip: memorize Revit's visibility priority order — Category → Filter → Object Styles → Element Override. A higher-level "off" switch cannot be unlocked by a lower-level setting.
- Which workflow best achieves the requirement?
Answer: Transfer View Templates through Transfer Project Standards and choose to overwrite the existing same-named standard.
When working with Revit's project standards, the key concept being tested here is how Transfer Project Standards handles naming conflicts — specifically whether it can overwrite an existing standard rather than simply adding new ones.
Transfer Project Standards (found under the Manage tab) lets you copy standards like view templates, line styles, and filters from one open project to another. Crucially, when a name conflict exists, Revit prompts you to overwrite the existing standard. Choosing "Overwrite" replaces the old template's definition while keeping its name intact — meaning any views already assigned to that template name retain their assignment automatically. This is exactly what option A describes, making it the correct workflow: one operation, no manual reassignment required.
Option B fails the requirement because individually applying template properties to each view doesn't update the shared template definition itself — future views or reapplications would still reference the outdated template, and the process doesn't scale well.
Option C gets the outcome partially right (a clean source template lands in the target), but it creates unnecessary rework. Renaming the old template and importing the source as new breaks every existing view assignment, forcing you to manually reconnect each view — the very thing the question wants to avoid.
Option D is a misconception about linked files. Linking a Revit project shares geometry and some data, but it does not allow a linked project's view templates to govern views in the host project. Templates are not inherited across links.
Study tip: On Revit exam questions about sharing standards between projects, always think "Transfer Project Standards + Overwrite" when the goal is replacing an existing definition without disrupting current assignments.
- Which line weights should normally govern the two walls in that section?
Answer: Weight 5 governs the cut wall, while weight 2 governs the wall shown in projection beyond the cut.
Whenever you see a Revit question about line weights in section views, the key distinction to hold in mind is cut graphics vs. projection graphics. Revit applies these two graphic categories based on the spatial relationship between an element and the section cut plane — not simply because a view is a section view.
When a section cut plane slices directly through an element, Revit uses that element's cut line weight (weight 5 for Walls in this scenario). The wall being cut is rendered thicker to visually communicate that it has been sectioned. Any element that falls beyond the cut plane — visible but not sliced — is drawn using its projection line weight (weight 2), just as it would appear in an elevation or plan view where no cut occurs. This makes B correct: the cut wall uses weight 5, and the wall shown beyond the cut uses weight 2.
Answer A reverses the logic entirely — it assigns the projection weight to the cut wall and the cut weight to the projected wall, which is the opposite of how Revit's graphic system works. Answer C incorrectly assumes every element in a section view is treated as cut; only elements intersected by the cut plane receive cut graphics. Answer D is equally wrong in the opposite direction — it claims projection graphics govern everything in orthographic views, ignoring that cut graphics absolutely apply to intersected elements in sections and plans.
A useful memory anchor: "Cut = sliced = thicker line." Ask yourself whether the cut plane physically passes through the element. If yes, cut weight applies; if no, projection weight applies. This logic extends to floor plans and callouts as well.
- What should a user expect when editing the three plans?
Answer: View Scale remains editable per plan, while the included template parameters remain controlled by the template.
When working with view templates in Revit, the key distinction to understand is the difference between included and excluded parameters. A view template doesn't have to control every view property — you can selectively exclude parameters, which returns control of those properties to the individual view.
In this scenario, the template includes Visibility/Graphics and Detail Level, meaning those settings are locked and synchronized across all three floor plans. However, View Scale has been explicitly excluded from template control. This exclusion applies uniformly to every view the template is assigned to, regardless of what scale that view is currently set to. Each plan is therefore free to have its own independent scale — exactly what answer A describes.
Answer B is wrong because it assumes that assigning a template locks all view properties. That's a common misconception. Revit gives you granular control through the "Include" checkboxes in the template definition — unchecking a parameter explicitly releases it back to the view.
Answer C is wrong because excluded parameters work in one direction only: the view controls them independently. Changing a view's scale does not push that value back into the template or alter any stored template setting.
Answer D is wrong because exclusion is not applied selectively based on what value a view happens to have. The exclusion is a template-level setting — it applies equally to all three plans, not just the one with a different scale.
Study tip: On questions about view templates, always ask yourself whether a parameter is included or excluded in the template — that single toggle determines whether the view or the template is in control.
- Which standards setting should be modified?
Answer: Modify the A-UTIL layer under Imported Objects in Object Styles.
Whenever you see a question about controlling the appearance of imported CAD content in Revit, think about where Revit separates native element styles from imported element styles. These live in different places within Object Styles, and mixing them up is a classic mistake.
Revit handles imported DWG layers through a dedicated section called Imported Objects within Object Styles (Manage tab → Object Styles → Imported Objects tab). Each DWG layer appears as its own sub-category, and you can assign a project-wide color and line weight directly to it. Since the passage says no view-specific variation is needed and the change must apply throughout the project, modifying the A-UTIL layer under Imported Objects is exactly the right tool — it sets a global default for that layer everywhere it appears.
Choice A is wrong because the Linework tool applies view-specific, element-level overrides. You'd have to repeat the action in every view, which directly contradicts the requirement for a universal change. Choice B is a trap: creating a native Revit line style under the Lines category in Object Styles only affects native Revit sketch lines and detail lines — it has no connection to DWG layer display. Choice C is similarly misguided; Model Objects controls native Revit model categories (walls, floors, etc.), not imported CAD geometry. Applying a change there wouldn't touch the DWG layer at all.
Study tip: Remember the separation: native Revit elements → Model Objects tab; imported DWG layers → Imported Objects tab. Any exam question involving a specific CAD layer and project-wide consistency should immediately point you to Imported Objects in Object Styles.
- Which elements are affected by the change?
Answer: Both the detail lines and model lines using the style update, while the wall edges remain unchanged.
Whenever you see a question about line styles in Revit, anchor your thinking to one key principle: a named line style is a shared definition stored in the project. Any element that references that style by name — regardless of category — displays whatever properties the style currently holds.
That's exactly why C is correct. Both detail lines and model lines explicitly reference the "Survey Boundary" style by name. When the BIM manager edits that style's color, pattern, and weight in Object Styles (or the Line Styles dialog), the definition itself changes, and every element pointing to it updates automatically. The wall edges, however, are governed by their own category settings in Object Styles — they never referenced "Survey Boundary" in the first place, so their appearance is completely unaffected.
A is wrong because it reverses the truth: model lines can use custom line styles just as detail lines can. Neither category has exclusive ownership of line styles. B is equally incorrect — detail lines don't "freeze" their graphics at creation time. They stay dynamically linked to the style definition, just like model lines do. D goes too far by including the wall edges. Proximity to other elements is irrelevant in Revit; only an explicit Linework override or a shared style assignment would tie a wall's edge appearance to that style, and the question tells you no such override exists.
A useful study tip: think of a line style as a template, and elements as instances pointing to that template. Editing the template propagates to all instances — but only to elements that actually use it.
- How will wall projection lines normally display in the coordination view and in an otherwise unmodified view?
Answer: They display red in the coordination view and blue in the unmodified view.
Whenever you see a Revit question about graphic display, think in terms of a priority hierarchy: element-level overrides beat view-specific overrides, which beat Object Styles (the project default). View templates sit at the view level of this hierarchy — they control what a specific view displays, but they don't rewrite the project-wide Object Styles baseline.
In this scenario, the coordination view has a view template that overrides wall projection lines to red. That override applies only within that view, so walls appear red there. The unmodified view has no view template, no element overrides, and no Linework tool changes, so it falls back to the Object Styles default — blue. This makes A the correct answer: red in the coordination view, blue in the unmodified view.
B is wrong because Object Styles sit at the bottom of the priority stack, not the top. View-level settings always win over Object Styles, not the other way around. C contains a critical misconception: view templates do not alter Object Styles. They are a view-level instruction that overrides display within that view only — the moment you open a different view without that template, the project standard resumes. D reverses the logic entirely, suggesting the template-controlled view shows blue and the default view shows red, which contradicts how the hierarchy works.
A useful rule of thumb: think of Object Styles as the "factory setting" that every view inherits unless something higher in the hierarchy — a view template, view-specific override, or element override — steps in to change it.
- What is the expected result after the template is changed?
Answer: Plan 1 adopts the new detail level, while Plan 2 retains the value applied during the earlier one-time operation.
Whenever you see a question about view templates in Revit, the critical distinction to understand is the difference between assigning a template and applying one — these two workflows behave completely differently after the fact.
When a view template is assigned to a view (visible in the View Properties as a persistent link), the view is continuously governed by that template. Any change the BIM manager makes to the template is immediately reflected in all views where it remains assigned. This is what happens to Plan 1 — because "Permit Plan" is still actively assigned, the updated detail level flows through automatically.
Plan 2 is a different story. Using Apply Template Properties is a one-time stamp: Revit copies the template's current settings into the view at that moment, then severs the connection entirely. The view now owns those properties independently. When the template changes later, Plan 2 has no knowledge of it — there is no link left to carry the update through. So Plan 2 keeps the detail level that was stamped in during that earlier operation, confirming that B is correct.
Choice A is wrong because it assumes both plans maintain an ongoing relationship with the template, which is only true for Plan 1. Choice C reverses the logic — Plan 1 is the one with the live connection, not Plan 2. Choice D is a common misconception; template changes do propagate immediately to currently assigned views, not just future ones.
Study tip: Think of "Apply Template Properties" like a photograph — it captures a moment but doesn't update when the subject changes. "Assigned" templates are more like a live video feed.
