Free GitLab Certified Duo Agent Platform Associate practice test: 30 questions with answers

Agentic chat can plan a multi-step request and use GitLab tools to create and update objects such as issues and labels. Code completion is an editor feature, the credits dashboard reports usage, and the AI Catalog is for finding agents and flows rather than running a task.

The Security Analyst is a foundational agent designed for security work such as triaging findings and suggesting fixes. A custom agent with no tools cannot see the findings, code completion works inside the editor while typing, and a credits report is about cost rather than analysis.

Human-in-the-loop approval makes the agent wait for a person's decision before it performs the action. Running first and logging afterwards defeats the approval, a self-assessed confidence score is not an approval mechanism, and retrying with a broader token is an escalation the team should not permit.

In MCP the client is the application that connects to servers, lists their tools and calls them, which here is the AI assistant. The ticketing backend is the server, the mcp.json file only holds connection details, and hosted infrastructure is not one of the protocol roles.

MCP servers advertise their tools through a list request, which returns each tool's name, description and input schema for the client to choose from. Downloading source code, asking the model provider for languages or checking credit balances are not how a client discovers tools.

External MCP servers are declared in an mcp.json configuration entry that gives the server's name and how to reach it. CI/CD variables, a foundational agent registration and a README file do not register MCP connections for the assistant.

Tool descriptions from an external server are untrusted content, so this text is a prompt injection attempt. Disabling the server, reviewing its tools and keeping writes behind approval contains the risk, while trusting it, adopting its instruction or giving it more budget would help the attack.

Trusting only vetted servers and reviewing their tools, plus scoping credentials to the minimum needed, both shrink what a compromised or malicious server can do. A shared administrator token and unchecked servers from chat each expand that risk.

A system prompt sets the agent's role, scope, output format and boundaries, and those specifics make its behaviour consistent across runs. Removing instructions, pasting every document in, or reducing the prompt to a greeting each leave the agent without the guidance it needs.

Least privilege means an agent should hold only the permissions its task requires, and this agent holds far more than summarizing needs. Defense in depth, a single source of truth and continuous integration are real practices, but none of them describes limiting an agent's permissions.

Issue text from outside users is untrusted input, so the agent's permissions must stop a single injected sentence from causing damage. Trusting the text, copying it into the system prompt or giving the agent more budget would all make the injected instruction more likely to succeed.

Prompt injection happens when content an agent reads, such as an issue comment or a file, contains instructions that try to take control of its behaviour. Adding examples, caching prompts and splitting long inputs are ordinary prompt-engineering or performance techniques, not attacks.

A published flow runs with the access it is given, so reviewing its prompts, permissions and triggers and documenting its purpose is the standard step before sharing it. Owner access everywhere, an empty description and borrowing a foundational agent's name each weaken security or clarity.

A trigger is the part of a flow that defines the event that starts it, such as opening a merge request. The final output step, the first agent's system prompt and the chosen model all shape what happens during a run rather than when it begins.

Conditions control whether a step executes depending on what came before, such as a scan result or a label. Token limits, catalog storage and interface colours are separate settings that do not decide which steps run.

Steps in a flow run in order and pass their outputs forward, so the summary can reflect the test draft and the security findings. Posting first, merging by hand, or forcing everything into one prompt would lose the data flow the team needs.

Flows are the layer that sequences several agent steps into one ordered process. A foundational agent covers one role on its own, the AI Catalog only lists and shares definitions, and an MCP server exposes tools without deciding the order of work.

GitLab supplies foundational agents that are ready to use, while organizations define their own custom agents with their own prompts and tool choices. The other options swap who creates each type or invent restrictions that do not describe the difference between them.

Agent autonomy is the degree to which an agent may act without human approval, which is exactly what the administrator is balancing. Flow orchestration, context window size and prompt versioning are real concepts, but none of them describes how much an agent may act unsupervised.

Restricting tools to what the task needs and requiring approval for consequential changes both narrow what an agent can do unsupervised. A long-lived administrator token and unreviewed write actions both widen the damage an agent can do.

The AI Catalog is where agents and flows are published so other projects can discover and reuse them. Copying files by hand does not scale and drifts out of date, billing settings do not distribute agents, and registering a server on one laptop serves only that machine.

The orchestration layer coordinates execution: it decides the sequence of steps and moves results between them. Writing a system prompt is part of defining one agent, storing model weights is a hosting concern, and choosing interface themes has nothing to do with running a process.

The agent layer holds a single role with its own instructions and tools, which is what this specialist is. A flow strings several agent steps together, orchestration decides the order at run time, and billing only records consumption, so none of them describes one specialist.

Code generation takes a natural-language description, such as a comment, and produces new code from it. Code completion predicts continuations of code the developer is already writing, while security scanning and merge request review are separate features that analyze code rather than write it.

The Code Review Flow examines merge request changes and leaves review comments, which gives reviewers a first pass. Code completion works while typing in the editor, a standard chat session answers one user's questions, and a credits report measures cost rather than reviewing code.

Suggested code can be wrong or insecure, so tests, human review and security checks apply just as they do to other code. Accepting without review or merging straight to the default branch removes those checks.

The Code Review Flow examines merge request changes and comments on them, which gives reviewers a first pass but does not replace their judgement. The other options claim it removes approvals, rewrites code or ignores merge requests, none of which is accurate.

A token committed to version control must be considered exposed, so rotating it is the priority and removing it from the code is a follow-up. Waiting for a merge, pasting the secret into chat or hiding the finding in a prompt all leave the credential at risk.

Model choice trades off quality, speed and cost, so the task's needs and the value of each run should guide it. The length of a model's name and the colour of a chat window have no bearing on how well a step performs.

Usage depends on how often the flow runs and how much work each run does, so a trial on representative work shows the likely cost before wider rollout. A fixed per-project assumption, hidden usage or separate copies with their own allowance do not estimate cost reliably.