1Y0-201 · Question #135
Scenario: A Citrix Administrator uses Machine Creation Services to provision desktops in an environment. Productivity applications are installed locally into desktop OS machines. The administrator is
The correct answer is D. Update the master image then update the appropriate machine catalog.. With Machine Creation Services, application updates are made in the master image, and then the machine catalog must be updated to point provisioned machines to the new image snapshot.
Question
Scenario: A Citrix Administrator uses Machine Creation Services to provision desktops in an environment. Productivity applications are installed locally into desktop OS machines. The administrator is instructed to update the productivity applications. Which action should the administrator take after updating the applications in order to ensure that users are provided with the updated applications?
Options
- AUpdate the master image then update the delivery group.
- BUpdate the machine catalog then update the delivery group.
- CUpdate the desktops then update the appropriate machine catalog.
- DUpdate the master image then update the appropriate machine catalog.
How the community answered
(41 responses)- A15% (6)
- B10% (4)
- C5% (2)
- D71% (29)
Why each option
With Machine Creation Services, application updates are made in the master image, and then the machine catalog must be updated to point provisioned machines to the new image snapshot.
Updating the delivery group after the master image skips the required step of updating the machine catalog - the delivery group references the catalog, not the image directly, so the machines would not receive the update.
The machine catalog cannot be updated to a new image without first updating the master image and creating a new snapshot - there is no new version to point the catalog to.
Updating individual desktops manually bypasses MCS management and does not propagate changes through the catalog, leading to inconsistency across the pooled machines.
In an MCS environment, the master image is the authoritative source for all provisioned machines. After updating applications in the master image and taking a new snapshot, the administrator updates the machine catalog to reference the new snapshot, which then rolls out the updated image to the machines in that catalog on next restart.
Concept tested: MCS master image update and machine catalog refresh workflow
Source: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/install-configure/machine-catalogs-manage.html
Topics
Community Discussion
9
Giovanna H.Jan 8, 2026Mapped to the Managing Machine Catalogs section of the 1Y0-201 blueprint, the mnemonic here is Image First, Catalog Second, never touch the delivery group for an app update. The correct answer is D because in an MCS environment the master image is the single source of truth for all provisioned desktops, so you update the applications there and take a new snapshot, then update the machine catalog to point to that snapshot so MCS can propagate the change across the provisioned machines. The delivery group controls user access and assignment, not the image content, which is why options A and B that involve updating the delivery group are incorrect, and option C has the workflow backwards entirely.
Kemal J.Dec 7, 2025D is right, but do you understand why touching the delivery group would break things here?
Bao N.Dec 7, 2025Changing the delivery group mid-stream resets the session affinity, so any in-flight packages get orphaned and the counters misalign, which is exactly the kind of silent failure that tanks your score on the simulation questions.
Viktor S.Nov 26, 2025I keep seeing people overthink this one. The desktops are where the apps actually live, those are desktop OS machines with locally installed software, so you go update the apps directly on the desktops first. Once the desktops have the new versions, you then update the machine catalog so MCS reflects that updated state and any new machines provisioned from it carry the right apps. Going to the master image first sounds logical until you remember that the catalog and the provisioned desktops have their own relationship, and if you skip updating the actual desktops and just mess with the catalog, you have not actually touched the running machines users are on. C is the only option that follows the actual flow of where the apps live and how MCS tracks that state.
Giovanna H.Nov 28, 2025Viktor, MCS-provisioned desktops are not meant to receive direct updates because changes made to them do not persist across restarts the way they would on a physical machine, so the correct sequence under D is to update the master image first and then update the catalog so that updated snapshot propagates to provisioned machines. The desktops are ephemeral constructs derived from that image, and the master image is precisely where durable app changes belong.
Lena V.Dec 17, 2025I keep coming back to A on this one and here is my reasoning. With MCS, everything flows from the master image, so if you install updated productivity apps directly on that image, the next logical step is to push that change out at the delivery group level so users actually get the new version when they log in. Updating the delivery group is what triggers the rollout to end users, and skipping straight to the catalog step feels like it misses the point of how MCS manages the image lifecycle. The master image is your source of truth, and the delivery group is your distribution mechanism, so A follows that logical order from source to end user. I studied this workflow pretty heavily and the pattern of image first, then delivery group, shows up consistently in how Citrix frames MCS administration tasks.
Kemal J.Dec 19, 2025Lena, the delivery group does not actually know a new image exists until you update the catalog first, because MCS ties the snapshot to the catalog, not directly to the delivery group, so D is correct because you have to update the catalog before the delivery group has anything new to roll out.
Bao N.Jan 2, 2026B has to be right here because with MCS the machine catalog is what ties your provisioned desktops back to the snapshot, so if you update the catalog to reflect the new image state, the delivery group just pulls from whatever the catalog is serving and your users get the updated apps automatically. Updating the delivery group without touching the catalog first would just keep serving the stale image, so the order in B is the only one that makes logical sense to me.
Giovanna H.Jan 5, 2026Bao, you have the catalog-to-delivery-group relationship right, but the missing piece is that updating the catalog only stages the new snapshot, it does not push it to the provisioned machines until you also run the Apply action, which is exactly what D includes as the final step. Without that apply and the subsequent machine restart cycle, users still boot from the old differencing disk regardless of what the catalog metadata shows.