How to answer
How do you secure your cloud infrastructure, and where does your responsibility end?
Half the answer belongs to your cloud provider, and the half that matters is yours. Naming the boundary is more useful than describing either side.
Infrastructure runs on a managed cloud platform, provisioned entirely from version-controlled infrastructure-as-code so no configuration is applied by hand. The provider secures the physical facilities, the hypervisor and the managed services; we are responsible for identity, network configuration, data classification and everything we deploy on top.
FillTrust grades an answer like this implied, not stated when your documents support it.
- Answered from
- Your architecture documentation and your provider's shared responsibility model. Half this answer is about someone else's controls and should say so.
- Evidence to attach
- An architecture diagram, and the provider's compliance reports if the reviewer wants the platform half.
- Where it is asked
- CAIQ v4.0 · STA-06SIG Lite
Cloud infrastructure questions get answered with the provider's compliance certificates, which is understandable and answers the wrong half. The platform's controls are genuinely strong and are genuinely not what a reviewer is worried about. They are worried about the storage bucket, the security group and the identity policy, all of which are yours.
Name the boundary explicitly. The provider secures the facilities, the hardware, the hypervisor and the managed services they operate. You are responsible for identity and access, network configuration, what you deploy, how it is configured and the data in it. Saying this out loud is not filler: the risk a reviewer is probing for is a control that both parties assumed the other owned, and that gap only closes when somebody writes the line down.
Infrastructure as code is the strongest thing most small teams can say here. If every resource is provisioned from version-controlled definitions, then your configuration is reviewable, reproducible and has a history. That answers "how do you know nothing was changed by hand at two in the morning" better than any policy statement, and it is checkable in a way a claim about hardening standards is not.
Be careful what you claim to benchmark against. Naming a hardening standard invites a request for the report showing you meet it. If you run a posture tool and act on its findings, say that and say the cadence. If you do not, describing the controls you actually have is stronger than naming a benchmark you cannot evidence.
Cover identity, because that is where the incidents are. Who can reach the production environment, whether that access requires multi-factor authentication, whether anything runs with long-lived static credentials, and how access is removed when someone leaves. Those four sentences answer more of what this question is really about than a paragraph on network architecture.
If you run on a managed platform with very little of your own infrastructure, say so. A small surface is a genuine security property, and a reviewer would rather read "we run three managed services and no virtual machines" than a description of controls for infrastructure you do not operate.
How this one goes wrong
Specific to this question, not general advice.
- Answering with your provider's certifications. Their SOC 2 covers their platform. Every breach of note in cloud hosting has been on the customer's side of the line.
- Claiming hardening you cannot show. "Follows CIS benchmarks" invites a request for the benchmark report, and there usually is not one.
- Not saying where the line falls. A reviewer's real worry is a control both parties assume the other owns, and naming the split is what resolves it.