LeetCode 552: Student Attendance Record II
Use C++ Container Classes
This code looks too much like C code and not enough like C++ Code.
In the modern day C++, the use of raw pointers such as uint32_t* accumulated = a; are frowned upon, and container classes such as std::array and iterators were developed to reduce the use of raw pointers.
The C style array b is never initialized, and the C style array a is initialized twice.
        std::memset(a, 0, sizeof(a));

        for (unsigned int node_x = 0; node_x &lt; MATRIX_WIDTH_SQUARED; node_x += MATRIX_WIDTH + 1) {
            a[node_x] = 1;
        }

The first initialization can be accomplished by:
        uint32_t a[MATRIX_WIDTH_SQUARED] = {0};

and I would prefer to see an iterator used in the second initialization.
Use Proper Casting
Currently the code is implementing C style casting ((uint32_t) (first_col_sum % MODE)) which is not as type safe as either static_cast(VALUE_TO_BE_CAST) or dynamic_cast&lt;NEW_TYPE&gt;(EXPRESSION). In this case I recommend static_cast.
Static Functions
It is not clear why the checkRecord() function was changed to a static member function since the original prototype was int checkRecord(int n) in the question. There really is no need for it to be static.

By declaring a function member as static, you make it independent of any particular object of the class. A static member function can be called even if no objects of the class exist and the static functions are accessed using only the class name and the scope resolution operator.

Variable Names
The symbolic constant names are clear as are the variable names adj_matrix (adjacency would be clearer), accumulated and adj_matrix_pointer, but the variable names a, b and temp are not clear and leave someone who has to read or maintain the code guessing.
Complexity
The function checkRecord() is too complex (does too much). After the if statement there should be a call to a function to execute the rest of the code, and that function might cal sub functions. Remember that it is much easier to write correct code when you limit what a function is responsible for.
There is also a programming principle called the Single Responsibility Principle that applies here. The Single Responsibility Principle states:

that every module, class, or function should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by that module, class or function.