Huawei Certified ICT Expert - Datacom — Free Practice Questions
10 free sample questions from a bank of 215, with the correct answers and explanations. No signup required — start practising right now.
- True
- False
The short version
A — TLS encryption is required for gRPC-based telemetry pushes. The statement correctly pairs the gRPC transport with mandatory TLS configuration.
Key concepts in this question
- Model-driven telemetry: devices push sampled data to collectors continuously.
- gRPC transport: the dial-out channel carrying telemetry payloads.
- TLS role: encrypts the gRPC session between device and collector.
- True-or-false reading: the claim only asserts the encryption requirement, which holds.
Why A is correct
Huawei telemetry can push over several protocols, but when the push is based on gRPC, the session must be secured with TLS so data stays confidential in transit. Configuring TLS for the device-to-collector channel is therefore the documented prerequisite for gRPC telemetry. The statement says exactly that, so True is correct.
Why the others are wrong
- B. False would deny a genuine security requirement and leave gRPC telemetry unencrypted, contradicting the push-model behavior.
H12-891 exam tip
Memory hook: see gRPC telemetry and think TLS first — encryption rides with the transport.
- True
- False
The short version
B — false: 6VPE demands VPN instances. Only 6PE rides instance-free; 6VPE is MPLS-VPN based.
Key concepts in this question
- 6PE scope: IPv6 over MPLS core, no customer VRFs.
- 6VPE scope: IPv6 VPN services requiring per-customer instances.
- Blanket claim: one rule cannot cover both models.
Why B is correct
6VPE requires VPN instances, so the no-instance claim is false (banked key refuted by model definitions: FLIP A to B).
Why the others are wrong
- A. True would free 6VPE of the instances it is built on.
H12-891 exam tip
6PE is instance-free; 6VPE is instance-based. Never merge the models.
- True
- False
The short version
A — The domain ID defaults to the process ID. It can then be changed with the domain-id command, exactly as stated.
Key concepts in this question
- OSPF process ID: the local instance number in the VRP configuration.
- Domain ID: tags VPN OSPF routes so PEs can judge same-domain membership.
- Default coupling: without configuration, domain ID equals process ID.
- domain-id command: run in the OSPF process view to override the default.
Why A is correct
On Huawei PEs, a BGP/MPLS VPN OSPF process derives its domain ID from the process ID unless configured otherwise, which keeps same-site routes comparable across the VPN. The domain-id command in the OSPF process view explicitly resets that value when domains must differ or merge. Both halves of the statement match VRP behavior, so True is correct.
Why the others are wrong
- B. False would reject either the documented default or the override command, but both behaviors are standard VRP operation.
H12-891 exam tip
Memory hook: no domain-id command means domain equals process — one line changes it.
- True
- False
The short version
B — The tenant math is wrong. A 24-bit VNI yields about 16 million values, not 12 million tenants.
Key concepts in this question
- VNI length: 24 bits in the VXLAN header identify the segment.
- Address space: 2 to the 24th power equals 16,777,216 values.
- Tenant mapping: one tenant may hold several VNIs, so tenants never exceed the VNI count.
- False trigger: the accurate 24-bit premise is paired with a wrong “12 million” total.
Why B is correct
The statement gets the VNI width and multi-VNI tenancy right but misstates the capacity. Two to the power of 24 is 16,777,216, commonly cited as about 16 million segments — far above 12 million. Since the headline number is factually wrong, the whole statement is false and B is correct.
Why the others are wrong
- A. True would endorse the 12-million figure, which understates the real 24-bit space by nearly a third.
H12-891 exam tip
Memory hook: 24 bits means 16 million — any “12 million VXLAN” number is automatically false.
- aes256-ctr
- aes192-ctr
- aes128-ctr
- aes256-cbc
The short version
C — The negotiated cipher is aes128-ctr. It is the first algorithm on the client list that the server also supports.
Key concepts in this question
- Algorithm lists: each side advertises supported ciphers in preference order.
- Client-first rule: the server selects the earliest client entry it can support.
- Common set: all four ciphers overlap, but only the negotiated one is used.
- CTR preference: the client ranks aes128-ctr at the top of its list.
Why C is correct
The client offers aes128-ctr first, then aes192-ctr, aes256-ctr, and aes256-cbc. The server supports every one of those, so negotiation stops at the client’s top choice: aes128-ctr. Option C names that cipher, making it the correct negotiated result.
Why the others are wrong
- A. aes256-ctr is common but sits third on the client list, so it loses to earlier matches.
- B. aes192-ctr is common but second on the client list, losing to aes128-ctr.
- D. aes256-cbc is common but last on both lists and never wins negotiation.
H12-891 exam tip
Memory hook: walk the client list top-down and stop at the first cipher the server also has.
- 2032
- 2024
- 2046
- No label
The short version
C — The R2-to-R4 wire carries label 2046. Each adjacency SID is popped before crossing its link, exposing the next segment.
Key concepts in this question
- Segment stack: R1 pushes 2013, 2032, 2024, 2046 for the steered path.
- Adjacency SID: popped by the node forwarding across that adjacency.
- Path trace: R1 to R3 to R2 to R4 to R6 in that segment order.
- Wire label: whatever sits on top after the local SID is popped.
Why C is correct
The encoded path is R1→R3 (2013), R3→R2 (2032), R2→R4 (2024), R4→R6 (2046). R3 pops 2032 handing to R2, so R2 receives top label 2024. R2 then pops its own adjacency SID 2024 before sending toward R4, exposing 2046 on the wire. Option C (2046) is therefore the label carried from R2 to R4.
Why the others are wrong
- A. 2032 is the R3-to-R2 adjacency SID, already popped before R2 forwards.
- B. 2024 is R2’s own adjacency SID, popped by R2 rather than sent.
- D. The packet remains label-switched here; a “no label” outcome would need PHP at R2, which the stack shows has not happened.
H12-891 exam tip
Memory hook: the adjacency SID never crosses its own link — the wire always shows the next one.
- To prevent loops.
- To prevent sub-optimal routes.
- To prevent memory insufficiency caused by receiving too many routes on RRs.
- To prevent memory insufficiency caused by receiving too many routes on clients.
The short version
C — Identical cluster IDs spare the RRs duplicate paths. Each RR discards the sibling’s reflection instead of storing and re-advertising it.
Key concepts in this question
- Redundant RRs: two reflectors back each other for reliability.
- Cluster-ID: the loop-avoidance tag attached to reflected routes.
- Same-cluster discard: a reflector drops any update carrying its own Cluster-ID.
- Memory effect: fewer stored duplicate paths on the RR control plane.
Why C is correct
With the same Cluster-ID, a route reflected by RR1 arrives at RR2 tagged with RR2’s own cluster value, so RR2 discards it rather than installing and reflecting it onward (and vice versa). That single design choice halves the reflected state each RR must hold for the same client prefixes. Option C describes that RR-side memory saving, so it is the intended answer.
Why the others are wrong
- A. Cluster-List checks stop loops with any cluster values; the shared ID specifically targets duplicate state.
- B. Route optimality depends on IGP cost and reflector placement, not on equal cluster IDs.
- D. Clients also benefit, but the question asks about the RR redundancy design goal, which is RR state.
H12-891 exam tip
Memory hook: same cluster means siblings ignore each other’s echoes — fewer copies stored on the RRs.
- Community
- AS_Path
- MED
- Originator ID
The short version
D — Originator-ID prevents loops, never selects routes. Community, AS-Path, and MED all steer selection.
Key concepts in this question
- Selection attributes: Community, AS-Path, MED influence best-path.
- Originator-ID role: iBGP loop prevention only.
- Cannot-use ask: the loop tool is the odd one out.
Why D is correct
Originator-ID cannot control BGP route selection (banked key refuted by attribute roles: FLIP A to D).
Why the others are wrong
- A. Community steers selection via policy.
- B. AS-Path steers selection directly.
- C. MED steers selection across entry points.
H12-891 exam tip
Selection tools are Community, AS-Path, MED. Originator-ID only stops loops.
- The route described in the message may be imported using the import command.
- The message describes a withdrawn IPv6 route.
- The next-hop address of the route described in the message is 2001:db8:2345:l::l.
- The route address prefix (including the prefix length) described in the message is 2001:db8:2345:1::1/128.
The short version
D — The update carries 2001:db8:2345:1::1/128 as reachable. Unfeasible length is zero and MP_REACH_NLRI spells out that exact prefix.
Key concepts in this question
- MP_REACH_NLRI: the attribute announcing reachable IPv6 NLRI in BGP4+.
- Prefix field: 2001:db8:2345:1::1 with length 128, a host route.
- Next hop field: 2001:db8:2345:12::1, distinct from the NLRI itself.
- Withdrawal signal: a nonzero unfeasible-routes length, absent here.
Why D is correct
The capture shows Unfeasible routes length 0, ORIGIN IGP, and an MP_REACH_NLRI block whose NLRI prefix is 2001:db8:2345:1::1 with prefix length 128. That is precisely a reachable /128 host announcement. Option D quotes that prefix and length verbatim, so it is correct.
Why the others are wrong
- A. Import versus network advertisement cannot be determined from the UPDATE bytes shown.
- B. Zero withdrawn length plus a populated MP_REACH_NLRI proves announcement, not withdrawal.
- C. The next hop reads 2001:db8:2345:12::1, not the option’s mistyped variant.
H12-891 exam tip
Memory hook: reachable IPv6 facts live in MP_REACH_NLRI — read the NLRI prefix, not the next hop.
- Service test
- Migration preparation
- On-site monitoring
- Migration implementation
The short version
C — On-site monitoring is not a middle-phase operation in this model. Preparation and implementation plus testing are placed in the middle phase.
Key concepts in this question
- Migration phases: early preparation, middle implementation and testing, post-migration monitoring and optimization.
- Middle phase tasks: migration preparation, migration implementation, and service test/verification.
- On-site monitoring: treated here as a post-migration or保障 activity, not middle-phase work.
Why C is correct
The banked model groups preparation, implementation, and service testing into the middle phase of the migration workflow. On-site monitoring or on-site assurance belongs to the later保障/optimization stage, so it is the operation not involved in the middle phase.
Why the others are wrong
- A. Service test is included as middle-phase verification after implementation in this question model.
- B. Migration preparation is explicitly part of the middle-phase input work.
- D. Migration implementation is the core middle-phase task.
H12-891 exam tip
Memorize the bank's phase grouping: preparation plus implementation plus test equals middle; monitoring equals later.
Want the full bank of 215 questions for Huawei Certified ICT Expert - Datacom? See all practice exams.