TL;DR: Name a small number of sources you actually use, then spend the answer on one specific thing you learned recently: why you chose it, how you learned it, and what you did with it. Depth on one beats breadth across ten, and the follow-up will go straight there.
How to approach it
Assume the second half of the question is the real one. "What have you learned recently" is a fact check on the first half, and an answer that lists podcasts and then cannot produce a concrete example does not survive it. Prepare one thing properly, with a reason for choosing it and something you built or changed.
A strong answer
On sources, be brief and honest. Two or three that you genuinely use, named specifically: a couple of engineering blogs where the companies actually publish their incident write-ups, a release-notes feed for the tools you run, the documentation when you need it. Nobody reads ten newsletters, and claiming to invites a question about last week's issue.
The more useful thing to say is that incidents and upgrades are where most real learning happens. The week you debugged something you did not understand teaches more than any course, and reading other organisations' public postmortems is unusually high-value, because they are the only place people write honestly about how systems fail.
Then the specific example, which is most of the answer. A shape that works:
What you learned and why you chose it. The reason matters. "I spent a few weeks on eBPF-based networking because we were about to double our cluster size and I wanted to understand what was replacing iptables and whether it changed our failure modes." That is learning driven by something real rather than by novelty.
How you learned it. The honest version of this is usually reading the documentation and then building something small enough to break. Say that. "I read the docs, then ran it in a kind cluster on my laptop and broke the network policy deliberately to see what the failure looked like."
What you did with it. This is the part that distinguishes learning from consuming. Wrote it up for the team. Changed a default. Raised a question in a design review that changed a decision. Even "decided we should not adopt it yet, and wrote down why" is a good outcome and shows judgement.
For a career changer, two additions. Pick depth over breadth, deliberately, and say so: knowing Kubernetes properly is worth more than a shallow familiarity with Kubernetes, Terraform, Ansible, Jenkins and three clouds, and interviewers can tell the difference within two questions. And having something you built and can show is the strongest possible form of this answer, because it converts a claim into an artifact.
On certifications, be measured. They are useful for structure and for getting past a screening filter, particularly in the services companies, and they do not demonstrate that you have operated anything. Mention them as one input rather than as the evidence, and have a story about something you built alongside.
What interviewers probe next
"Tell me more about that." Which is why the example needs to be real. Expect to be asked what surprised you, what you got wrong first, and where you would not use it.
"How do you decide what to ignore?" A good question to have an answer for. Anything not attached to a problem you have, or a tool you run, can wait. The field produces more than anyone can follow, and choosing is the skill.
"What is the last thing you got wrong?" Have one. Something you believed about a system that turned out to be false, and how you found out. It is a more credible answer than any success.
Common mistakes
Listing sources with no concrete example, which fails the moment the interviewer asks for one.
Naming something you skimmed a blog post about, then being unable to answer a second-level question.
Claiming a breadth of tools that a few specific questions will undo.
Treating a certification as the answer, with nothing built alongside it.