All questions
Question 1
A drawing contains a newly attached external reference and several unsaved page-setup changes. The project manager wants a ZIP transmittal that reflects the drawing exactly as it currently appears.
Which workflow most reliably creates the required package?
- Save the host drawing, resolve any save errors, and then create a ZIP package with eTransmit. (correct answer)
- Run eTransmit immediately, because it packages the current in-memory drawing without requiring a saved version.
- Copy the host drawing into a ZIP file, because attached references are embedded when the drawing is compressed.
- Export the layout to DWF first, and then use eTransmit to reconstruct the drawing and its references.
Explanation: When working with eTransmit in AutoCAD, the key principle to understand is that eTransmit packages what exists on disk, not what exists in memory. It reads the saved DWG file to identify all dependencies — external references (xrefs), fonts, plot styles, and page setups — so if your drawing hasn't been saved, eTransmit works from an outdated snapshot that misses your latest changes.
That's exactly why A is the correct workflow. Saving first writes your newly attached xref binding information and unsaved page-setup changes to disk, where eTransmit can reliably detect and include them. Resolving save errors before packaging ensures no corrupted or incomplete file ends up in the ZIP.
B is a common trap. eTransmit does not capture the in-memory state — it reads the last saved version. Running it without saving would produce a package that silently omits your new xref attachment and layout changes, which is precisely the problem the question describes.
C misrepresents how compression works. Manually copying a DWG into a ZIP does nothing to embed or consolidate external references. Xrefs remain separate files stored at their original paths, so recipients without access to those paths will see missing references.
D introduces unnecessary complexity and breaks the workflow. Exporting to DWF converts the drawing to a viewer format — you can't "reconstruct" a DWG with its xrefs from a DWF. eTransmit isn't designed to reverse-engineer DWF exports.
Study tip: Whenever an AutoCAD question involves eTransmit, ask yourself: Has the drawing been saved? Always save (and resolve errors) before transmitting — eTransmit is only as current as the last saved file.
Question 2
A consultant must receive one editable DWG without maintaining links to four referenced DWG files. The sender must retain the original project files with their existing xref relationships.
Which eTransmit configuration best satisfies both requirements?
- Enable binding of external references in the transmittal setup and send the resulting package copy. (correct answer)
- Unload the external references before transmission and restore them after the ZIP file is created.
- Choose an organized folder structure and omit the referenced DWG files from the package.
- Select relative paths for the external references and send only the original host drawing.
Explanation: When a question asks about eTransmit and xref management, focus on two simultaneous requirements: what the recipient needs and what the sender must preserve. Here, the consultant needs a self-contained, editable DWG with no external dependencies, while the original project files must stay intact with their xref structure untouched.
The eTransmit tool in AutoCAD includes a Bind option in its transmittal setup. When you enable binding, AutoCAD merges all referenced DWG files directly into the host drawing as permanent block definitions — eliminating any external links. Critically, eTransmit operates on a copy of your files, so your original drawings and their xref relationships remain completely unchanged. This is exactly why A satisfies both requirements simultaneously: the consultant receives one clean, standalone DWG, and your originals are never touched.
The other options each fail one or both conditions. B — unloading xrefs before transmission — doesn't merge the referenced geometry into the host drawing; it just suppresses display. The consultant would receive an incomplete file missing xref content entirely. C — omitting the referenced DWG files — sends a broken drawing that still contains unresolved xref paths, which would generate missing file errors when opened. D — using relative paths and sending only the host drawing — has the same problem as C: the xrefs are referenced but absent, so the consultant's drawing won't resolve them.
A useful study rule: Bind = merge and break the link permanently; Attach = link remains live. On any eTransmit question, ask yourself whether the goal is to preserve links or eliminate them — that distinction will guide you to the right configuration every time.
Question 3
A contract requires the transmittal ZIP to contain the drawing dependencies plus a project-specific readme.pdf. The PDF is not attached, underlaid, hyperlinked, or otherwise referenced by any drawing.
What should the sender do in eTransmit?
- Add readme.pdf manually to the transmittal file list before creating the ZIP package. (correct answer)
- Place readme.pdf beside the host drawing and rely on eTransmit to include every neighboring file.
- Enter the PDF filename in the transmittal notes so eTransmit embeds the document automatically.
- Attach readme.pdf temporarily as an xref because eTransmit accepts only referenced DWG files.
Explanation: When using eTransmit, it's important to understand what the tool automatically collects versus what requires manual intervention. eTransmit scans your drawings and gathers files that are referenced — xrefs, images, fonts, plot styles, and similar dependencies. If a file has no programmatic link to any drawing, eTransmit simply doesn't know it exists.
That's exactly the scenario here: readme.pdf is a standalone document with no attachment, underlay, or hyperlink connecting it to the drawings. The correct move is A — manually adding the PDF to the transmittal file list. eTransmit's "Add File" option lets you include arbitrary files in the ZIP package precisely for situations like this, where a contract requires supplemental documents that aren't drawing dependencies.
B is wrong because eTransmit does not sweep up every file sitting in the same folder as the host drawing. It only collects files it detects through reference relationships — placing the PDF nearby accomplishes nothing.
C is wrong because the transmittal notes field is a text memo for the recipient, not a file-inclusion mechanism. Writing a filename there does not cause eTransmit to embed or package that file.
D is wrong on two levels: eTransmit handles many file types beyond DWG (images, fonts, etc.), and temporarily attaching an unrelated PDF as an xref is a workaround that would corrupt your drawing's reference structure — never an appropriate solution.
As a study tip, remember that eTransmit is reference-driven. If a file isn't linked to a drawing, you must add it manually. Any question describing an "unreferenced" file that needs to be included is signaling that the manual Add File path is the answer.
Question 4
An office works in the current DWG format, but a client requires all transmitted drawings in an earlier supported DWG format. The office must continue working in the current format after delivery.
How should the transmittal be prepared?
- Bind every referenced drawing because binding changes the host and references to the client's DWG format.
- Use SAVEAS on every source drawing first and continue working from the newly downgraded project files.
- Select a ZIP package type because ZIP compression automatically converts DWGs to an earlier format.
- Set the required earlier file format in the transmittal setup and let eTransmit convert the packaged copies. (correct answer)
Explanation: When a question asks about delivering drawings in an older format while preserving your working files, think about AutoCAD's eTransmit workflow — a tool specifically designed to package drawings and their dependencies for sharing without touching the originals.
eTransmit's transmittal setup includes a file format option that lets you specify an earlier DWG version for the packaged copies only. AutoCAD converts those copies during packaging, leaving your source drawings untouched in the current format. This makes D the correct approach: you configure the target format once in the transmittal setup, run eTransmit, and hand off the ZIP or folder — done, with zero risk to your working project.
A is wrong because binding affects how external references are merged into a host drawing (it embeds xrefs), but it does not change any file's DWG format version. Binding and format conversion are completely separate operations. B describes a destructive workflow — using SAVEAS on your source files and continuing from the downgraded copies would permanently degrade your working project to the older format, which directly violates the scenario's requirement to keep working in the current format. C is a misconception about file compression. ZIP packaging in eTransmit simply archives the files; compression has no knowledge of or effect on DWG format version. Format conversion must be explicitly specified in the transmittal settings.
As a study tip, remember that eTransmit is about packaging for delivery, not editing source files. Any question that mentions transmitting drawings to an external party — especially with format or dependency requirements — should immediately point you toward eTransmit and its setup options.
Question 5
A CAD coordinator receives a transmittal ZIP containing many drawings, images, fonts, and plot-support files. Before opening the drawings, the coordinator wants to identify the original file locations and review any dependency warnings recorded when the package was created.
Which package item should the coordinator examine first?
- The plotter configuration file, which catalogs all drawing, image, font, and external-reference source locations used during the transmittal process.
- The host drawing's automatic-save file, which logs every resolved and unresolved dependency together with the source folder path for each file.
- The transmittal report, which documents packaged files, original source paths, and any dependency warnings or processing notes recorded during package creation. (correct answer)
- The ZIP archive comment field, which replaces the transmittal report and records full dependency and warning information whenever ZIP compression is selected.
Explanation: When working with eTransmit packages in AutoCAD, you should think about what tool exists specifically to document the packaging process itself — not the drawings or support files, but the record of how the package was assembled.
The transmittal report is that record. AutoCAD generates it automatically when you create a transmittal package using the ETRANSMIT command. It catalogs every file included in the package, preserves the original source paths so recipients know where files lived on the sender's system, and flags any dependency warnings — such as missing xrefs or unresolved font paths — that occurred during packaging. This makes C the correct first stop before opening any drawings, since it gives you a complete picture of the package's integrity before you touch anything else.
Choice A is a trap because plotter configuration files (PCF or PC3 files) store printer and plot settings, not file-location catalogs or dependency logs. They play no role in documenting transmittal content.
Choice B misidentifies the autosave file (SV$ extension) as a dependency log. Autosave files are simply timed backup snapshots of a drawing's current state — they contain no transmittal metadata, resolved paths, or warnings whatsoever.
Choice D is a fabrication. ZIP archive comment fields are a generic ZIP feature and carry no structured AutoCAD dependency or warning data. AutoCAD does not route transmittal report information into the ZIP comment field regardless of compression settings.
A good study habit here: whenever a question mentions a transmittal or ETRANSMIT workflow, think "report first." The transmittal report is your audit trail, and reviewing it before opening drawings is standard professional practice.
Question 6
A sheet set contains 24 sheets distributed across 11 drawing files. The deliverable must contain the selected sheets' drawings and their dependent files, but not unrelated drawings elsewhere in the project.
Which workflow is most efficient and least likely to omit a selected sheet?
- ZIP the entire project directory manually, and delete files that do not appear to contain selected layouts.
- Open one sheet drawing, run eTransmit once, and assume the remaining sheet drawings are detected automatically.
- Start eTransmit from the Sheet Set Manager for the selected sheets and review the collected file list. (correct answer)
- Publish the selected sheets to PDF, and use eTransmit to recover the corresponding editable drawing files.
Explanation: When a question asks about efficiently packaging selected sheets with their dependencies, think about AutoCAD's built-in tools for sheet sets — specifically how eTransmit and the Sheet Set Manager work together to handle multi-file deliverables.
The Sheet Set Manager lets you select specific sheets across multiple drawing files and launch eTransmit directly from that context. When you do this, AutoCAD automatically traces each selected sheet's dependencies — xrefs, images, fonts, plot styles — and compiles a complete file list for your review before packaging. This is exactly what answer C describes, and it's the most reliable workflow because the dependency detection is automated and scope-limited to only the sheets you selected.
Answer A fails because manually deleting files from a ZIP archive is error-prone and slow. You may accidentally remove required xrefs or keep unrelated files, and with 24 sheets across 11 files, the risk of omission is significant. Answer B is tempting but dangerously incomplete — opening only one sheet drawing and running eTransmit captures that file's dependencies, but AutoCAD has no way to automatically discover the other 10 drawing files you never opened. You would silently miss most of the package. Answer D confuses two separate tools with different purposes: publishing to PDF creates a non-editable deliverable, and eTransmit cannot reverse-engineer the source DWG files from a PDF. The workflow is circular and doesn't solve the original problem.
Your study tip: whenever you see "selected sheets" and "dependent files" in the same question, that's a signal to think Sheet Set Manager + eTransmit together. AutoCAD designed that integration specifically for transmittal scenarios involving multi-sheet, multi-file projects.
Question 7
A layout uses a custom office.ctb file and a custom largeformat.pc3 configuration. On another workstation, the DWG opens correctly, but lineweights and device settings differ when the recipient plots it.
Before recreating the eTransmit package, what should the sender verify?
- The external references are bound, because unbound references override the recipient's CTB and PC3 files.
- The drawing uses relative paths for all DWG xrefs, because relative paths also transfer plotting configurations.
- All model-space layers are unlocked, because locked layers prevent plot styles and plotters from being packaged.
- The page setup references the intended CTB and PC3 files, and both support files are selected for inclusion. (correct answer)
Explanation: When troubleshooting eTransmit packaging issues, focus on what the feature actually does: it bundles a DWG along with its support files — xrefs, fonts, plot styles (CTB files), and plotter configurations (PC3 files). The problem described is that lineweights and device settings differ on the recipient's machine, which points directly to missing or mismatched plot-related support files.
D is correct because the root cause of mismatched plotting output is almost always that the CTB and/or PC3 files weren't included in the transmittal package. Before regenerating the eTransmit, the sender must confirm two things: first, that the page setup is actually referencing the intended office.ctb and largeformat.pc3 files (not some default substitute), and second, that both files are explicitly selected for inclusion in the eTransmit dialog. AutoCAD doesn't always auto-detect PC3 files for inclusion — you may need to add them manually.
A is a distractor built on a false relationship — binding xrefs affects geometry and layer data, not whether plot style or plotter files travel with the package. B invents a connection that doesn't exist: relative vs. absolute xref paths have no bearing on how plotting configurations are packaged or transferred. C is similarly fabricated — layer lock status is irrelevant to eTransmit's ability to package plot styles or plotter configurations.
For the exam, remember this pattern: whenever a question involves output differences (lineweights, colors, device behavior) after sharing a file, your first instinct should be to check whether the plot style table (CTB/STB) and plotter configuration (PC3) files were included and correctly referenced in the page setup.
Question 8
An eTransmit ZIP was created with relative reference paths and an organized folder structure. The sender wants to verify that the package works independently of the original server paths before delivering it.
Which validation procedure provides the strongest test?
- Open the original host drawing and confirm that all references still resolve from the project server.
- Extract the ZIP to a separate clean folder, open the transmitted DWG, and check its external references. (correct answer)
- Open the DWG directly inside the ZIP archive and confirm that its model-space geometry is visible.
- Compare the compressed ZIP size with the source folder size and confirm that the values are similar.
Explanation: When validating an eTransmit package, you're testing one specific thing: whether the drawing and all its external references (XREFs, images, fonts, etc.) can resolve correctly using only the files inside the package, with no dependency on the original server or project paths. This is the entire purpose of eTransmit — portability. The strongest test simulates exactly what the recipient will experience.
Extracting the ZIP to a clean, isolated folder and then opening the DWG — answer B — is the correct approach because it replicates the recipient's environment. If all XREFs load without missing-reference warnings and the drawing displays correctly, you've confirmed the package is truly self-contained. The "clean folder" detail is critical: it eliminates any chance that AutoCAD accidentally resolves a path back to the original server location through cached search paths.
A is wrong because checking references from the original server tells you nothing about the package's portability. Of course the files resolve from the server — they live there. This test completely misses the point of the validation.
C is tempting but flawed. Opening a DWG directly inside a ZIP archive (via Windows preview or a quick-open) may display model-space geometry without actually loading external references, giving you a false sense of completeness. Missing XREFs won't necessarily prevent basic geometry from appearing.
D tests file compression ratios, not functional integrity. Similar sizes suggest no files were accidentally omitted, but this is a rough heuristic — it cannot confirm that reference paths resolve correctly in the new environment.
The strategy to remember: validating portability always means simulating the recipient's conditions, not checking the sender's environment.
Question 9
The Create Transmittal dialog lists a required raster reference as not found. A copy of the image exists on a former employee's disconnected network drive, but no accessible location currently matches the saved reference.
Which action gives the best assurance that the image will be present and correctly linked in the transmitted drawing?
- Create the ZIP despite the warning, because eTransmit stores the last displayed version of a missing image.
- Resolve or repath the image to an accessible file, reload it, and then recreate the transmittal package. (correct answer)
- Select Place all files in one folder, because that option retrieves files from disconnected drives.
- Bind external references, because binding converts unresolved raster references into embedded drawing objects.
Explanation: When working with eTransmit in AutoCAD, the core principle is this: a transmittal package can only reliably include files that AutoCAD can actually locate and access at the time of packaging. If a reference path is broken, eTransmit cannot retrieve that file — it simply reports it as missing.
The correct approach, choice B, follows the proper workflow: first resolve the broken path by pointing AutoCAD to an accessible copy of the image (using the Reference Manager or the Attach/Reload options in the External References palette), confirm the image loads correctly in the drawing, and then regenerate the transmittal. Only then can eTransmit find, copy, and bundle the raster file alongside the DWG with a correct relative path.
Choice A is dangerously wrong. eTransmit does not cache or store a "last displayed version" of missing raster images. If the file cannot be found, it is simply omitted from the package — the recipient opens a drawing with a broken image link.
Choice C reflects a misunderstanding of what "Place all files in one folder" actually does. That option controls how eTransmit organizes files it has already found — it does not grant AutoCAD the ability to reach disconnected or inaccessible network drives to retrieve missing files.
Choice D confuses raster references with XREFs. Binding applies to DWG-based external references, merging their geometry into the host file. Raster images (JPG, PNG, TIF, etc.) cannot be bound — they remain external files that must physically accompany the drawing.
Your study takeaway: eTransmit only packages what AutoCAD can see. Always resolve missing references before creating a transmittal, not after.
Question 10
A host drawing references files stored in several project subfolders. Two different subfolders each contain an image named logo.png, and each image has different content. The recipient must be able to open the transmitted drawing without either image being substituted for the other.
Which eTransmit path strategy is most appropriate?
- Place all files in one folder so AutoCAD resolves both images from a single search location.
- Use an organized folder structure so distinct source paths remain represented within the package. (correct answer)
- Bind all external references so raster images are converted into named block definitions.
- Remove all paths so AutoCAD selects the first file matching each image filename.
Explanation: When you encounter eTransmit questions, focus on file identity preservation — the goal of eTransmit is to package all referenced files so the recipient's drawing behaves exactly as the sender's did. The critical variable here is that two files share the same filename but live in different folders, meaning their folder path is the only thing distinguishing them.
Choosing B is correct because eTransmit's "organized folder structure" option preserves the relative subfolder hierarchy from the original project. Each logo.png retains its unique path within the package, so AutoCAD can resolve each reference to the correct image — no confusion, no substitution.
A is a trap that sounds tidy but creates exactly the problem you're trying to avoid. Flattening everything into one folder forces both logo.png files to compete for the same location; one will overwrite the other, and the recipient will see the wrong image for at least one reference.
C misrepresents how binding works. Binding applies to DWG-based xrefs (external drawing files) by embedding them as block definitions. Raster images like PNG files cannot be bound — they remain externally linked regardless, so this option doesn't solve the problem at all.
D describes removing path information entirely, which makes AutoCAD search its support paths for any file matching the name. With two files sharing a name, AutoCAD would arbitrarily pick one, virtually guaranteeing the wrong image gets loaded for at least one reference.
Study tip: On eTransmit questions, always ask yourself whether the path type protects file uniqueness. When filenames collide, only a folder-structure approach keeps each reference unambiguous.