If you are sitting the Professional Cloud Architect exam, you will see at least one scenario about a healthcare customer moving regulated data into Google Cloud. The scenario will not ask you to memorize HIPAA in detail. It will ask whether you understand the shape of the problem, who is responsible for what, and which Google Cloud features make compliance achievable. This article walks through what HIPAA actually requires, how Google Cloud fits into the picture, and what the exam expects you to recognize.
The Health Insurance Portability and Accountability Act applies to healthcare organizations that handle Protected Health Information, known as PHI. PHI is any individually identifiable health data, including names, diagnoses, treatment records, and billing information tied to a person. Organizations that create, receive, maintain, or transmit PHI in the course of providing healthcare are called covered entities. Hospitals, insurers, and clinical labs are common examples.
HIPAA imposes two main rules that matter for cloud architecture. The Security Rule requires covered entities to protect the confidentiality, integrity, and availability of PHI through administrative, physical, and technical safeguards. The Privacy Rule governs how PHI can be used and disclosed. Both rules apply regardless of where the data lives, which means moving PHI into Google Cloud does not move the obligation off the covered entity.
When a covered entity stores, processes, or transmits PHI using Google Cloud, Google becomes a Business Associate under HIPAA. A Business Associate is any third party that handles PHI on behalf of a covered entity. Once Google is a Business Associate, it inherits the legal obligation to implement appropriate safeguards for that PHI.
The mechanism that formalizes this relationship is the Business Associate Agreement, or BAA. The BAA is a legally binding contract between the covered entity and Google. It spells out what each side is responsible for, what Google commits to in terms of HIPAA compliance, and what happens in the event of a breach. Without a signed BAA, you cannot put PHI on Google Cloud in a HIPAA-compliant way, even if the underlying services are technically capable of meeting the Security Rule.
This is the single most important point for the Professional Cloud Architect exam. If a question describes a healthcare customer migrating workloads that touch PHI, the first thing the architecture needs is a BAA in place with Google. No technical control substitutes for that contract.
Signing a BAA does not make your application HIPAA-compliant. It makes the underlying Google Cloud services eligible to be used in a HIPAA-compliant architecture. You still have to design the application and the GCP environment so that the controls required by the Security Rule are actually present.
That means you, as the architect, are responsible for things like encryption of PHI at rest and in transit, access controls that enforce least privilege, audit logging that captures who did what to which records, network isolation that keeps PHI away from systems that do not need it, and key management that meets your organization's standards. Google provides the primitives. The covered entity decides how they are wired together.
Another nuance the exam can probe is service eligibility. Not every Google Cloud service is in scope for the BAA. Google publishes a list of HIPAA-covered services, and that list changes over time. If a workload touches PHI, every service in the data path needs to be on the list. Pushing PHI into a service that is not BAA-eligible breaks compliance, even if the rest of the architecture is sound.
In practice, a HIPAA-compliant architecture on Google Cloud usually looks like this. PHI lands in storage that is on the BAA-eligible list, such as Cloud Storage, BigQuery, or Cloud SQL, with customer-managed encryption keys if the organization requires that level of control over key material. Access is mediated through IAM with conditional bindings and audit logging enabled at both the admin and data layers. Network access to PHI services is restricted using VPC Service Controls, which create a perimeter that prevents data exfiltration even if a credential is compromised. Data flowing between services stays inside the VPC perimeter or uses Private Google Access so that PHI never traverses the public internet in cleartext.
For the exam, you do not need to know every BAA-eligible service by heart. You need to recognize the pattern. When a question describes a healthcare workload, the right answer almost always involves a combination of BAA, encryption with a clear key-management story, IAM with audit logging, and network controls that keep PHI inside a defined perimeter.
HIPAA scenarios on the Professional Cloud Architect exam tend to test three things. The first is whether you know that a BAA is required before PHI can be put on Google Cloud. The second is whether you understand that compliance is shared responsibility, with Google providing capable services and the customer being responsible for configuring them correctly. The third is whether you can pick the right combination of GCP features to satisfy the Security Rule, especially around encryption, access control, audit logging, and network isolation.
If you see a distractor that suggests HIPAA is satisfied automatically because the workload runs on Google Cloud, that distractor is wrong. If you see an option that puts PHI in a service not covered by the BAA, that is wrong too. The right answer treats compliance as a design problem with a contract attached.
My Professional Cloud Architect course covers HIPAA and regulated workloads alongside the rest of the architecture and compliance material.
