Checkmarx CxCE study materials
Checkmarx CxCE study resources

Checkmarx CxCE: Checkmarx Platform Architecture, Deployment, and Administration

Checkmarx CxCE · Work through your exam, one topic at a time.

All guide sections

Checkmarx Platform Architecture, Deployment, and Administration

What this domain tests

Architecture questions ask you to place a symptom (slow scans, invisible project, failed login) on the right component, and administration questions ask how teams, roles, engines, and licensing shape what a user can scan and see.

Core components

  • CxManager - the central server. It hosts the IIS web portal and the Windows services that queue and schedule scans, and it owns configuration and results.
  • CxEngine - performs the actual code analysis. Engines may run on the manager host or on separate Windows machines in a distributed deployment. Crucially, each scan runs on one engine, so adding engines raises concurrency, not the speed of a single scan.
  • SQL Server - stores projects, scan metadata, results, comments, and the audit trail. Growth is driven by scan count and result volume, not only by source size.
  • Clients - CxAudit, IDE plugins, CxConsole (CLI), REST API, and CI/CD plugins; all authenticate against the same access-control model.

Access control and tenancy

Users belong to a hierarchical team structure. A project is assigned to a team, and a user sees projects belonging to their teams and their sub-teams, so parent-team membership grants visibility downward. Roles (for example Admin, Manager, Auditor, Reviewer, Scanner) map to permissions such as running scans, editing queries, or changing result states. Authentication can come from local accounts, LDAP/Active Directory, or SSO, but authorization always stays inside CxSAST.

Operations

Watch the scan queue and engine health, size the database, verify that the service account can reach scheduled source locations, use a proxy where needed, and configure mail notifications. Before an upgrade, back up the database and upgrade the manager before engines and clients.

Worked example

A team reports that scans sit in the queue for hours. Diagnosis order: is any engine offline or unreachable (health list), how deep is the queue, and are engines saturated with long scans? Adding an engine lets more scans run in parallel; it will not shorten the one huge scan the team is waiting on. The correct fix may be excluding vendored folders and splitting the monolith into several projects.

Traps that cost marks

  • Confusing inheritance direction in teams, which silently exposes projects.
  • Deleting a user who owns assignments or comments.
  • Treating engine count as per-scan speed.
  • Upgrading engines or plugins first and then discovering an API mismatch.