There is no universal answer. What gets done with/to headers depends both on the request, the specific CDN, the specific header and your site configuration (that includes both the headers your backend/origin server includes in the response and how you configure your site in the CDN).
Assume that by default the majority of headers will be stripped from the response generated by a back-end/origin server and only a (minimal) subset of headers will be set in the response sent by the CDN.
Some (CDN specific) headers might be added by the CDN according to your policies or by default. For example Fastly adds a
x-served-by: header by default and CloudFront allows you to set and optional
Server-Timing: header to facilitate debugging CDN operations.
Some headers might be preserved from your back-end server. For example
Expires: headers are fairly common ones. See for example: Cloud Front docs
Some might be adjusted by the CDN in specific ways. For example see how Fastly deals with a
Date: header set in the origin.
Reasons to set headers at the CDN
Rather than allowing each application to do their own thing, or not do anything you set a single policy for all your sites and applications at the CDN level.
Good examples are CORS and HSTS policies.
You may choose to only set/add a specific header at the CDN when the origin does not, but use the value from the origin if it is set there.
Reasons to preserve headers set at the origin
The application (developer) knows best what the application needs.
Overriding the default caching policy with a
Cache-Control: private, no-store is a text book example that comes to mind.