Browse all 10 free NVIDIA-Certified Professional: Agentic AI practice questions below.
Your team runs a LangChain agent in production and is weighing a custom instrumentation layer against adopting the NVIDIA NeMo Agent Toolkit. The team will not rewrite the agent, and it needs to see where latency and token spend go inside each run.
Select TWO capabilities of the toolkit that meet these needs.
- It converts LangChain chains into its own workflow format on import, replacing the LangChain runtime.
- It works alongside frameworks such as LangChain and exports traces to backends like Phoenix or Langfuse.
- It serves the LLM itself, so the agent no longer needs NIM or another inference endpoint to run.
- Its profiler breaks each run down from the workflow level to individual tokens, per tool call and LLM step.
- It compiles the agent's Python control flow into CUDA kernels, so that the reasoning steps run on the GPU.
You must choose between two agents for a workload that is 70% question answering, 20% classification and 10% summarization. Your harness reports one blended score per agent, averaged equally across the three task suites: Agent B 0.74, Agent A 0.72.
What should you do before choosing?
- Replace the three task suites with one general benchmark such as MMLU, so both agents answer identical questions.
- Rerun the blended evaluation with three random seeds, and pick the agent whose mean score stays ahead.
- Score each task with its own metric, compare the agents task by task and weight results by the workload mix.
- Pick Agent B, since a 0.02 lead on a score blended across three suites is consistent evidence of quality.
Your support agent splits each question into four to six sub-queries and sends each one, in turn, to the embedding NIM and then the vector store before calling an LLM served with TensorRT-LLM. Profiling shows the embedding GPU at 12% utilization, and users see nothing for about 6 seconds until the whole answer appears at once.
Which change best raises GPU efficiency and cuts the wait users feel, without changing answer quality?
- Route each question to an 8B model in place of the 70B model, cutting the cost of each generation.
- Raise retrieval top-k from 5 to 20 per sub-query, so that the LLM receives more evidence in each call.
- Batch the sub-queries sent to the embedding NIM and vector store, and stream the LLM's tokens to the client.
- Add a semantic cache that returns a stored answer whenever a new question's embedding is close to a cached one.
Your RAG agent's answers drop key facts and sometimes cite document IDs that were never retrieved. Vector search recall@50 is 0.95, but the passage that holds the answer is often ranked between 9th and 30th, while the LLM receives only the top 5. You cannot retrain the LLM.
Select TWO interventions most likely to help.
- Require a source ID for each claim, and reject answers that cite IDs missing from the retrieved set.
- Lower the temperature to 0, so the model stays with the retrieved passages and stops inventing sources.
- Increase the chunk size to 2,000 tokens, so each retrieved chunk carries as much context as possible.
- Raise the top-k passed to the LLM from 5 to 25, so that the answer passage is usually in the context.
- A reranker, such as a NeMo Retriever cross-encoder model, that reorders the top 50 candidates before the LLM.
Your agent answers account questions from three client systems: a PostgreSQL billing database, a MongoDB support store and a REST CRM. The same customer appears as cust_id, customerId and an email address, and dates arrive as epoch seconds, ISO strings and local-time text. The agent's answers mix up customers and put events in the wrong order.
Which design fixes this?
- Give the agent a SQL tool, a MongoDB tool and a CRM tool, and let it join the records itself at query time.
- Load all three sources into one vector index, so that semantic search returns a customer's records together.
- Add few-shot examples to the prompt that show how the three ID formats and date styles map onto each other.
- Build an ETL pipeline that extracts each source, maps its fields to one schema and normalizes IDs and dates.
Your incident agent answers questions such as "why is checkout slow since the 2 p.m. deploy?" It greps recent logs for words from the question and looks up the CMDB by exact service name. It misses log lines that say "p99 latency" or "timeout," and it fails when users say "checkout" while the CMDB lists "payments-gateway."
Which design best supports fast reasoning across both sources?
- Add an alias table to the CMDB that maps common user terms to service names, maintained by the SRE team.
- Index log lines and CMDB records in one vector store, and run hybrid semantic and keyword search across both.
- Summarize each hour of logs into plain text with an LLM, and have the agent read the most recent summaries.
- Expand each grep with an LLM-generated list of synonyms for the words in the question before searching the logs.
Your code-generation agent collects thumbs-up and thumbs-down votes. After three months the thumbs-up rate is 78%, but the team cannot decide what to change: a thumbs-down may mean wrong logic, insecure code or poor style, and many thumbs-up votes go to code that compiles but was never run.
Which feedback method best drives targeted, iterative improvement?
- Have expert reviewers score a sample of outputs on a numeric rubric for correctness, security and style.
- Replace the votes with an LLM judge that scores each output for correctness and style on a 1 to 10 scale.
- Add a free-text comment box to the thumbs-down button, and cluster the comments each month by topic.
- Track acceptance rate, the share of generated code committed without edits, as the main quality metric.
Your distributed agents (intake, enrichment, scoring and notification) call each other over synchronous HTTP. When the scoring agent restarts, upstream calls time out and work is lost; 10x traffic bursts cause cascading timeouts; and adding a new consumer requires changing every producer.
Select TWO communication patterns that fix these problems.
- A durable queue or event log, such as Kafka or NATS JetStream, that keeps messages until they are acknowledged.
- Long-lived gRPC streams between each pair of agents, so messages flow without per-call overhead.
- Publish/subscribe topics, so agents subscribe to event types without knowing which agents emit them.
- Synchronous HTTP between agents with retries, exponential backoff and a circuit breaker on each call.
- A shared in-memory store in the coordinator process that the agents read and write directly.
Your agent approves vendor payments up to $50K. After a disputed payment, a forensic review found that an engineer had edited the agent's policy file without approval, and that the decision logs had been modified during a cleanup, so nobody could prove what the agent saw or why it paid.
Which practice best ensures security and accountability?
- Anonymize the inputs before they are written to the decision log, so that it holds no personal data.
- Encrypt the decision logs at rest, and keep them in the same database the agent uses for its state.
- Use RBAC for who can run or change the agent, and keep a write-once, signed audit log of each decision.
- Require code review for policy changes, and give engineers broad log access to speed up investigations.
Your team is building two agents: (a) a support agent whose next lookup depends on what the previous lookup returned, and (b) a nightly report agent that runs the same 12 independent queries and merges the results.
Select TWO statements that correctly describe when ReAct or Plan-and-Execute fits.
- ReAct suits agent (a): each action depends on the last observation, which ReAct reasons over before acting.
- ReAct suits agent (b): calling the LLM between each of the 12 queries keeps the report fully grounded.
- ReAct suits both agents, since it uses fewer LLM calls than Plan-and-Execute on multi-step tasks.
- Plan-and-Execute suits agent (b): one planning call fixes the steps, and executors run them in parallel.
- Plan-and-Execute suits agent (a): its upfront plan covers each branch, so new results need no replanning.
