Free HFCP sample questions

Correct answer: 2

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.

Correct answer: ctx.GetStub().GetTransient()

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.

Correct answer: The channel configuration update that adds the organization's MSP definition to the channel has not been successfully committed, so the organization's identities do not satisfy the channel's Readers policy.

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.

Correct answer: contract.evaluateTransaction()

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.

Correct answer: False

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.

Correct answers: The sequence number in the new definition was not incremented from the previous version.; An insufficient number of organizations have approved the new chaincode definition.

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.

Correct answer: Fetch, translate, update, and sign a channel configuration update transaction using `configtxlator` and `peer channel update`.

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.

Correct answer: Configure the peer to use CouchDB as the state database and create an index on the 'owner' field.

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.

Correct answer: Persistently checkpoint the position of the last successfully processed event (its block number and transaction ID) and, on restart, resume listening from that checkpoint.

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.

Correct answer: The peer and orderer nodes (`core.yaml` and `orderer.yaml`)

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.