Prepare for the HFCP by treating Fabric as a pipeline: applications propose, endorsing peers execute, orderers sequence, and all peers validate and commit. Every topic in the exam domains — architecture, chaincode, identity, consensus, private data, and maintenance — becomes clearer when you can place it in that pipeline and name which component owns the decision.
Why execute-order-validate shapes every Fabric question
Fabric uses an execute-order-validate architecture: contracts run before ordering, and peers validate afterward. Questions about transactions hinge on which phase performs endorsement, ordering, and validation, so separating those three phases is the first study habit to build.
Trace the flow concretely. An application sends a transaction proposal to endorsing peers. Each endorser executes the chaincode locally and returns a signed read-write set — the keys it read, the versions it read, and the values it would write. The application collects these endorsements and submits them to an ordering service, which sequences transactions into blocks. Every peer in the channel then receives the block and validates each transaction twice: against the endorsement policy and against key versions. Only validated transactions are written to the ledger.
This differs from chains that order first and execute after. Here is a scenario to internalize: two applications endorse transactions that both read the same key at version 7 and write different values. Both pass endorsement, both get ordered, and the first commits. The second fails validation with an MVCC read conflict because the key version moved. The underlying concept is that endorsement success does not guarantee commit, because validity is decided only on the committing peer during the validation phase. The better decision is designing keys to avoid hot contention and handling conflicts with application-level retries, because read sets pin versions at execution time, not at commit time.
Endorsement policies: who runs the code versus who approves the result
An endorsement policy states whose signatures a transaction needs, and it is evaluated at two points: when endorsing peers execute the proposal and when every committing peer validates the result. Running chaincode and satisfying the policy are separate requirements.
Policies can reference channel-level policies, such as a majority of organizations in the channel, or name specific principals. The policy is attached when a chaincode definition is approved, and it can differ from the default channel policy. Study how a change of policy ripples: if the definition requires signatures from both a buyer organization and a seller organization, every transaction must collect endorsements from peers of each before the application can even submit it for ordering.
Work this scenario. A developer tests new chaincode against a peer in her own organization and everything passes. In production, the approved definition requires endorsement from both transacting organizations, so transactions stall whenever the other organization's peers are unavailable. The mistake is validating behavior only against a single-org peer. The better decision is exercising cross-org endorsement — ideally with each organization running its own peer in a test network — before fixing the policy in a definition. It matters because the policy couples your transaction availability to another organization's infrastructure, a trade you should make deliberately rather than inherit.
MSP and Fabric CA: identity issuance is not authorization
A certificate authority issues X.509 identities; the Membership Service Provider (MSP) declares which CAs an organization trusts and what roles certificates carry. Authorization in a channel flows from MSP configuration, never from the act of issuing a certificate.
Keep the two concepts cleanly separate when you study. The Fabric CA is a service that enrolls identities and issues certificates. An MSP is configuration — a named set of trusted CA certificates, administrator certificates, and organizational unit settings — that peers, orderers, and channel configuration reference. A freshly issued certificate is functionally inert until the CA that signed it appears in an MSP that the channel trusts. Node organizational units classify a certificate as belonging to a client, peer, admin, or orderer, which is how the same CA can feed several distinct roles.
Practice by tracing authority in a configuration. Take a peer enrolled through the Organization 1 CA and answer two questions from the config alone: which MSP does the peer claim, and does its certificate carry the peer role? Membership under Org1's MSP lets it act as a peer; administrative operations on network resources require a certificate with the admin role under the relevant MSP. Your self-check is being able to point to the exact place — the MSP definition in channel configuration or node configuration — where each identity's authority is decided. If you can only explain the CA side, you have half the model.
Chaincode lifecycle: what changes between package, approve, and commit
In the Fabric 2.x lifecycle, chaincode is packaged, installed on peers, approved per organization, and committed to a channel as a definition. Each step has a distinct owner and failure mode, and the legacy install-and-instantiate flow still surfaces in older material.
Walk the steps in order and note who performs each. Packaging bundles source and metadata. Installation places the package on a specific peer's filesystem. Approval records an organization's agreement to a definition — name, version, sequence number, endorsement policy, collection configuration — and checkcommitreadiness shows which organizations still need to approve. Commit finalizes the definition on the channel, after which the chaincode can be invoked. For upgrades, the definition's sequence number increments while the version and code change together.
Consider a realistic failure. A team ships revised chaincode, one organization approves a definition with the new sequence number while another approves with the old one, and the commit call keeps failing because definitions do not match across organizations. The mistake is treating approval as per-team bookkeeping rather than a channel-wide agreement with a shared sequence. The better decision is tracking the current sequence number and each organization's approval status explicitly, checking readiness before committing. It matters because a mismatch blocks the commit entirely — the channel simply has no single agreed definition to activate.
Also distinguish the legacy lifecycle. Older environments use install plus instantiate (or upgrade) through system chaincode, and documentation and tooling from that era still appear in the wild. Knowing that the terms describe an earlier flow — and mapping instantiate to the modern approve-and-commit pair — prevents you from misreading instructions written for a different Fabric generation.
- Package: bundles chaincode source; owned by the developer, no network effect yet.
- Install: copies the package onto a specific peer; scoped to that node only.
- Approveformyorg: the organization signs off on a definition including name, version, sequence, and policy.
- Commit: activates the definition on the channel once required approvals match.
- Upgrade: re-run the flow with an incremented sequence number and the new code.
Channels versus private data collections: matching confinement to the need
A channel gives a subset of organizations its own complete ledger; a private data collection keeps endorsed data off the channel ledger and distributes it only to authorized peers, which store a hash of it publicly. Choose per data set, not per organization pair.
Collections are defined in chaincode and list which organizations' peers receive the private data, optionally with a collection-level endorsement policy. Authorized peers store the raw private data in a side database and publish only a hash to the channel ledger, so non-member organizations can verify that data existed at a given version without seeing it. Channels, by contrast, carry everything: their own ledger, their own governance, and their own participation set.
Now the scenario. A consortium builds a new channel for every supplier relationship because pricing data must stay confidential. Each channel multiplies governance, configuration, and ordering overhead, and shared business logic gets duplicated per channel. The mistake is reaching for a channel to solve a single-data-set problem. The better decision is one shared channel plus a private data collection scoped to the relevant organizations, reserving new channels for cases where an entire workload — participants, endorsement rules, and lifecycle — genuinely differs. It matters because the two tools differ in operational cost and in what non-members can verify, so the choice shapes the network for years.
Use the table below as a decision drill: for each confidential-data requirement you encounter in practice questions, decide which row characteristics matter and justify a channel or a collection before checking the answer.
| Decision question | New channel | Private data collection |
|---|---|---|
| Who sees the raw data? | Only the channel's member organizations | Only peers of organizations listed in the collection |
| What do non-members see? | Nothing; they are not on the channel | A hash of the private data on the channel ledger |
| What scope does it confine? | An entire ledger and its governance | One data set defined in chaincode |
| Endorsement control | Channel and chaincode definition policies | Collection-level policy can differ per data set |
| Operational footprint | Separate configuration and ordering per channel | No new channel; configuration lives with the chaincode |
| Best fit | A whole workload with distinct participants or rules | Confidential subsets inside a broader shared workflow |
Ordering services: what consensus decides and what it never decides
Ordering nodes reach consensus on the order of transactions and cut blocks; they do not execute chaincode or determine validity. Validity checks belong to peers, so a transaction that an orderer has sequenced can still be marked invalid at commit.
Study the two service families by their fault model. Raft-based ordering is crash fault tolerant: nodes elect a leader and replicate an ordered log, tolerating node failures. Byzantine fault tolerant ordering options in later Fabric releases additionally tolerate faulty or malicious nodes. Both families produce the same artifact — an ordered stream of blocks — which peers receive and distribute among themselves using gossip. Neither family inspects transaction content for business validity; the endorsement and MVCC checks happen on the committing side.
Use this separation to audit practice scenarios. If a question says an orderer has received and sequenced a transaction, do not infer it committed — peers may reject it during validation. If a question describes configuration updates or chaincode definitions, remember those also flow through ordering like any other transaction. When reading about deployment design, note that spreading ordering nodes across organizations and regions improves resilience of the ordering service itself, which is a different concern from peer availability or endorsement policy satisfaction. Keeping the ordering/validating split explicit in your notes turns vague network diagrams into testable claims.
A practice sequence and readiness rubric you can adapt
Build readiness around reconstructing flows from memory and auditing your own work, then verify details against official documentation. End each study cycle by explaining a component's role in one sentence without notes — that is the skill the scenarios above depend on.
An adaptable sequence grounded in the exam domains: First, draw a full network diagram — organizations, peers, orderers, CAs, and one channel — and annotate which MSP each component trusts. Second, run the chaincode lifecycle end to end on a local test network, recording the definition's name, version, sequence, and policy at each step. Third, work decision drills: pick channel versus private data collection for three different data sets, choose an endorsement policy for a two-party workflow, and diagnose a deliberately planted MVCC conflict. Repeat any cycle that feels shaky rather than moving on.
Score your own output against this rubric, treating it as a learning milestone rather than a prediction of any exam score: your transaction-flow diagram places endorsement before ordering and after execution; it shows every channel peer validating blocks, not just endorsers; it distinguishes private data storage from the public hash; your identity trace names the MSP that grants each role; your upgrade walkthrough tracks the sequence number and per-organization approvals; and your ordering notes state what orderers never do. Concrete readiness checks before you finish: explain execute-order-validate in three sentences, state who must approve a chaincode definition and at which step, and describe the exact failure mode when two transactions contend on one key version.
One administrative note: for scheduling, availability, and current exam policies, rely on the issuer's own site rather than third-party summaries, since those details change independently of the syllabus.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.