Invoking Claude Through Third-Party Vendors for the CCDV-F Exam

One model, several front doors

Claude is not reachable only through Anthropic's own API. The same Claude model runs across several deployment surfaces, and the Claude Certified Developer - Foundations (CCDV-F) exam expects you to reason about which surface fits a customer. The first-party Claude API is Anthropic's own environment and is typically first to receive new features. Amazon Bedrock and Google Vertex AI expose the same models inside AWS and Google Cloud respectively. And products such as Microsoft Foundry embed Claude inside a platform the customer may already be standardised on. Every one of these is the same Messages API request and response cycle reaching the same model; what changes is the environment around it.

What Bedrock and Vertex add is that the model runs inside the customer's own AWS or Google Cloud account. That means the request authenticates with that cloud's identity system - AWS IAM or Google Cloud IAM - rather than an Anthropic API key, and the data stays inside that cloud's boundary, with regional routing available when data residency is a constraint. The model is identical; the identity, the data boundary, and the operational envelope belong to the customer's cloud.

The surface is chosen by posture, not by merit

The instinct of a developer is to compare platforms on technical merit and pick the best one. For deployment surface, that instinct is wrong, and the exam tests it directly. Because the model is the same everywhere, there is no better model to choose. The deciding factor is almost always where the customer already holds cloud infrastructure and compliance agreements. A shop that runs on AWS, with its security reviews and certifications already framed around AWS, will invoke Claude through Bedrock so the workload lands inside an environment it has already vetted. A Google Cloud shop reaches the same conclusion with Vertex.

The reason is that matching the platform to an existing certification avoids a data-residency and compliance review from scratch. When Claude runs inside a cloud the customer is already audited on, the identity model, the data boundary, and the compliance paperwork are already in place. Choosing a surface the customer does not already operate would mean standing up and certifying a whole new environment. This is why deployment surface is an infrastructure and non-functional requirement that flows from the customer's posture, not a technical preference expressed in the code.

Residency and compliance can rule a surface out

Some constraints do not just favour a surface, they eliminate one. The clearest is EU data residency: the direct Claude API does not currently offer EU data residency, so an EU-only workload must route through Bedrock or Vertex, whose regional routing keeps the data in-region inside the customer's cloud. Quoting the first-party API for an EU-residency requirement it does not satisfy is a straight error, and the exam builds scenarios exactly there.

Two more compliance properties vary by surface and must be confirmed rather than assumed. Zero Data Retention (ZDR), where request and response content is not retained, and HIPAA Business Associate Agreement (BAA) eligibility, needed for protected health information, are both available for some model-and-platform combinations and not others. Because they vary by model and by platform, the discipline is to confirm ZDR and HIPAA BAA eligibility per model at scoping time, not to assume a capability carries across every surface. The trap that catches candidates is assuming an existing ZDR agreement blankets every model: eligibility is not guaranteed for every model even under one, and a newer or higher-capability release may not have ZDR status confirmed yet. So a regulated workload that requires ZDR may be constrained to a specific model or platform confirmed eligible at scoping - checked against Anthropic's Trust Center, and against each cloud's own data-retention terms on Bedrock, Vertex, or Microsoft Foundry. On cost, per-token rates are broadly aligned across surfaces, so total cost moves on data egress, platform fees, and integration effort rather than on token price - which means cost is measured per call per platform, not by comparing headline token prices.

What the CCDV-F exam trips candidates on

Three traps recur. The first is assuming the first-party API is always the right choice, ignoring that a regulated customer's residency or compliance posture may require Bedrock or Vertex. A scenario gives you a customer already deep in AWS with a compliance regime, and the credited answer is Bedrock, not the direct API, because the surface follows the posture. The second is believing the deployment surface changes the model's capabilities. It does not - it changes only the identity, the data boundary, and the timing of when new features arrive. If a question implies Bedrock gives you a weaker or different Claude, that framing is the distractor.

The third is the residency specific one: quoting the direct Claude API for an EU-data-residency requirement it does not currently satisfy. When a scenario states EU-only data handling, the direct API is ruled out and the workload routes through Bedrock or Vertex. Hold three ideas together - the model is the same everywhere, the surface is chosen by posture, and residency and compliance can eliminate a surface - and these questions resolve cleanly.

Common misreadings to avoid

How this shows up on the exam

Domain 2 questions on this knowledge point are scenario-based and posture-driven. A frequent shape gives you a customer with a stated cloud footprint and a compliance or residency constraint and asks which surface to use; reason from posture, not merit, and let a residency rule eliminate the direct API when EU data handling is required. Another shape probes whether you believe the platform changes the model - it does not, only the identity, data boundary, and feature timing move. A third tests whether you will confirm ZDR or HIPAA BAA per model rather than assume it.

This knowledge point runs on the same Messages API request and response cycle whichever surface you pick, and it sits beside the other Claude API mechanics such as vision and multimodal inputs. It also connects to model version pinning, since the timing of a new snapshot's availability can differ by surface, and to the infrastructure and non-functional requirements that make deployment surface a posture decision in the first place.