HFCP Hyperledger Fabric Certified Practitioner Exam Topics and Questions

Blockchain fundamentals set the floor for everything else on this exam. If your mental model of how a distributed ledger reaches agreement is fuzzy, you will lose marks in every later topic, not just this one. The examinable core here is the Hyperledger Fabric Model specifically: how its components relate, what smart contracts are responsible for, how consensus works in a permissioned context, and what business problems the architecture is actually designed to solve.

How Fundamentals of Blockchain is tested

At 16%, this topic contributes a meaningful slice of your score, and the items tend to be conceptual rather than procedural. You will not be asked to run commands. Instead, items place you in front of a scenario and ask you to identify which Fabric component or mechanism is responsible for a given outcome. The trap is treating Fabric as a generic blockchain: its permissioned model, its separation of endorsement from ordering, and its specific definition of a smart contract all differ from public-chain assumptions. Candidates who lean on Bitcoin or Ethereum knowledge without adjusting for Fabric's architecture consistently pick options that are plausible in a public-chain world but wrong in a Fabric context. Items also reward knowing why the Fabric model offers specific business benefits, not just that it does. Vague familiarity with distributed ledgers is not enough; you need to be precise about what Fabric's model actually guarantees and where those guarantees come from.

With fundamentals behind you, the exam's heaviest territory opens up. At 36%, Hyperledger Fabric Networks is where most candidates either build a decisive lead or bleed marks steadily across the section. The domain covers the architecture of a running Fabric network: peers, orderers, channels, membership services, policies, and how these pieces are configured and secured. The breadth is real, and gaps in any corner of the architecture tend to surface as wrong answers.

How Hyperledger Fabric Networks is tested

Because this topic carries more than a third of the exam's weight, expect a high volume of items that span the full architecture rather than drilling a single component. Items frequently describe a network state and ask what happens next, or describe a failure and ask which configuration is responsible. That framing demands you hold the whole system in mind simultaneously, not just recall isolated facts about peers or orderers in isolation.

The most common place candidates lose marks is in policy and membership: knowing that policies exist is not the same as knowing how endorsement policies interact with channel policies in a specific scenario. Similarly, channel configuration is tested at a level of precision that surprises candidates who only read overview material. Items reward being able to trace a decision through the network's components step by step. Guessing based on which answer sounds most architecturally sensible is a losing strategy here; the distractors are designed to sound reasonable to anyone who has not worked through the details.

Smart Contracts shares its 24% weight with the next topic, and together they make up nearly half the exam. Coming off the network architecture section, you now move from infrastructure into the code that runs on it. In Fabric, a smart contract is chaincode, and the exam tests not just what chaincode does but how it interacts with the ledger, what the endorsement flow looks like from the contract's perspective, and where contract logic can go wrong in ways that produce silent errors rather than obvious failures.

How Smart Contracts is tested

Items in this topic tend to be scenario-based: a chaincode function behaves unexpectedly, or a transaction reaches the orderer in a state that causes it to be invalidated, and you are asked to identify the cause. That means you need to understand the full lifecycle of a smart contract invocation, from proposal through endorsement to commit, and know at which point different classes of error are caught.

Candidates lose marks here by treating chaincode logic as ordinary application code. The determinism requirement is the sharpest edge: operations that are non-deterministic across peers produce phantom validation failures that are genuinely hard to diagnose without knowing the rule. Items reward knowing the constraints that Fabric places on what chaincode may and may not do, not just knowing how to write a basic asset transfer. The chaincode lifecycle, including package, install, approve, and commit steps, is also fair game and is tested at a level of detail that rewards having actually traced the steps rather than read a summary.

The final topic shifts from what runs inside the network to how external applications interact with it. At 24%, Client Application covers the gateway model, peer gateway service configuration, smart contract invocation from client code, chaincode and block eventing, and offline signing. Each of these is a distinct integration point, and the exam tests them at a practical level: not just that they exist, but how you wire them up correctly and what breaks when you do not.

How Clients Applicaiton is tested

Items here are the most applied on the exam. You are typically given a client-side scenario: an application is submitting transactions, listening for events, or signing payloads offline, and something about the configuration or the call sequence is wrong. You need to identify the fault or select the configuration that produces the described behaviour.

The gateway model is the conceptual anchor. Candidates who understand why the gateway abstraction exists, and what the peer gateway service is doing on their behalf, handle these items well. Those who memorised the SDK API surface without understanding the underlying flow tend to pick options that are syntactically plausible but logically wrong for the scenario.

Offline signing is a consistent source of lost marks because candidates underestimate how much the exam tests it. The flow involves multiple steps and specific sequencing; items reward knowing the order and the reason for it. Block eventing is similarly precise: the difference between which events fire, when they fire, and what data they carry matters to the items, not just the fact that eventing exists.