Question #1
An enterprise blockchain is a permission blockchain node distributed to whom?
- A . Administration data center
- B . Nodes distributed with a validator
- C . Member organizations
- D . Nodes distributed on a public Blockchain
Correct Answer: C
C
Explanation:
In Hyperledger Fabric, the enterprise blockchain is a permissioned network where nodes are distributed among the member organizations that participate in the blockchain network. This is in contrast to a public blockchain where anyone can participate anonymously. In a permissioned blockchain like Hyperledger Fabric, the participants are known entities within a business network, such as enterprises or organizations, that have specific permissions and roles within the network. This setup enhances security and trust as each participant is vetted and authorized to take part in the network operations. The architecture of Hyperledger Fabric is designed to support such a governance model, where multiple organizations can interact in a secure and regulated environment, maintaining their own ledgers but sharing data that require consensus across known entities.
C
Explanation:
In Hyperledger Fabric, the enterprise blockchain is a permissioned network where nodes are distributed among the member organizations that participate in the blockchain network. This is in contrast to a public blockchain where anyone can participate anonymously. In a permissioned blockchain like Hyperledger Fabric, the participants are known entities within a business network, such as enterprises or organizations, that have specific permissions and roles within the network. This setup enhances security and trust as each participant is vetted and authorized to take part in the network operations. The architecture of Hyperledger Fabric is designed to support such a governance model, where multiple organizations can interact in a secure and regulated environment, maintaining their own ledgers but sharing data that require consensus across known entities.
Question #2
An endorsement policy lists what?
- A . The number of organizations involved in a transaction.
- B . The number of peers needed to endorse a transaction.
- C . The order in which transactions are executed.
- D . The identities required for endorsing a transaction.
Correct Answer: D
D
Explanation:
In Hyperledger Fabric, an endorsement policy specifies which network participants, identified by their digital identities, must endorse a transaction before it can be considered valid. This is crucial for the network’s security and integrity, as it controls how transactions are approved and added to the ledger. Endorsement policies are part of the channel configuration and can be customized to fit the specific needs of a business network. They dictate the necessary endorsements from specific organizations or even particular roles within those organizations, ensuring that only authorized entities can validate transactions. This mechanism supports the collaborative yet secure nature of the enterprise blockchain, where trust is decentralized across different organizations that are part of the network.
D
Explanation:
In Hyperledger Fabric, an endorsement policy specifies which network participants, identified by their digital identities, must endorse a transaction before it can be considered valid. This is crucial for the network’s security and integrity, as it controls how transactions are approved and added to the ledger. Endorsement policies are part of the channel configuration and can be customized to fit the specific needs of a business network. They dictate the necessary endorsements from specific organizations or even particular roles within those organizations, ensuring that only authorized entities can validate transactions. This mechanism supports the collaborative yet secure nature of the enterprise blockchain, where trust is decentralized across different organizations that are part of the network.
Question #3
A smart contract can call other smart contracts both within the same channel and across different channels .
Which of the following transactions is inter-contract communication whose functionality is limited?
- A . Chaincode X calls Getstate in Chaincode Y on the same channel.
- B . Chaincode X calls Putstate in Chaincode Y on the same channel.
- C . Chaincode X calls Getstate in Chaincode Y on a different channel.
- D . Chaincode X calls Putstate in Chaincode Y on a different channel.
Correct Answer: D
D
Explanation:
In Hyperledger Fabric, inter-contract communication is possible both within the same channel and across different channels. However, the functionality to alter the state (using PutState) of a chaincode on a different channel is restricted. This limitation is due to the security and isolation principles of channels in Hyperledger Fabric, where each channel represents a separate ledger and state. Transactions within a channel can read and write data freely, subject to endorsement policies, but writing data to another channel’s chaincode directly is not permitted. This prevents unauthorized influence on a separate and potentially isolated business process, ensuring that operations within a channel are controlled and secure.
D
Explanation:
In Hyperledger Fabric, inter-contract communication is possible both within the same channel and across different channels. However, the functionality to alter the state (using PutState) of a chaincode on a different channel is restricted. This limitation is due to the security and isolation principles of channels in Hyperledger Fabric, where each channel represents a separate ledger and state. Transactions within a channel can read and write data freely, subject to endorsement policies, but writing data to another channel’s chaincode directly is not permitted. This prevents unauthorized influence on a separate and potentially isolated business process, ensuring that operations within a channel are controlled and secure.
Question #4
When building a test network, how many nodes are adequate for an Ordering Service?
- A . There is no set number of nodes required for an Ordering Service.
- B . Three ordering nodes are needed for a test Ordering Service.
- C . One ordering nodes is sufficient for an Ordering Service.
- D . Ordering Service nodes are optional in a test network.
Correct Answer: C
C
Explanation:
For a test network in Hyperledger Fabric, one ordering node is sufficient to form an Ordering Service7. The test network typically uses a single-node Raft ordering service for simplicity and educational purposes.However, for production networks, a multi-node ordering service is recommended for fault tolerance and high availability8.
C
Explanation:
For a test network in Hyperledger Fabric, one ordering node is sufficient to form an Ordering Service7. The test network typically uses a single-node Raft ordering service for simplicity and educational purposes.However, for production networks, a multi-node ordering service is recommended for fault tolerance and high availability8.
Question #5
Regarding peer lifecycle chaincode, which of the following is the incorrect (unsupported) subcommand for query?
- A . peer lifecycle chaincode querypackaged
- B . peer lifecycle chaincode querycommitted
- C . peer lifecycle chaincode queryapproved
- D . peer lifecycle chaincode queryinstalled
Correct Answer: A
A
Explanation:
The correct subcommands for querying in the peer lifecycle chaincode are queryinstalled, queryapproved, checkcommitreadiness, commit, and querycommitted 1. The subcommand querypackaged is not a supported subcommand for querying in the peer lifecycle chaincode.
A
Explanation:
The correct subcommands for querying in the peer lifecycle chaincode are queryinstalled, queryapproved, checkcommitreadiness, commit, and querycommitted 1. The subcommand querypackaged is not a supported subcommand for querying in the peer lifecycle chaincode.
Question #6
When deploying an Orderer environment, variables must be customized or overridden in which artifact?
- A . crypto-config.yaml
- B . docker-compose.yaml
- C . configtx.yaml
- D . orderer.yaml
Correct Answer: D
D
Explanation:
When deploying an Orderer environment in Hyperledger Fabric, the primary configuration file that must be customized or overridden is orderer.yaml. This file contains the configuration settings specifically for the orderer node, including general ledger type, consensus type, and various operational settings like batching, timeouts, and MSP configurations. Other files like crypto-config.yaml, docker-compose.yaml, and configtx.yaml serve different roles. crypto-config.yaml is used for generating cryptographic material, docker-compose.yaml for defining services, networks, and volumes for containers, and configtx.yaml for channel configuration and consortium definitions. Therefore, orderer.yaml is critical for setting up the orderer’s behavior and parameters in the network environment.
D
Explanation:
When deploying an Orderer environment in Hyperledger Fabric, the primary configuration file that must be customized or overridden is orderer.yaml. This file contains the configuration settings specifically for the orderer node, including general ledger type, consensus type, and various operational settings like batching, timeouts, and MSP configurations. Other files like crypto-config.yaml, docker-compose.yaml, and configtx.yaml serve different roles. crypto-config.yaml is used for generating cryptographic material, docker-compose.yaml for defining services, networks, and volumes for containers, and configtx.yaml for channel configuration and consortium definitions. Therefore, orderer.yaml is critical for setting up the orderer’s behavior and parameters in the network environment.
Question #7
Which subcommand adds a peer to a channel in Hyperledger Fabric?
- A . peer channel fetch
- B . peer channel creace
- C . peer channel updace
- D . peer channel join
Correct Answer: D
D
Explanation:
In Hyperledger Fabric, the correct subcommand to add a peer to a channel is peer channel join. This command is used by a peer node to join an existing channel. The command requires a block to be specified which typically is the genesis block of the channel, allowing the peer to synchronize with the channel’s ledger from the beginning. Other commands like peer channel fetch, peer channel create, and peer channel update serve different purposes. peer channel fetch retrieves blocks from a channel, peer channel create is used to set up a new channel, and peer channel update modifies channel settings. Thus, peer channel join is the specific command used to connect a peer to a channel.
D
Explanation:
In Hyperledger Fabric, the correct subcommand to add a peer to a channel is peer channel join. This command is used by a peer node to join an existing channel. The command requires a block to be specified which typically is the genesis block of the channel, allowing the peer to synchronize with the channel’s ledger from the beginning. Other commands like peer channel fetch, peer channel create, and peer channel update serve different purposes. peer channel fetch retrieves blocks from a channel, peer channel create is used to set up a new channel, and peer channel update modifies channel settings. Thus, peer channel join is the specific command used to connect a peer to a channel.
Question #8
After the transaction that contains the delState("A") function is committed, what happens to the ledger and state database?
- A . getstate("A") function returns the current state of the key "A".
- B . The deleting transaction sets an empty value to the key "A" in the write set.
- C . The state of the key "A" is removed from the state database, but its history remains in the ledger.
- D . All transaction histories which updated the state "A" are deleted from the ledger.
Correct Answer: C
C
Explanation:
In Hyperledger Fabric, when a transaction that includes the delState("A") function is committed, it results in the removal of the state of the key "A" from the current state database. However, the history of all transactions that have affected the key "A" remains intact in the ledger. This operation ensures that while the current state reflects the deletion, the immutability and traceability of the ledger are preserved, allowing for auditability and verification of past states. Options such as setting an empty value to the key or altering the transaction history are not supported, as they would violate the principles of immutability and transparency central to blockchain technology. Therefore, the correct outcome of a delState("A") operation is that the current state of "A" is deleted, but its transaction history remains accessible in the ledger.
C
Explanation:
In Hyperledger Fabric, when a transaction that includes the delState("A") function is committed, it results in the removal of the state of the key "A" from the current state database. However, the history of all transactions that have affected the key "A" remains intact in the ledger. This operation ensures that while the current state reflects the deletion, the immutability and traceability of the ledger are preserved, allowing for auditability and verification of past states. Options such as setting an empty value to the key or altering the transaction history are not supported, as they would violate the principles of immutability and transparency central to blockchain technology. Therefore, the correct outcome of a delState("A") operation is that the current state of "A" is deleted, but its transaction history remains accessible in the ledger.
Question #9
How would a developer iteratively test and develop a smart contract without the overhead of the smart contract lifecycle process for every update?
- A . Running chaincode for Smart Contracts in development mode.
- B . Manually update the Smart Contract code on the network.
- C . Deploy the Smart Contract on the network for every update.
- D . Use a Production Network to test and develop Smart Contracts.
Correct Answer: A
A
Explanation:
For developers looking to iteratively test and develop smart contracts in Hyperledger Fabric without the overhead of the full lifecycle process for each update, the recommended approach is to run the chaincode in development mode. This mode allows developers to test and debug chaincode directly on their machines without having to package, install, approve, and commit changes on the network each time. Development mode simplifies the iterative development process by allowing direct interaction with the chaincode during its development, making it easier to make and test changes quickly and efficiently. This contrasts with other methods that involve manual updates, redeployments, or using a production network, all of which are more time-consuming and complex.
A
Explanation:
For developers looking to iteratively test and develop smart contracts in Hyperledger Fabric without the overhead of the full lifecycle process for each update, the recommended approach is to run the chaincode in development mode. This mode allows developers to test and debug chaincode directly on their machines without having to package, install, approve, and commit changes on the network each time. Development mode simplifies the iterative development process by allowing direct interaction with the chaincode during its development, making it easier to make and test changes quickly and efficiently. This contrasts with other methods that involve manual updates, redeployments, or using a production network, all of which are more time-consuming and complex.
Question #10
Which of the following information do signature policies provide when creating a network in Hyperledger Fabric?
- A . Identity specific users who must sign in order to satisfy a policy.
B Number of nodes in the network - B . Private keys of all network participants.
- C . Type of consensus algorithm used
Correct Answer: A
A
Explanation:
In Hyperledger Fabric, signature policies specify the identities of specific users who must sign a transaction for it to be considered valid. These policies define the endorsement rules associated with a chaincode and are a critical component of the transaction flow. They ensure that transactions are endorsed by the correct entities as stipulated by the governance of the network. Signature policies are not related to the number of nodes, private keys of participants, or the type of consensus algorithm used but are strictly about defining which users or member organizations’ signatures are required to fulfill transaction criteria.
A
Explanation:
In Hyperledger Fabric, signature policies specify the identities of specific users who must sign a transaction for it to be considered valid. These policies define the endorsement rules associated with a chaincode and are a critical component of the transaction flow. They ensure that transactions are endorsed by the correct entities as stipulated by the governance of the network. Signature policies are not related to the number of nodes, private keys of participants, or the type of consensus algorithm used but are strictly about defining which users or member organizations’ signatures are required to fulfill transaction criteria.
1 1. What is true about the historic states in Hyperledger Fabric model?
Question #11
In Hyperledger Fabric, Intercommunication is how a smart contract in a channel updates the World State database. It is achieved by what process?
- A . Setting the endorsement policy to communicate with all peers.
- B . Configuring the Peer-to-peer endorsement options.
- C . Calling smart contracts within the channel and in different channels.
- D . Making use of the cross channel Consensus mechanism.
Correct Answer: C
C
Explanation:
Intercommunication in Hyperledger Fabric regarding how smart contracts update the World State database is primarily achieved by calling other smart contracts, both within the same channel and across different channels. This process allows smart contracts, also known as chaincode, to interact and transact across the network, updating the World State as necessary based on business logic defined in the contracts. This capability is crucial for complex business processes that span multiple contracts and possibly multiple channels. Unlike setting endorsement policies or configuring peer-to-peer options, calling other smart contracts directly facilitates dynamic and direct interaction between business processes, enhancing the modularity and efficiency of the network. Cross-channel communication must be carefully managed within the permissions and policies defined in the network to maintain security and integrity.
C
Explanation:
Intercommunication in Hyperledger Fabric regarding how smart contracts update the World State database is primarily achieved by calling other smart contracts, both within the same channel and across different channels. This process allows smart contracts, also known as chaincode, to interact and transact across the network, updating the World State as necessary based on business logic defined in the contracts. This capability is crucial for complex business processes that span multiple contracts and possibly multiple channels. Unlike setting endorsement policies or configuring peer-to-peer options, calling other smart contracts directly facilitates dynamic and direct interaction between business processes, enhancing the modularity and efficiency of the network. Cross-channel communication must be carefully managed within the permissions and policies defined in the network to maintain security and integrity.
Question #12
What types of events committed to the ledger can client applications receive using the peer’s event service?
- A . Only block events
- B . Both chaincode and block events
- C . Neither chaincode nor block events
- D . Only chaincode events
Correct Answer: B
B
Explanation:
In Hyperledger Fabric, client applications can subscribe to receive both chaincode events and block events using the peer’s event service. Chaincode events are generated by the chaincode itself, typically based on specific conditions coded within the chaincode operations, and are used to notify applications of specific state changes or significant occurrences. Block events inform about the addition of new blocks to the ledger, which may contain multiple transactions. This dual capability allows client applications to effectively monitor transaction confirmations and specific chaincode outputs in real time, which is critical for applications that rely on up-to-date blockchain data for processing decisions.
B
Explanation:
In Hyperledger Fabric, client applications can subscribe to receive both chaincode events and block events using the peer’s event service. Chaincode events are generated by the chaincode itself, typically based on specific conditions coded within the chaincode operations, and are used to notify applications of specific state changes or significant occurrences. Block events inform about the addition of new blocks to the ledger, which may contain multiple transactions. This dual capability allows client applications to effectively monitor transaction confirmations and specific chaincode outputs in real time, which is critical for applications that rely on up-to-date blockchain data for processing decisions.
Question #13
Which of the following is the correct role of orderer nodes?
- A . Order and package endorsed transactions into a block.
- B . Order new tokens from the token issuer.
- C . Order peers to endorse a transaction.
- D . Reorder stored blocks to compress data volume.
Correct Answer: A
A
Explanation:
The primary role of orderer nodes in Hyperledger Fabric is to order and package endorsed transactions into blocks. Orderers receive transactions from various peers, ensure that these transactions are in a consistent order, and then package them into blocks that are subsequently appended to the blockchain. This function is crucial for maintaining the consistency and integrity of the ledger across all participating nodes. Orderer nodes do not issue tokens, enforce peer endorsements, or reorder stored blocks for data compression. Instead, their main function is integral to the consensus and ledger maintenance processes within a Hyperledger Fabric network
A
Explanation:
The primary role of orderer nodes in Hyperledger Fabric is to order and package endorsed transactions into blocks. Orderers receive transactions from various peers, ensure that these transactions are in a consistent order, and then package them into blocks that are subsequently appended to the blockchain. This function is crucial for maintaining the consistency and integrity of the ledger across all participating nodes. Orderer nodes do not issue tokens, enforce peer endorsements, or reorder stored blocks for data compression. Instead, their main function is integral to the consensus and ledger maintenance processes within a Hyperledger Fabric network
Question #14
What gRPC status code might you expect to be associated with an error invoking a transaction as a result of a transient failure, such as a network disconnection between the client application and Gateway peer?
- A . UNAVAILABLE
- B . ABORTED
- C . DEADLINE EXCEEDED
- D . FAILED PRECONDITION
Correct Answer: A
A
Explanation:
The gRPC status code "UNAVAILABLE" is commonly expected in scenarios involving transient failures in network communication, such as a disconnection between the client application and the Gateway peer. This status code indicates that the service is currently unavailable, often due to network issues or service downtime, making it suitable for situations where the failure is temporary and the request can be retried. This differs from other codes like "ABORTED" or "DEADLINE EXCEEDED," which represent different types of errors related to the transaction logic or timing issues, respectively. "FAILED PRECONDITION" would be inappropriate for network disconnections as it suggests issues
with the request’s preconditions, not the network status.
A
Explanation:
The gRPC status code "UNAVAILABLE" is commonly expected in scenarios involving transient failures in network communication, such as a disconnection between the client application and the Gateway peer. This status code indicates that the service is currently unavailable, often due to network issues or service downtime, making it suitable for situations where the failure is temporary and the request can be retried. This differs from other codes like "ABORTED" or "DEADLINE EXCEEDED," which represent different types of errors related to the transaction logic or timing issues, respectively. "FAILED PRECONDITION" would be inappropriate for network disconnections as it suggests issues
with the request’s preconditions, not the network status.
Question #15
In a production environment, what peer items require on-going monitoring?
- A . Only the orderer service since it manages the ordering of transactions.
- B . Only the chaincode containers since they handle the business logic.
- C . All peer containers, including their CPU, network, and memory.
- D . Only the peer nodes that are running chaincode, since they consume most resources.
Correct Answer: C
C
Explanation:
In a production environment of Hyperledger Fabric, it is essential to monitor all peer containers comprehensively, including their CPU, network, and memory usage. This is because each peer node plays a critical role in maintaining the network’s overall health and efficiency. Monitoring these resources helps in detecting potential bottlenecks or failures early, ensuring the smooth operation of the blockchain network. Focusing only on specific components like the orderer service or chaincode containers would provide a limited view of the network’s health and could lead to issues being overlooked. Comprehensive monitoring enables administrators to maintain optimal performance and reliability across the entire network.
C
Explanation:
In a production environment of Hyperledger Fabric, it is essential to monitor all peer containers comprehensively, including their CPU, network, and memory usage. This is because each peer node plays a critical role in maintaining the network’s overall health and efficiency. Monitoring these resources helps in detecting potential bottlenecks or failures early, ensuring the smooth operation of the blockchain network. Focusing only on specific components like the orderer service or chaincode containers would provide a limited view of the network’s health and could lead to issues being overlooked. Comprehensive monitoring enables administrators to maintain optimal performance and reliability across the entire network.
Question #16
What do we call the ordering nodes actively participating in the consensus mechanism for a given channel and receiving replicated logs for the channel?
- A . Committer set
- B . Consenter set
- C . Peers
- D . Endorsers
Correct Answer: B
B
Explanation:
In Hyperledger Fabric, the ordering nodes that are actively participating in the consensus mechanism for a given channel are referred to as the "Consenter set." These nodes are part of the ordering service and are responsible for creating blocks by ordering transactions and ensuring consistency across the network. The Consenter set receives the transaction logs that need to be replicated across other orderers and peers in the network. This is distinct from the "Committer set," which comprises nodes that commit blocks to their ledger, and "Endorsers," which are responsible for endorsing transactions by checking them against the chaincode execution policies.
B
Explanation:
In Hyperledger Fabric, the ordering nodes that are actively participating in the consensus mechanism for a given channel are referred to as the "Consenter set." These nodes are part of the ordering service and are responsible for creating blocks by ordering transactions and ensuring consistency across the network. The Consenter set receives the transaction logs that need to be replicated across other orderers and peers in the network. This is distinct from the "Committer set," which comprises nodes that commit blocks to their ledger, and "Endorsers," which are responsible for endorsing transactions by checking them against the chaincode execution policies.
Question #17
Which of the following is the identity solution in Hyperledger Fabric?
- A . Hyperledger Fabric Orderer
- B . Hyperledger Fabric CA
- C . Hyperledger Fabric SDK
- D . Membership Service Providers
Correct Answer: D
D
Explanation:
In Hyperledger Fabric, the identity solution that manages user identities and authenticates participants on the network is facilitated by Membership Service Providers (MSPs). MSPs are crucial for defining the rules by which identities are validated, authenticated, and allowed access to the network. MSPs handle the issuance of certificates and define the roles and permissions associated with participant identities, enabling permissioned interactions on the blockchain. This differs from Hyperledger Fabric CA, which primarily issues and revokes certificates as part of identity management but is used in conjunction with MSPs to provide comprehensive identity solutions within the network.
D
Explanation:
In Hyperledger Fabric, the identity solution that manages user identities and authenticates participants on the network is facilitated by Membership Service Providers (MSPs). MSPs are crucial for defining the rules by which identities are validated, authenticated, and allowed access to the network. MSPs handle the issuance of certificates and define the roles and permissions associated with participant identities, enabling permissioned interactions on the blockchain. This differs from Hyperledger Fabric CA, which primarily issues and revokes certificates as part of identity management but is used in conjunction with MSPs to provide comprehensive identity solutions within the network.
Question #18
What is necessary for a chaincode to become ready to commit on a channel?
- A . The chaincode must be previously installed on the channel’s peers.
- B . The policy Channel/Application/Writers must be satisfied.
- C . The policy /Channel/Application/LifecycleEndorsement must be satisfied.
- D . The chaincode must have the endorsement policies correctly defined.
Correct Answer: C
C
Explanation:
For a chaincode to become ready to commit on a channel in Hyperledger Fabric, it is necessary that the policy "/Channel/Application/LifecycleEndorsement" be satisfied. This policy specifies who needs to approve the chaincode definition before it can be committed to the channel. It ensures that the chaincode deployment is endorsed according to the governance standards agreed upon by the network participants, typically requiring a majority or other specified fraction of the organizations in the network to endorse the change. This lifecycle endorsement policy is key to maintaining a secure and agreed-upon update process for chaincodes on the channel.
C
Explanation:
For a chaincode to become ready to commit on a channel in Hyperledger Fabric, it is necessary that the policy "/Channel/Application/LifecycleEndorsement" be satisfied. This policy specifies who needs to approve the chaincode definition before it can be committed to the channel. It ensures that the chaincode deployment is endorsed according to the governance standards agreed upon by the network participants, typically requiring a majority or other specified fraction of the organizations in the network to endorse the change. This lifecycle endorsement policy is key to maintaining a secure and agreed-upon update process for chaincodes on the channel.
Question #19
How can the client application access descriptive error text for each of the endorsing peers following a transaction endorsement failure?
- A . Extract relevant entries from the endorsing peer logs.
- B . Examine the message of the associated cause or wrapped error.
- C . Look up the gRPC status code for the error.
- D . Extract the details associated with the returned error.
Correct Answer: D
D
Explanation:
When a client application encounters a transaction endorsement failure in Hyperledger Fabric, the most effective way to access descriptive error text for each endorsing peer is to extract the details associated with the returned error. This error information typically includes details about why the endorsement was unsuccessful, providing insights into issues such as policy violations or execution failures. This method is more direct and informative compared to extracting logs or examining generic error messages and helps developers and administrators quickly diagnose and address issues in transaction processing.
D
Explanation:
When a client application encounters a transaction endorsement failure in Hyperledger Fabric, the most effective way to access descriptive error text for each endorsing peer is to extract the details associated with the returned error. This error information typically includes details about why the endorsement was unsuccessful, providing insights into issues such as policy violations or execution failures. This method is more direct and informative compared to extracting logs or examining generic error messages and helps developers and administrators quickly diagnose and address issues in transaction processing.