Citrix DaaS on Citrix Cloud Certified cheat sheet
Citrix DaaS on Citrix Cloud Certified · Keep the key ideas within reach.
Virtual application delivery and component responsibility
Separate identity, enumeration, brokering, hosting and connection evidence.
A visible resource does not prove that a launch path is healthy.
DaaS cloud control and customer resource responsibilities are distinct.
Version-specific console and licensing details need current verification.
Machine catalogs, delivery groups and controlled image updates
Catalog, delivery group, entitlement and available capacity are separate conditions.
MCS disk and PVS boot details vary with the stated supported model.
Random assignment is distinct from persistence and reset timing.
An image rollback does not necessarily reverse external user or application state.
HDX sessions, remote paths and user-experience policies
A portal sign-in and a healthy HDX launch path are different observations.
Gateway, connector and session data paths depend on the chosen design.
Default-printer selection differs from printer assignment and creation.
Correlate client, network, host, profile and application evidence before changing policy.
User state, profile containers, application layers and resource tuning
State ownership, persistence, exclusions and recovery must be explicit.
FSLogix and Citrix Profile Management are different technologies with compatibility requirements.
ELM layer/image workflows differ from every form of runtime application attachment.
Optimization and CPU controls need workload evidence and cannot guarantee every outcome.
DaaS resource locations, identity and cloud-operation boundaries
DaaS cloud control does not remove every customer image, data and identity responsibility.
Connector scale and continuity behavior require supported actual guidance.
Administrator identity, subscriber identity, provisioning and resource authorization differ.
Existing sessions and new launches can have different outage dependencies.
Virtual-delivery monitoring, capacity, continuity and controlled change
Separate the stages of a user’s measured experience.
Registration, capacity, entitlement and connection failures require different evidence.
Power schedules and optimization must preserve actual workload requirements.
Continuity and rollback need tested identity, configuration, image and user-state dependencies.
Identity, access and cryptographic protection
Identification, authentication, authorisation and accounting are four distinct steps.
MFA needs two different factor categories, not two instances of one.
RBAC suits stable job roles; ABAC suits context-dependent, fine-grained rules.
Kerberos uses a KDC with TGT and service tickets for SSO.
Symmetric ciphers handle bulk data; asymmetric ciphers solve key distribution and signatures.
Signing uses a specified signature scheme with the signer’s private key; verification and custody are essential to origin evidence.
ECB leaks patterns; use authenticated modes such as GCM or encrypt-then-MAC.
Security operations, monitoring and response
Asset inventory and configuration baselines underpin every operational control.
Changes need an appropriate authorization path, recovery planning and relevant evidence.
Emergency changes still require retrospective documentation within a defined window.
Monitor log sources for silence, not just for events.
Distinguish historical Revision 2 phases from current NIST incident-response guidance integrated with broader risk management.
Containment precedes eradication in almost every scenario.
Capture volatile evidence (memory, connections) before disk and before power-off.
Continuity, backup and technical recovery
Distinguish tolerated data loss from tolerated interruption.
A recovery point and restore time must both meet the stated targets.
A same-failure-domain snapshot alone does not cover loss of that domain.
Verify complete restore procedures and actual dependency behavior.