Case Study 2: CareBridge Health System - Q&A Preparation
Work in Progress
This content is currently being reviewed for accuracy and will be updated soon.
Q&A Guide
This page compiles judge-style follow-up questions for the case study. Use it after your presentation run-through so you can test how well you defend your choices.
Q&A Snapshot
| Field | Detail |
|---|---|
| Open after | Presentation Notes |
| Format | 45-minute Q&A following a 45-minute presentation |
| Study role | Practice concise, defensible answers |
| Related pages | Case Study Overview, Scenario Paper, Worked Solution |
Q&A Strategy
Answer in 60-90 seconds: state your decision, give one reason, and name one alternative you rejected and why.
Q1: Why Private OWD instead of Public Read Only with restriction rules?
Private OWD is necessary because the access pattern is additive, not subtractive. Eight distinct user types each see a different patient slice. Starting with Public Read Only and restricting down would require restriction rules for every user-type/data combination, which is fragile and error-prone. Private OWD with targeted sharing rules (criteria-based for static groupings, Apex-managed for dynamic patterns) is cleaner and auditable.
Q2: How does the VIP restriction work with the sharing model?
Apex-managed sharing cleanup on the Account standard object. Restriction Rules are not supported on Account — the supported set is custom objects, external objects, Contracts, Events, Quotes, Tasks, Time Sheets, and Time Sheet Entries — so the VIP mechanism has to enforce least privilege a different way. Private OWD on Account is the starting point: no default access. When a patient’s VIP_Flag__c transitions to true, a trigger on Account fires an Apex queueable that does three things in order: (1) delete every AccountShare row for the patient where RowCause is Manual or an Apex sharing reason (Apex cannot delete criteria-based sharing rule rows — those are system-managed), except rows belonging to CareTeamMember-assigned users, (2) re-insert Apex-managed share rows for users with the VIP_Override permission set (CCO delegates and documented break-glass users), and (3) write the full before-and-after access state to the VIP audit log for the 90-day CCO report. Criteria-based sharing rules (Physician department, Hospital Nurse unit, Care Program) include an explicit exclusion clause (AND VIP_Flag__c = false) so they never create share rows for VIP patients in the first place — the criteria exclusion is the primary enforcement, and the Apex cleanup of manual and Apex-managed shares is defence in depth. The trigger also fires on insert and on VIP_Override permission set assignment changes. Every share row insert and delete is recorded by Shield Event Monitoring and exported daily to the external audit archive for the 7-year retention requirement. The CCO can answer “who accessed this VIP patient in the last 90 days” by querying the exported log store via a CRM Analytics dashboard.
Q3: How do you handle specialist access? They only see referred patients.
Apex-managed sharing triggered by the referral lifecycle. When a referral is accepted, an Apex trigger creates a share record on the patient Account. When the episode closes, a second trigger removes it. This is dynamic and event-driven. Criteria-based sharing cannot model this because no static field on the patient maps to which specialists currently have active referrals.
Q4: How do you prevent Patient Access staff from seeing clinical data?
Three layers. First, Private OWD means no default access. Second, criteria-based sharing grants Read Only to accounts with upcoming appointments at their facility. Third, FLS hides all clinical fields (diagnosis, notes, medications, labs, vitals). Even if sharing inadvertently grants record access, FLS prevents clinical field visibility. Defense-in-depth.
Integration Questions
Q5: Why MuleSoft instead of point-to-point?
Three reasons. Protocol diversity: FHIR R4, HL7v2 MLLP, REST. Parsing HL7v2 in Apex is unmaintainable. Volume and reliability: 3,300 lab results plus 15,000 RPM readings per day requires proper queueing and retry. HIPAA audit: centralized logging of every PHI data flow. Retrofitting audit logging later is harder than building it in.
Q6: Health Timeline does on-demand reads from Epic. What about latency? And aren’t you also pushing data in via FHIR Subscriptions?
No — the design commits to on-demand only and does not use Epic FHIR Subscriptions inbound. The two patterns are mutually exclusive, because subscription push plus on-demand read would create duplicate state and defeat the PHI duplication avoidance rationale. The clean split: Salesforce masters demographics (outbound to Epic via CDC / Pub/Sub API), Epic masters clinical data (surfaced in Salesforce through Salesforce Connect virtual FHIR objects backed by a custom adapter, never persisted). A Health Timeline component load issues a MuleSoft FHIR read and returns resources for display only. The FHIR read through MuleSoft takes 1-3 seconds — a 2-second Lightning load satisfies the CMO’s 90-minute time-savings quote, and progressive disclosure masks latency for the typical flow. If latency becomes a problem for high-frequency re-renders, Platform Cache with a short TTL can mitigate without creating a persistent PHI copy (cache expires inside the session and is not a system of record).
Q7: Walk through the RPM alert flow.
MuleSoft polls Philips every 5 minutes. New readings become RPM_Reading records via Platform Events. An Apex trigger evaluates against patient-specific thresholds. If breached: creates RPM_Alert, assigns high-priority Task to care team, sends push notification. For critical alerts (e.g., systolic >200), also pages the on-call physician. Worst-case latency: ~6 minutes end-to-end. Dr. Patel’s team validated this as clinically acceptable.
Q8: How do you ensure no PHI leaks through the integration layer?
Four controls. All transport encrypted (mTLS for Epic, TLS for MLLP, HTTPS for REST). MuleSoft and Anypoint MQ deployed under separate BAA coverage (distinct from the Salesforce BAA). Every message logged with timestamp, source, destination, patient ID, and payload hash — never full payload; logs are encrypted at rest inside MuleSoft’s operational plane. System-to-system authentication via External Client Apps with OAuth 2.0 Client Credentials and short-lived tokens (Connected App creation is disabled by default in Spring ‘26, so new integrations use ECAs). Named Credentials manage outbound callouts from Salesforce so no keys are stored in code.
Data Questions
Q9: How do you handle the 40% patient overlap between Meditech and Epic?
Composite matching key: normalized last name + DOB + gender + last 4 SSN, with Informatica fuzzy matching for edge cases. Survivorship: Epic wins for clinical data, Meditech wins for administrative data not in Epic. Both legacy MRNs preserved as alternate identifiers on the surviving record for audit lineage. The MPI mapping table is the single source of truth for which records merged into which.
Q10: What is your storage strategy for 8% annual growth?
Three-tier strategy with PHI controls at every tier. Hot tier (active + 3 years) in Health Cloud standard objects with Shield Platform Encryption, FLS, and Apex-managed sharing. Warm tier (3-7 years) in archived standard objects via Salesforce Backup or the Privacy Center archive, with Shield Platform Encryption and sharing rules preserved and rehydration on readmission — not Big Objects, because custom Big Objects do not support Shield Platform Encryption, sharing rules, or triggers, which breaks PHI least-privilege. Cold tier (7+ years) in external storage (S3 + Salesforce Connect OData) federated via Data 360 for compliance retrieval, with AWS KMS encryption, a separate AWS HIPAA BAA, and CCO-delegated read-only access. Annual archival job moves aging data between tiers. At 8% growth, hot tier gains ~100K patients and ~280K encounters per year; older data continuously moves through warm to cold.
Q11: What is your rollback plan if migration goes wrong?
The parallel run is the primary rollback window, but rollback has to be reversible, not just “extend the parallel run.” During months 9-11, Meditech is placed in a controlled read-only mode via database user role changes; the writable schema backup is retained, and a documented DBA runbook restores writable access on CIO approval. A reverse-sync MuleSoft flow — built during Phase 1 and held inactive — pushes Health Cloud changes back into Meditech if rollback is triggered. The reverse-sync flow is exercised twice during Phase 3 to prove it works, and test runs are validated by the CCO delegate and the data migration specialist. Exit criteria for the parallel run: 30 consecutive days zero critical discrepancies, all users trained, all integrations stable. If exit criteria are not met by month 12, the team has up to 4 months of buffer before vendor support ends at month 16. The rollback is not theoretical — it is a tested procedure.
Architecture and Governance Questions
Q12: Why not use Epic MyChart for the patient portal?
MyChart works well for clinical interactions, but CareBridge needs a unified portal spanning clinical and non-clinical functions: scheduling, bill pay, insurance verification, care plan tracking, referral status, RPM enrollment, consent management, and education. Building all of that in MyChart requires extensive Epic customization. Experience Cloud with Customer Community (login-based) licenses surfaces clinical data via the Salesforce Connect virtual FHIR adapter (on-demand from Epic) and provides native access to Health Cloud data and self-service capabilities. The login-based licensing model keeps 400K portal users within the $12M budget at $2/login/month; member-based tiers (Customer Community Plus at $6/login or $15/member) are not cost-effective at this scale with ~18K DAU.
Q13: How do you handle offline for home health nurses?
Three pieces, and the sharing mechanism matches the solution consistently. First, Kronos sync at 5 AM triggers an Apex queueable that deletes the prior day’s home-health AccountShare rows and inserts new per-patient share rows for the day’s assignments (one AccountShare per nurse-patient pair, Apex-managed RowCause). This is assignment-level sharing, not zone-level — the nurse sees only her specific assigned patients, which satisfies Req 26 “assigned patients only.” Second, the Salesforce Mobile offline briefcase pre-loads assigned patients’ records (demographics, care plan, visit history) on morning WiFi sync against the freshly rebuilt share rows. Third, nurses document in offline mode; data syncs on connectivity return. Conflict resolution: last-write-wins for most fields; clinical documentation uses create-only (never overwritten, only appended).
Q14: How do you handle the union 90-day notice for home health mobile?
The 90-day notice must go out by month 10 for a month-13 go-live. It requires demonstrating that the technology does not negatively impact working conditions. I invite union reps to UAT during mobile testing, proactively address tracking/surveillance concerns (the app tracks visit documentation, not nurse location), and include union-negotiated training in the rollout. Factored into Phase 3 timeline.
Q15: If you had to cut scope, what would you defer?
I would defer Phase 4: RPM integration, external referral portal, DocuSign consent. RPM nurses have a functional Philips dashboard workflow today. External referrals use phone and fax - not ideal but functional. DocuSign can continue as standalone. What I would NOT cut: Meditech decommission (hard deadline), patient portal (security risk), Epic integration (core physician value). Phase 2 clinical core + Phase 3 portal are the minimum viable transformation.
Identity and Access Questions
Q16: How do you handle Epic SMART on FHIR authentication for the bidirectional integration?
MuleSoft authenticates to Epic using SMART on FHIR backend services (OAuth 2.0 client credentials with signed JWT assertion). Epic registers the MuleSoft application with specific FHIR scopes (Patient.read, Patient.write, Encounter.read, Observation.read, etc.). The JWT is signed with a private key whose public counterpart is registered in Epic’s app configuration. This avoids interactive user authentication for system-to-system flows. Tokens are short-lived (5-minute expiry); MuleSoft handles token refresh transparently. Each FHIR scope maps to a specific integration use case, limiting blast radius if a credential is compromised.
Q17: Walk through the patient portal credential migration for 400,000 users.
Three-phase approach. Phase 1: bulk export hashed credentials from the legacy Java/Struts database. Phase 2: import user records into Experience Cloud with a custom migration script that creates Contact + User records, preserving the email as the username. Passwords cannot be migrated (different hashing algorithms), so every user gets a forced password reset on first login. Phase 3: on first Experience Cloud login, the user sees a branded “Welcome to the new portal” flow that walks them through password creation and MFA enrollment (SMS or authenticator app). Accounts dormant longer than 12 months (roughly 12,000 accounts) are imported but flagged inactive; they only activate on login attempt. The legacy portal runs in parallel for 60 days with a banner redirecting users to the new portal.
Q18: How do you handle staff SSO when a nurse holds licenses in both NC and SC?
Nurse licensing is tracked in a child Nurse_License__c custom object with one record per state license (state, license number, expiration date, status), related to the User record — not a multi-select picklist, because expirations and states change over time and history must be auditable. Entra ID group membership includes state license attributes synced from the HR system; JIT provisioning creates or updates the Nurse_License child records on login. When Kronos sync delivers a patient assignment to a home health nurse, the MuleSoft flow checks whether the nurse has an active Nurse_License record matching the patient’s home state. If the license does not match, the schedule is not hard-rejected — that would create a split-brain between Kronos (which already committed the assignment) and Health Cloud. Instead, an exception record is created with severity “license mismatch,” the schedule record is written with a Pending_Review__c = true flag, and a high-priority task is routed to the scheduling supervisor with a 2-hour SLA. The supervisor either reassigns the patient or overrides with documented justification. The compliance dashboard tracks license expirations 90 days in advance and generates alerts to both the nurse and their manager. Kronos remains the system of record for workforce scheduling; Salesforce surfaces the exception without silently dropping data.
LDV and Scale Questions
Q19: At 8% annual growth, what does your storage look like in 5 years? How do you handle query performance?
Year 1: 1.2M patients, 3.5M encounters, 5.5M RPM readings. Year 5 (compound 8%): ~1.76M patients, ~5.1M encounters/year (cumulative ~22M), ~8.1M RPM readings/year (cumulative ~35M). Encounters and RPM readings are the LDV concerns. Strategy: hot tier (active + 3 years) stays in standard objects with custom indexes on Patient_ID + Date fields. Warm tier (3-7 years) moves to archived standard objects via Salesforce Backup or the Privacy Center archive, preserving Shield Platform Encryption and sharing rules. Cold tier (7+ years) in external storage (S3 + Salesforce Connect OData) federated via Data 360 for compliance retrieval. SOQL queries on hot tier stay performant because archival keeps the active working set under Salesforce’s comfortable range. For RPM readings specifically, I would use custom indexes and batch query patterns. The sharing model is the other concern: with 1.2M Account records and Apex-managed sharing, share table size grows proportionally. I would run sharing model performance tests at projected 5-year volumes during UAT on the full-copy sandbox.
Q20: How does sharing model performance hold up at scale with Private OWD?
Private OWD with Apex-managed sharing creates share records for every nurse-patient and specialist-patient relationship. At projected volumes, the AccountShare table grows to millions of rows. Three mitigations: (1) Apex-managed sharing triggers are bulkified and run asynchronously via Queueable where possible. (2) Share records have explicit expiration logic: specialist shares are removed on episode close, home health shares are rebuilt daily from Kronos (old shares deleted, new shares created in the same transaction). (3) Quarterly share table cleanup job removes orphaned records. During UAT, I load 5-year projected data volumes into the full-copy sandbox and run query performance benchmarks with representative user profiles. If the daily home-health share rebuild approaches the 6 AM deadline, the fallback is a territory-based model via Salesforce Territory Planning on the Health Cloud data model.
Error Handling and Failover Questions
Q21: What happens if Epic goes down during business hours? How does the care team continue working?
Epic is the clinical system of record, and it remains independently accessible; Salesforce is the clinical engagement layer. If the MuleSoft-to-Epic connection fails: (1) Health Timeline displays a “clinical data refresh pending” banner instead of showing stale data. (2) Demographic updates from Health Cloud queue in MuleSoft’s Anypoint MQ and replay automatically when Epic recovers. (3) Care plans, care teams, referrals, and RPM data in Health Cloud remain fully functional because they are native Salesforce data. (4) Lab results continue flowing to Epic via the direct HL7v2 Interconnect path (parallel to MuleSoft); the Health Cloud lab view shows stale data but no clinical decisions are compromised because physicians can access Epic directly. PagerDuty alerts fire if the Epic sync gap exceeds 30 minutes.
Q22: What if the RPM polling fails during a clinical emergency?
If MuleSoft cannot reach Philips: (1) polling retries 3x at 1-minute intervals. (2) After 3 failures, an alert fires to the RPM nurse team AND the MuleSoft operations team. (3) RPM alert generation in Salesforce pauses rather than generating false alerts from missing data. (4) RPM nurses revert to the Philips dashboard directly, which remains independently available. (5) On polling restoration, MuleSoft runs a catch-up load fetching all readings since the last successful poll. If a patient has a critical reading during the outage, the Philips device still triggers the Philips-native alert pathway (SMS to the assigned nurse), which operates independently of Salesforce.
Budget and Licensing Questions
Q23: Walk through the licensing math. Does $12M cover Health Cloud + Shield + MuleSoft + Experience Cloud for 400K users?
The budget fits because Health Cloud Enterprise is scoped to clinical users who actively manage care plans, referrals, and RPM — not the full 8,500 staff headcount. Health Cloud Enterprise is ~$350/user/month at Salesforce public list; there is no “Health Cloud Platform” SKU, and standard Platform users cannot access Care Plan, Care Team, Health Timeline, or HealthcareProvider objects because those require a full CRM license plus the Health Cloud Permission Set License. The scoping: ~2,400 Health Cloud Enterprise users (physicians actively in care coordination, care coordinators, home health nurses, RPM nurses, compliance, and analytics power users) at ~$350/user/month list, discounted ~20% for enterprise healthcare, ramped across 24 months — roughly $4.2M net over 24 months. The remaining ~6,100 staff (Patient Access, Revenue Cycle, admin, IT, and nurses who chart only in Epic) use Sales/Service Cloud or Platform licenses without the Health Cloud PSL, surfacing demographics and scheduling — roughly $1.6M over 24 months. Shield (Platform Encryption + FAT + Event Monitoring) adds ~20% uplift, roughly $0.6M. CRM Analytics for Health Cloud is priced separately at ~$165/user/month and is scoped to ~80 analytics power users, not the full clinical base. Data 360 base + connector adds ~$0.25M over 24 months. Salesforce Maps for 200 home health nurses is ~$75/user/month, roughly $0.36M over 24 months. MuleSoft Anypoint enterprise tier for 5 integration endpoints is ~$1.2M. Experience Cloud: Customer Community login-based at $2/login/month for ~18K DAU works out to ~$432K over 24 months — login-based pricing is the key leverage because member-based tiers at $6-$15/member/month would materially exceed the portal budget. Partner Community for 390 external providers is ~$0.23M. Implementation partner, Informatica CDQ, training, managed support, and contingency round out the total. Net: ~$12.1M, which fits the $12M budget with minor contingency risk. The alternative of giving all 8,500 staff full Health Cloud Enterprise would cost ~$30M list ($24M discounted) and break the budget by ~2.5×.
Q24: How do you handle the 3% orphaned Meditech referrals where the patient ID no longer exists?
Three-step approach. Step 1: during profiling (months 1-4), identify all 135,000 orphaned referrals (3% of 4.5M) and categorize them: (a) patient was merged and the referral points to the non-surviving record, (b) patient record was deleted but referral retained, (c) data entry error with invalid patient ID. Step 2: for category (a), the MPI mapping table resolves the orphan by linking to the surviving patient record. For category (b), if the referral is older than 7 years and has no open actions, archive it to cold storage with a “source patient record unavailable” flag. For category (c), route to clinical SME review queue with a 4-week deadline before go-live. Step 3: any referral that cannot be resolved is migrated with a special status (“Legacy - Unresolved”) and excluded from active referral metrics. No data is discarded without clinical SME sign-off.
Governance Questions
Q25: How do you handle state-specific consent retention? NC requires 11 years, SC requires 10 years.
The Consent_Record__c object includes a Patient_Home_State__c field derived from the patient Account. A formula field Retention_End_Date__c calculates the retention deadline: signature date + 11 years for NC patients, + 10 years for SC patients. An automated Flow checks quarterly for consent records past their retention end date and routes them to the compliance team for review before deletion (no automated deletion of consent records, ever). If a patient moves from SC to NC mid-treatment, the longer retention period (11 years) applies retroactively to all their consent records. Shield Field Audit Trail retains the full modification history for 7 years regardless of consent retention rules, providing a second layer of compliance coverage.
HIPAA and Compliance Questions
Q26: Walk me through what happens if a PHI breach is detected. What is your notification timeline? Who is notified?
Three lanes: detection, containment, and notification, each with named owners. Detection: Shield Event Monitoring streams to a SIEM (CareBridge’s existing Splunk instance via the Event Monitoring Analytics app) with alerts for anomalous access patterns — bulk record exports, out-of-hours VIP access, geography anomalies, or access from outside the home health nurse’s assigned patient set. Containment: the CCO delegate has a documented runbook to revoke sessions, disable users, or flip the VIP trigger into lockdown mode (no new share rows for any VIP patient until the incident is closed). A preserved copy of Shield Event Monitoring logs for the incident window is exported immediately to the external audit archive so the chain of evidence is not lost to the 30-day retention window. Notification: HIPAA Breach Notification Rule requires notification without unreasonable delay and no later than 60 days after discovery for affected individuals; HHS is notified within 60 days for breaches ≥500 individuals (or annually for smaller breaches); state breach laws (NC, SC) have shorter timelines and are tracked by the compliance dashboard. Notification templates are pre-approved by legal and stored in Knowledge; the breach workflow is a Flow that drives task assignments to the compliance team with hard SLA deadlines.
Q27: You said clinical data is not persisted in Salesforce via on-demand FHIR reads. But what about the data that is persisted — demographics, care plans, RPM readings? How do you ensure US data residency (Constraint 7)?
Three mechanisms. First, Salesforce Hyperforce lets the customer select the region during org provisioning; CareBridge’s org is provisioned in a US Hyperforce region, and the Salesforce Trust site publishes the instance location. This is a contractual commitment enforced in the Master Subscription Agreement and the BAA. Second, MuleSoft Anypoint Runtime Fabric is deployed to a US region (AWS US-East or CloudHub US) with the region pinned in the MuleSoft Anypoint control plane; all data processing and queueing happens in US-resident infrastructure. Third, the cold tier external storage is an AWS S3 bucket in a US region with the us-* bucket constraint and AWS Config rule preventing cross-region replication; the Data 360 connector is configured against the US bucket. Annual attestation by the CCO delegate verifies all three — Salesforce instance location, MuleSoft region, and AWS region — against the BAAs and regulatory requirements.
Q28: A patient withdraws consent for data sharing. What happens to their records in Health Cloud, their portal access, and their data in Epic?
HIPAA gives patients the right to request restrictions on PHI use (45 CFR 164.522). CareBridge’s workflow: the patient submits a withdrawal request via the portal or in person; a compliance workflow creates a Consent_Withdrawal_Request record linked to the patient Account with a severity classification. For full withdrawal from the engagement platform, the compliance team (1) disables the patient portal user via a scheduled deactivation (preserving the record for audit), (2) flips a Consent_Status__c field on the Account to “Withdrawn” which a sharing rule and validation rule combination uses to block write access from non-emergency users, (3) triggers a Flow that halts all outbound integrations touching the patient — no more Epic demographic push, no RPM data flow, no Kronos-driven home-health sharing — and (4) sends a notification to Epic’s registration module via MuleSoft so Epic can flag the withdrawal for its own clinical workflow. Epic clinical records themselves are not deleted because they are the legal medical record; HIPAA allows providers to retain clinical data for treatment even after a restriction request. For data deletion requests (as opposed to withdrawal), the compliance team uses Privacy Center to orchestrate field-level erasure on the Health Cloud side, with the 7-year audit trail preserving the erasure event metadata.
Q29: Your error handling design puts failed messages with patient identifiers into Anypoint MQ dead letter queues. Is PHI at rest in MuleSoft? Does your BAA cover Anypoint MQ?
Yes on both. Anypoint MQ and the MuleSoft Anypoint operational logs contain patient identifiers by design (correlation IDs and patient IDs logged alongside timestamps and payload hashes — full payloads are never logged, but the identifier alone is PHI). The MuleSoft BAA explicitly covers Anypoint Platform, Anypoint MQ, Anypoint Monitoring, and the Anypoint logs storage tier. The BAA is separate from the Salesforce Healthcare BAA because MuleSoft is a distinct cloud service with its own service agreement and security certifications. Operational controls on top of the BAA: Anypoint MQ messages are encrypted at rest, DLQ retention is capped at 30 days with automated purge, DLQ access is restricted to 2 named MuleSoft operations engineers via Anypoint Access Management, and every DLQ access is logged to Anypoint audit and reviewed weekly by the CCO delegate. For the 6-BAA inventory, MuleSoft is listed separately alongside Salesforce, Informatica, DocuSign, Philips, and AWS.
Q30: How does the CCO actually run the 90-day access report the paper’s stakeholder quote calls out?
The CCO asked to “run a report at any time showing who accessed a specific patient’s record in the last 90 days.” Shield Event Monitoring captures record-level access via the Lightning URI, URI, and Report events, but EventLogFile retention is only 30 days natively and 1 year with Shield Event Monitoring. The 90-day window is served from an external audit archive, not directly from Salesforce. The workflow: MuleSoft exports EventLogFile hourly to an S3 bucket in the CareBridge audit archive AWS account (under the AWS HIPAA BAA); the bucket is Snowflake-loaded daily into a compliance dataset. A CRM Analytics dashboard federated against the Snowflake dataset (via Salesforce Connect + CRM Analytics External Data) exposes a “Patient Access History” widget — the CCO delegate enters a patient MRN and the dashboard returns every access event from the last 90 days with user, timestamp, access type, and source IP. For broader analytics (anomaly detection, trend reports), Splunk runs SIEM queries against the same S3 export. Both paths keep the 7-year HIPAA retention obligation intact because EventLogFile archive retention is 7 years on the S3 side, independent of the 30-day / 1-year Salesforce native retention. The operational procedure is documented in the CCO runbook and tested quarterly.
Question Categorization
| Question | Primary Domain | Secondary Domain |
|---|---|---|
| Q1-Q4 | D2 Security | D1 System Arch |
| Q5-Q8 | D5 Integration | D1 System Arch |
| Q9-Q11 | D3 Data | D6 Dev Lifecycle |
| Q12-Q13 | D4 Solution Arch | D3 Data |
| Q14-Q15 | D6 Dev Lifecycle | D1 System Arch |
| Q16-Q18 | D2 Security / Identity | D5 Integration |
| Q19-Q20 | D3 Data / LDV | D1 System Arch |
| Q21-Q22 | D5 Integration / Failover | D4 Solution Arch |
| Q23-Q24 | D1 System Arch / Budget | D3 Data |
| Q25 | D6 Dev Lifecycle / Compliance | D2 Security |
| Q26-Q30 | D2 Security / HIPAA Compliance | D5 Integration / D3 Data |
Q&A Strategy
If asked a question you did not prepare for: pause, restate to confirm understanding, state what you know, and if uncertain say “I would need to validate this, but my approach would be…” Never bluff on clinical or compliance topics.
Related Topics
Always verify against official Salesforce documentation
This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.
Personal study notes for the Salesforce CTA exam. Content compiled from VJ's study notes, official Salesforce documentation, community sources, and online publicly available content, then organized and presented with AI assistance. Not affiliated with Salesforce. © 2025–2026 VJ Srivastava.