Hyperledger Fabric Certified Practitioner Free Sample Questions

Raft is crash fault tolerant as long as a majority of the consenters (a quorum) is available. The quorum is floor(N/2) + 1, so for N = 3 it is 2: a three-node ordering service can lose one node and keep ordering transactions, but if two nodes fail the remaining node cannot form a majority and the channel stops producing blocks.

The GetTransient() method on the chaincode stub is used to access the transient data field of a transaction proposal. Data in the transient field is passed to the chaincode but is not included in the final transaction that gets committed to the ledger, making it ideal for passing private or confidential information for processing.

The ordering service delivers a channel's blocks only to identities that satisfy the channel's read policy. In the Fabric 'Adding an Org to a Channel' tutorial, the new organization fetches block 0 only after the configuration update that adds its MSP has been committed: if the organization had not been successfully appended to the channel configuration, the ordering service would reject the request. A missing orderer TLS CA certificate (for example, no --cafile on the CLI call) causes a TLS handshake or certificate-verification failure instead of an access-denied policy error, and the state database, chaincode containers and genesis block content do not decide whether the request is authorized.

The evaluateTransaction() method is specifically designed for read-only operations (queries). It submits a proposal to a single peer, which executes the chaincode and returns the result directly to the client. This avoids the overhead of the full transaction flow involving endorsement from multiple peers and ordering, making it highly efficient for queries.

This statement is false. The core privacy mechanism of PDCs is that the private data itself is NOT sent to the ordering service. Instead, only a hash of the private data is included in the public transaction. The actual private data is transmitted peer-to-peer via the gossip protocol only between the authorized organizations.

The chaincode lifecycle requires that each new definition committed to a channel must have a sequence number that is exactly one greater than the previously committed sequence number. Failing to increment the sequence number is a common reason for commit failure.

Committing a chaincode definition requires satisfying the channel's LifecycleEndorsement policy (typically a majority of organizations). If not enough organizations have submitted an 'approveformyorg' transaction for the new definition, the 'commit' transaction will fail validation.

Anchor peers are defined in the channel configuration. To update them on a live network, an administrator must create a channel configuration update transaction. This involves fetching the latest config block, using configtxlator to convert it to JSON, modifying the anchor peer definition, converting it back to a protobuf, and submitting the signed update transaction to the channel.

CouchDB supports rich queries against the JSON data values stored in the world state. To make these queries performant and avoid full database scans, a corresponding index must be created for the fields being queried (in this case, the 'owner' field). The chaincode can then use a GetQueryResult call with a selector to efficiently find all assets for that owner.

This is event checkpointing. The Fabric Gateway client API does not reconnect automatically: after a failure the application must start a new eventing session at the correct start position. A checkpointer (for example checkpointers.file(path)) persists the block number and the last processed transaction ID within that block; passing it as the checkpoint option to getChaincodeEvents() resumes eventing just after the last processed event, with no missed or duplicated events. There is no replay=true option, and neither evaluateTransaction nor a peer buffer setting can recover missed events.

The operations service, which exposes a REST API for health checks and a /metrics endpoint for Prometheus, must be enabled and configured on the components you wish to monitor. This is done within the operations section of the core.yaml file for peers and the orderer.yaml file for orderers.