Cloud Security interview questions: security architecture
Reviewed by Mark Dickie · Last updated
8 questions on this page you can answer and see marked on the spot. Go to the first one
Cloud security architecture is the design of controls, policies, and network structures that protect data and workloads running in a cloud environment. For an interview, you need to show you can reason about shared responsibility boundaries, identity-centric access design, network segmentation, and how to map threats like data exfiltration or privilege escalation to concrete mitigations. Interviewers will also probe your understanding of zero trust principles, encryption at rest and in transit, and how you harden multi-cloud or hybrid setups without creating operational friction for the teams who have to live inside the controls you define.
The table below maps the core architecture domains interviewers draw from and the level of depth expected in a typical engineering or architect-track interview:
| Domain | What interviewers probe | Typical difficulty |
|---|---|---|
| Identity & access management | Least-privilege policy design, role assumption, conditional access | 3–4 |
| Network segmentation | VPC/VNet design, micro-segmentation, east-west traffic control | 3–5 |
| Data protection | Encryption strategy, key management, secrets handling | 2–4 |
| Shared responsibility | Where provider control ends and customer control begins | 1–3 |
| Zero trust architecture | Trust evaluation per request, policy enforcement points | 3–5 |
| Incident response & detection | Logging coverage, detection design, blast-radius containment | 3–4 |
What does a cloud security architecture interview test?
Most interviews split into two halves: a design scenario and a knowledge-recall round. The design scenario usually gives you a cloud workload or migration problem and asks you to secure it end to end. The recall round checks whether you can name the right service, control, or pattern for a given threat without hand-waving.
How should you approach the design scenario?
- Clarify the shared responsibility split for the specific provider and service model (IaaS vs. PaaS vs. SaaS) before proposing anything.
- Start with identity: define who or what authenticates, what roles they assume, and under what conditions.
- Layer network controls next, including segmentation between trust zones and restrictions on egress paths.
- Specify data-protection controls: encryption at rest, key custody, and how secrets reach workloads at runtime.
- Close with detection and response: what logs you collect, which signals trigger alerts, and how you contain a compromised resource.
Key facts
- Tarmac has 27 Cloud Security interview questions on this topic, 25 of them on this page, at difficulty 1–5 of 5.
- Tarmac tracked 1,251 job postings asking for Cloud Security in September 2026.
- Roles asking for Cloud Security advertise a median base salary of US$180,000, across 181 job postings as of September 2026.
- Tarmac last reviewed these Cloud Security interview questions on 14 October 2026.
At a glance
| Questions | 25 shown · 27 in the bank |
|---|---|
| Difficulty | 1–5 of 5 |
| Formats | True / false, Short answer, Flashcard, Multiple choice |
What you'll review
- zero trust vs perimeter models
- security reference architectures
- threat surface reduction
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
In a zero-trust security model, a user connected to the corporate internal network is granted implicit trust and does not need to re-authenticate when accessing an internal application, because the network perimeter already protects them. True or false?#
Options
Show answer
A user on the corporate internal network does not receive implicit trust under zero trust; they must authenticate and be authorized for each internal application. Zero trust follows the principle 'never trust, always verify,' so network location alone never grants access, unlike perimeter models that assume inside traffic is safe.
This statement is false. The defining principle of zero trust is 'never trust, always verify.' The perimeter model assumes traffic inside the network boundary is safe and grants implicit trust to internal users, but zero trust treats every access request the same way regardless of network location. Each request must be authenticated and authorized against identity, device posture, and other contextual signals before access is granted.
In a perimeter-based security model (also called 'castle-and-moat'), what is the fundamental assumption about a device that has successfully connected to the corporate network?#
Show answer
In a perimeter model, a device inside the network boundary is assumed to be trusted and may access internal resources with minimal additional verification.
The perimeter model treats the network boundary as the trust boundary: once a device passes through the firewall or VPN, it is considered inside the trusted zone and can reach internal resources with comparatively little ongoing verification. Zero Trust rejects this assumption by requiring continuous authentication and authorization for every request regardless of network location.
What three-word phrase summarizes the guiding philosophy of the Zero Trust security model?#
Show answer
Never trust, always verify — every access request is authenticated, authorized, and continuously validated regardless of whether it originates inside or outside the network perimeter.
The defining maxim of Zero Trust is 'never trust, always verify,' meaning no implicit trust is granted based on network location; every request is independently authenticated and authorized.
What is the primary purpose of a cloud security reference architecture?#
Show answer
A cloud security reference architecture is a reusable, standardized blueprint that defines recommended security controls, network zones, identity boundaries, and design patterns for deploying cloud workloads securely and consistently across an organization.
A security reference architecture is a reusable, standardized blueprint that defines recommended security controls, network zones, identity boundaries, and design patterns so that cloud deployments follow a consistent, vetted security baseline. It does not replace a security operations team, it is not merely an audit checklist, and it addresses cloud rather than on-premises physical hardware concerns.
Name a foundational IAM technique for reducing the threat surface in a cloud security architecture and briefly explain how it works.#
Show answer
Apply the principle of least privilege to every IAM role and service account so each identity receives only the minimum permissions it needs. This shrinks the exploitable surface because a compromised credential can reach only a few resources and actions.
The principle of least privilege grants each identity only the permissions required for its job, so a compromised or misused credential can reach fewer resources and perform fewer actions. Because it limits the blast radius no matter which specific resource or vulnerability an attacker targets, it is a foundational way to reduce the exploitable threat surface in a cloud architecture.
What does it mean to reduce the threat surface in a cloud security architecture?#
Show answer
Threat surface reduction means minimizing the set of exposed entry points an attacker could target, such as open ports, public-facing APIs, IAM permissions, and enabled cloud services, so that fewer attack paths exist.
Threat surface (attack surface) reduction is the practice of shrinking the collection of points where an unauthorized actor could interact with a system. In cloud environments this includes closing unused ports, removing unnecessary public endpoints, scoping down IAM permissions, and disabling unneeded managed services. Each removal eliminates a potential attack path, leaving the attacker with fewer ways to gain access.
What is the fundamental difference between the zero-trust model and the traditional perimeter-based (castle-and-moat) security model?#
Show answer
Zero trust assumes no implicit trust based on network location and verifies every access request, whereas the perimeter model grants implicit trust to users and devices once they are inside the network boundary.
The zero-trust model assumes no implicit trust based on network location: every access request is authenticated, authorized, and continuously validated before access is granted. The traditional perimeter model assumes that users and devices inside the network boundary are trusted and can access resources freely once they have crossed the perimeter. This is why zero trust is often described as the opposite of castle-and-moat security.
In the cloud shared responsibility model, which service model places the GREATEST security responsibility on the cloud service provider (CSP), leaving the customer primarily responsible for data governance, identity, and access management?#
Options
Show answer
SaaS (Software as a Service) places the greatest security responsibility on the cloud provider. The provider runs and secures the whole stack, from physical facilities up through the application, while the customer keeps data governance, identity, and access management.
Under SaaS the cloud provider operates and secures the entire stack, including physical infrastructure, virtualization, OS, runtime, middleware, and the application, so it carries the most security responsibility of any cloud service model. The customer's remaining duties centre on data governance, identity management, and access control. In IaaS the customer must also secure the OS, middleware, and application layers, and in PaaS the customer secures applications and data while the provider covers the OS and runtime. On-premises deployment is not a cloud service model at all, so it does not fit the question.
Your team runs a fleet of cloud-hosted virtual machines in a public cloud VPC. Which single change, by itself, reduces the external attack (threat) surface of those VMs?#
Options
Show answer
The correct change is removing all inbound security group rules except port 443 from a known corporate CIDR block. Threat-surface reduction means shrinking the set of externally reachable entry points. Locking inbound rules to one port and one source range directly cuts what an adversary can probe. Logging, multi-AZ, and SIEM aggregation improve detection or resilience, not exposure.
Threat-surface reduction means shrinking the set of externally reachable entry points an adversary could discover or exploit. Restricting inbound security group rules to only port 443 from a known corporate CIDR block directly narrows the exposed network surface — fewer open ports and fewer source addresses. Enabling verbose audit logging and forwarding logs to a SIEM improve detection and forensics, not surface area. Adding availability zones improves resilience, not exposure. None of those alternatives remove or restrict an exploitable entry point.
Your organization runs several internet-facing microservices in a public cloud. Name three concrete architectural changes that reduce the externally reachable attack surface of those services. Do not include detection, logging, or alerting improvements.#
Show answer
- Remove public IP addresses from the service VMs/containers so they have private IPs only, and front them with an internal load balancer plus an API gateway or WAF as the sole internet-facing component. 2. Tighten inbound security group / firewall rules so each subnet or instance accepts traffic only from its specific upstream component (for example, the API gateway subnet) on the exact port needed, closing all other inbound paths. 3. Use cloud private endpoints (AWS PrivateLink, Azure Private Link) for calls to managed services such as databases, storage, and queues, so that traffic stays on the provider backbone and never crosses the public internet.
Threat-surface reduction shrinks the number and breadth of externally reachable entry points (public IPs, open ports, exposed APIs, reachable services) rather than improving visibility after an attack. A strong answer names three distinct surface-shrinking changes: removing public IPs and funneling all ingress through a single controlled gateway or WAF, restricting inbound security group or firewall rules to only the required source and port, and using private endpoints so managed-service traffic never crosses the public internet. Each change eliminates or narrows a concrete avenue an attacker could discover or exploit, and none of them is a detection or logging improvement.
In a traditional perimeter-based security model, a user or device that authenticates at the network boundary (for example, via VPN or an edge firewall) is generally granted broad access to internal resources. Name the zero-trust principle that corrects this implicit trust, and state what it requires for each access request.#
Show answer
The corrective principle is explicit, continuous verification: 'never trust, always verify.' Every access request is authenticated and authorized based on identity and real-time context, such as device posture and the requested resource, and is granted under least-privilege policies, regardless of whether the request originates inside or outside the network perimeter.
Zero trust replaces the 'trust but verify' posture of perimeter models with 'never trust, always verify': network location confers no trust, so every request must be authenticated, authorized, and scoped to least privilege using identity and context. This counters the perimeter model's core weakness, where an attacker who breaches the boundary is treated as trusted inside.
A mid-sized SaaS company runs a flat internal network behind a single perimeter firewall. Once employees connect through VPN, they can reach most internal services. The security team wants to move to a zero-trust architecture. Describe the transition, covering: (1) how you replace trust based on network location with identity-based access, (2) how you segment the network to limit lateral movement, and (3) how you handle continuous verification and monitoring without crippling developer productivity.#
Show answer
Phase 1, identity-based access: Put an identity-aware proxy (for example, Cloudflare Access, Google BeyondCorp, or Azure AD Conditional Access with App Proxy) in front of each internal application instead of granting broad network access over the VPN. Every request is authenticated through the corporate IdP using SAML or OIDC and authorized per application based on user identity, group membership, and device posture such as managed status, disk encryption, and OS patch level. Phase 2, segmentation: Split the flat network into least-privilege segments aligned to application tiers (web, API, database) and, where useful, business units. Enforce default-deny allow-lists with cloud-native controls such as security groups or host-based micro-segmentation, so the web tier reaches the API tier only on its required port, the API tier reaches the database only on the database port, and no other inter-segment traffic is permitted. This limits lateral movement if one segment is compromised. Phase 3, continuous verification and monitoring: Evaluate device posture and session risk on every request rather than only at VPN connect time, feeding MDM and EDR signals into the policy engine. Use short-lived access tokens, for example 15-minute tokens, instead of long-lived network sessions. Send logs to a SIEM with UEBA to detect anomalies such as unusual source locations, access to unfamiliar services, or sudden spikes in data transfer. To protect productivity, rely on SSO so checks are transparent to users, automate device enrollment so managed laptops pass posture checks without manual steps, and provide a self-service path for temporary elevated access to production segments with approval workflows and automatic expiry.
The question asks for a practical zero-trust transition design covering three areas: replacing network-location trust with identity-based, per-request authorization; segmenting the network with default-deny allow-lists to limit lateral movement; and applying continuous verification and monitoring while keeping developer workflows smooth. A strong answer names concrete mechanisms for each area, such as an identity-aware proxy, tiered allow-list segmentation, device posture checks, short-lived credentials, SIEM/UEBA monitoring, and automated enrollment with just-in-time access. The sample answer covers each pillar with these details, so it is a sound open-ended design question best graded against those expectations rather than a single fixed answer.
In the NIST SP 800-207 zero trust reference architecture, which logical component makes the real-time allow-or-deny access decision when a subject requests access to an enterprise resource?#
Options
Show answer
The Policy Decision Point (PDP) is the NIST SP 800-207 zero trust component that makes the real-time allow-or-deny decision for each access request to an enterprise resource. It evaluates the request against configured policy and attributes gathered from other components. The Policy Enforcement Point then carries out that verdict in the data path.
The Policy Decision Point is the logical component defined in NIST SP 800-207 that evaluates each access request against configured policies and renders an allow-or-deny decision in real time. The Policy Enforcement Point sits in the data path in front of the resource and enforces the decision the Policy Decision Point made, but it does not itself decide. The Policy Information Point supplies supplementary attributes, such as device posture, time, or threat-intel signals, that the Policy Decision Point may consult, yet it does not produce the authorization verdict. The Continuous Diagnostics and Mitigation system feeds ongoing posture telemetry into the policy evaluation context but is not the component that issues per-request access decisions.
Under PCI DSS guidance, what is the main compliance benefit of using network segmentation to isolate the Cardholder Data Environment (CDE) from non-CDE workloads in a cloud environment? Explain in a few sentences.#
Show answer
It reduces the scope of the PCI DSS assessment. Non-CDE systems that are properly isolated from the CDE by segmentation controls fall out of scope, so only the CDE and systems directly connected to it must be validated against PCI DSS requirements.
PCI DSS documents network segmentation as a mechanism for scope reduction. When the CDE is effectively isolated by segmentation controls, adjacent non-CDE systems are excluded from the assessment scope, so fewer systems must be validated against PCI DSS requirements. The answer is the scope reduction itself, not a security claim: segmentation still needs to be verified (for example by penetration testing of the segmentation controls) to keep the out-of-scope status valid.
Design a cloud security reference architecture for a regulated workload that processes payment card data and is being migrated to a public cloud. Your design must address: (1) network segmentation, (2) identity and access management, (3) encryption and key management, (4) logging and monitoring, and (5) PCI DSS compliance scoping. Keep it provider-agnostic enough to map to AWS, Azure, or GCP, but name concrete service categories where useful.#
Show answer
Network segmentation: Place the cardholder data environment (CDE) in a dedicated VPC/VNet with isolated subnets. Use subnet-level network ACLs as a coarse boundary, and resource-level security groups/NSGs for least-privilege east-west traffic. Put a next-generation firewall or cloud-native equivalent at the CDE boundary, and expose only a hardened API gateway or WAF to the internet. Default-deny all traffic into the CDE.
Identity and access management: Federate a corporate identity provider over SAML or OIDC. Require MFA for all human access, grant least-privilege RBAC through cloud-native roles, and use just-in-time, audited break-glass elevation. Apply conditional-access policies that evaluate device posture and sign-in risk. Workloads authenticate with managed identities so no long-lived secrets are embedded in code.
Encryption and key management: Encrypt data at rest with customer-managed keys held in an HSM-backed key service (for example AWS KMS with CloudHSM, Azure Key Vault with Managed HSM, or GCP Cloud KMS with Cloud HSM). Rotate keys on a defined schedule, enforce TLS 1.2 or higher for all data in transit, and keep separate keys for CDE and non-CDE workloads so they never share key material.
Logging and monitoring: Forward control-plane audit logs (CloudTrail, Azure Activity Log, GCP Audit Logs) to immutable storage. Enable flow logs for CDE network traffic. Feed everything into a centralized SIEM with alerts for anomalous access, privilege escalation, and policy violations. Run continuous posture scanning (Security Hub, Defender for Cloud, or Security Command Center) to detect configuration drift, and maintain a documented incident runbook with triage SLAs.
PCI DSS scoping: Document the CDE scope explicitly and use segmentation to reduce it, so only systems that store, process, or transmit cardholder data fall inside. Enforce resource tagging for CDE membership through organization-level policy. Validate scope annually and run external vulnerability scans quarterly through an Approved Scanning Vendor.
This is an open design question with no single key, so it stays SHORT_ANSWER and is graded against the sample answer and keywords. A strong answer must cover all five required areas with concrete controls: CDE network segmentation with default-deny and a boundary firewall, federated identity with MFA and least-privilege roles, customer-managed keys in an HSM-backed service with separated CDE keys, centralized immutable logging with a SIEM, and PCI DSS scope reduction with annual validation and quarterly ASV scans. The sample answer demonstrates each of these in provider-neutral terms with example services mapped to AWS, Azure, and GCP.
In a multi-account cloud landing zone reference architecture, security designs often place centralized logs in a dedicated log-archive account that is separate from workload accounts. Explain the two main security benefits of this separation.#
Show answer
Keeping the log archive in its own account separates duties: the teams that run workloads cannot read, alter, or delete the audit trail for their own activity. This makes the logs tamper-resistant, often with immutable or write-once storage and restricted delete rights, so they remain trustworthy evidence for investigations and compliance. The same account also gives security teams one complete, centralized record of activity across all accounts.
The answer hinges on two properties the separate log-archive account provides. First, separation of duties: workload account administrators hold no permissions over the archive, so a compromised or malicious workload admin cannot erase evidence of their own actions. Second, tamper resistance: the archive can be locked down with immutable or write-once storage and restricted delete permissions, preserving log integrity for forensics and compliance. A correct answer names at least one of these benefits with a concrete reason, such as preventing a workload admin from altering or deleting logs. Centralization of the audit trail is a useful side effect but not the primary security reason, so an answer relying only on it is incomplete.
An application running in a VPC currently reaches Amazon S3 through a NAT Gateway, sending API requests over the public internet. Which change reduces the threat surface by eliminating an internet-exposed path, rather than merely adding a control on top of an existing one?#
Options
Show answer
Replacing the NAT Gateway route for S3 with a VPC gateway endpoint for S3 reduces threat surface by removing an internet-exposed path. Traffic from the VPC to S3 then stays on the AWS network instead of crossing the public internet. WAF rules, SSE-KMS encryption, and IP allow-lists add controls but leave that internet path in place.
A VPC gateway endpoint for S3 routes traffic over the AWS internal network backbone, so the application's requests to S3 no longer leave the VPC through the NAT Gateway onto the public internet. That removes the internet-exposed egress path and the attack surface it creates. The other choices add protective controls: WAF rules inspect inbound web requests to the application, SSE-KMS encrypts data at rest, and an IP allow-list restricts who can call the bucket. None of them removes the public-internet path, so they harden the existing surface rather than reducing it.
You are designing the network and identity architecture for a multi-tenant SaaS application on AWS. The stack consists of: an internet-facing API layer, a set of microservices running in Amazon EKS, an Amazon RDS (PostgreSQL) database, access to Amazon S3 and Secrets Manager, and integration with a third-party payment processor via outbound HTTPS. The goal is to minimize the threat surface while preserving all required functionality. Propose an architecture that addresses network segmentation, egress control, identity and access management, and exposure minimization for cloud-service traffic.#
Show answer
Place the internet-facing entry point on a managed regional API layer (API Gateway, or an ALB in public subnets if needed) so nothing else is exposed to the internet. Run the EKS worker nodes and the RDS instance in private subnets with no internet route, and restrict security groups so EKS accepts traffic only from the entry point and RDS accepts connections only from the EKS security group. Reach S3 and Secrets Manager through VPC gateway and interface endpoints so that traffic stays on the AWS network and no NAT path is needed for those calls. Control egress for the payment processor by routing outbound traffic through AWS Network Firewall in a dedicated egress subnet, allowing HTTPS only to the processor's published domain or IP ranges and denying everything else; restrict worker-node security group outbound rules as a second layer. For identity, give each microservice its own IAM role through IAM Roles for Service Accounts (IRSA), scoped to the exact actions and resources it needs, using short-lived STS credentials instead of long-lived access keys. Receive the payment processor's callbacks through a single authenticated webhook on API Gateway that verifies an HMAC signature, so no inbound port is opened on the cluster. Store secrets in Secrets Manager, rotate them, and grant each service read access only to the secrets it needs.
The strongest answer minimizes exposure on four fronts at once: segmentation (only the entry point is public, EKS and RDS sit in private subnets, and security groups chain access tier by tier), egress control (the payment processor is the only external destination, enforced by a firewall that default-denies other outbound traffic), identity (IRSA gives each microservice a least-privilege role with short-lived STS credentials, so a stolen credential has a small blast radius), and exposure minimization (VPC endpoints keep AWS service calls off the public internet and the HMAC-verified webhook avoids opening any inbound cluster port). A sound answer must cover all four areas and must not rely on mechanisms that cannot do the job, such as attaching security groups to a NAT Gateway.
An organization is transitioning from a perimeter-based (castle-and-moat) security model to zero-trust. A security architect proposes several changes. Which one is fundamentally inconsistent with zero-trust principles?#
Options
Show answer
Removing internal firewalls because a VPN tunnel already authenticates users is fundamentally inconsistent with zero-trust. Zero-trust rejects the idea that network location or a single authenticated entry point implies trust. Every internal request still needs identity-based verification and segmentation, while micro-segmentation, per-call authorization, and just-in-time privileged access all reinforce zero-trust.
Zero-trust eliminates the assumption that being inside a network boundary implies trust. The proposal to remove internal firewalls because the VPN tunnel already authenticates users preserves the exact perimeter-model assumption zero-trust dismantles: a successful entry point is treated as sufficient proof of trustworthiness for everything behind it, and internal segmentation is dropped rather than strengthened. In a zero-trust model, every access request is authenticated and authorized based on identity and context, regardless of network position. Micro-segmentation limits lateral movement, per-call identity-based authorization embodies 'never trust, always verify', and just-in-time elevation with no standing admin rights minimizes standing access; all three align with zero-trust.
You are the lead security architect for a mid-size SaaS company (500 employees, hybrid workloads split between AWS and an on-prem data center for legacy systems). The current security model is perimeter-based: a VPN grants remote workers broad access to the internal network, a WAF and next-gen firewall sit in the DMZ, and the internal network is largely flat with implicit trust between services. Leadership has mandated a migration to zero trust within 18 months. Design a phased zero-trust architecture that addresses (1) identity and access, (2) network segmentation, (3) workload-to-workload communication, and (4) continuous monitoring. Identify the key trade-offs and risks of the migration and how you would mitigate them.#
Show answer
Phase 1, identity and access: Enforce SSO with MFA for all applications, make device posture (managed device, compliance state) an access condition, and replace VPN access to web applications with an identity-aware proxy or equivalent policy enforcement point. Access is evaluated per request using user identity, device posture, location and risk signals, and standing privileged access is replaced by just-in-time elevation with approval. Phase 2, network segmentation: Break the flat network into segments aligned to application tiers (presentation, application, data). Use default-deny between segments with explicit allow-list rules (host firewalls, cloud security groups, or service mesh network policy) for only the documented, required flows, so a compromised workload cannot move laterally. Phase 3, workload-to-workload trust: Give AWS workloads IAM roles with short-lived STS credentials and IMDSv2. For service-to-service calls across AWS and on-prem, issue cryptographic workload identities (for example SPIFFE/SPIRE SVIDs) and enforce mutual TLS through a service mesh, replacing IP-based trust. Legacy on-prem systems that cannot do mTLS sit behind an authenticating proxy at the segment boundary. Phase 4, continuous monitoring: Feed access logs, authentication events and policy decisions into a SIEM with UEBA, and evaluate risk continuously. Anomalous behavior such as impossible travel or bulk data access triggers step-up MFA or session revocation. Trade-offs and risks: (a) Latency from policy evaluation, mitigated by caching decisions with short TTLs and co-locating enforcement points with workloads. (b) Legacy incompatibility, mitigated by protocol-translation proxies and a longer timeline for those segments. (c) Operational complexity of fine-grained policy, mitigated by policy-as-code with peer review, testing and drift detection. (d) Coexistence during the transition, mitigated by running controls in monitor-only mode first, confirming no legitimate traffic is blocked, then enforcing segment by segment. (e) User friction from repeated MFA and device checks, mitigated by risk-based step-up and SSO. Success is measured by the share of requests evaluated by the policy engine (target 100%), mean time to detect lateral movement, the reduction in standing privileged accounts, and the number of segments enforcing default-deny.
A strong answer must cover all four pillars the prompt names (identity and access, network segmentation, workload-to-workload trust, continuous monitoring), sequence them into phases within the 18-month window, and name concrete trade-offs (latency, legacy compatibility, policy complexity, transition coexistence, user friction) each paired with a mitigation. Because the answer is an open architecture design rather than a single fact, it is graded on coverage and reasoning, which is why it stays a short-answer question with keyword support for offline grading.
You are the lead security architect for a financial services company migrating a regulated payment-processing workload to a hybrid multi-cloud environment (AWS + Azure + on-premises data center). The workload handles PCI-DSS in-scope cardholder data and must comply with both PCI-DSS v4.0 and SOX. Design a zero-trust security reference architecture covering: (1) identity and access management, (2) network microsegmentation, (3) data protection including encryption and key management, (4) continuous monitoring and threat detection, and (5) a secure CI/CD pipeline. For each domain, identify the specific controls, cloud-native services you would use, and the key architectural trade-offs you must accept.#
Show answer
Identity and access: Federate all human identity through a single IdP (Microsoft Entra ID or Okta) using SAML or OIDC. Enforce conditional access with MFA, device compliance, and risk-based step-up. Use just-in-time privileged elevation (AWS IAM Identity Center with temporary STS role assumption, or a PAM tool such as CyberArk) with no standing privileged access, and log every elevation. Workloads authenticate with cloud-native workload identity (AWS IAM roles, Azure managed identities) and no long-lived API keys in configuration. Cross-cloud access uses OIDC federation so one cloud can assume a role in the other without exchanging keys. Trade-off: one IdP gives one policy plane and less complexity, but it becomes a single point of compromise, so it needs phishing-resistant MFA, break-glass accounts, and monitoring of IdP sign-ins.
Network microsegmentation: Default-deny east-west traffic. Use security groups in AWS, NSGs and Azure Firewall in Azure, and a next-generation firewall with microsegmentation (for example VMware NSX) on-premises. Deploy a service mesh (Istio or Linkerd) for mTLS and per-request authorization between microservices. Reach cloud services through private endpoints (AWS PrivateLink, Azure Private Link) with no public-internet exposure. Trade-off: a service mesh adds latency and operational overhead and covers only mesh-attached workloads, so legacy and on-prem systems still need network-layer segmentation as a complementary enforcement plane.
Data protection and key management: Encrypt data at rest with customer-managed keys held in cloud KMS backed by FIPS-validated Level 3 HSMs (AWS CloudHSM, Azure Dedicated HSM). Encrypt data in transit with TLS 1.2 or later end to end. Use separate keys per environment and data classification, rotate keys on a defined schedule (quarterly, with automated rotation where supported), and enforce dual control over key custodians as PCI-DSS requires. Tokenize PANs where possible and store real cardholder data only in a separately vaulted environment. Keep regulated data in approved regions (AWS us-east-1 and us-west-2, Azure eastus and westus2) with no cross-border replication. Trade-off: native per-cloud KMS gives strong isolation but splits key governance across two vendors; BYOK from an on-prem HSM or a cloud-agnostic abstraction such as HashiCorp Vault Transit unifies control but adds an on-prem dependency and latency on every encrypt and decrypt operation.
Continuous monitoring: Centralize telemetry (VPC flow logs, AWS CloudTrail, Azure Activity logs, WAF logs, application audit logs) in a SIEM such as Microsoft Sentinel, ingesting AWS GuardDuty and Security Hub findings through connectors. Enable GuardDuty and Microsoft Defender for Cloud for anomaly detection, map detections to MITRE ATT&CK, and run a 24/7 SOC with playbooks. Automate containment, such as quarantining instances with Lambda or Azure Functions and revoking compromised credentials. Trade-off: one SIEM gives unified cross-cloud correlation but concentrates detection in one platform; a federated model with native tools first avoids lock-in but fragments visibility and complicates correlation.
Secure CI/CD: Keep all secrets in a dedicated vault (AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault), never in Git. Scan Terraform with checkov or tfsec, scan container images with Trivy before registry push, and block on critical CVEs. Sign images with Cosign and enforce admission control with OPA Gatekeeper so unsigned images are rejected at runtime. Authenticate pipelines to clouds with OIDC federation instead of long-lived deploy credentials. Separate build, staging, and production with least-privilege pipeline identities, run SCA and DAST in staging, and peer-review pipeline-as-code changes. Trade-off: scanning at every stage slows throughput, and blocking on critical CVEs can stall delivery when no upstream fix exists, so a documented compensating-control waiver process is needed.
A strong answer must cover all five domains (identity, microsegmentation, data protection with key management, monitoring, and CI/CD), name concrete controls and cloud-native services for each, and state the trade-off that each design choice introduces rather than only listing controls. The answer should also reflect the regulated context: PCI-DSS scope drives tokenization, dual control of keys, and approved-region data residency across AWS and Azure. Graders should check that every domain is addressed with a specific control and a stated cost, that current product names are used (Microsoft Entra ID, Microsoft Sentinel, Microsoft Defender for Cloud), and that the trade-offs are real consequences of the chosen design rather than generic remarks about scale or complexity.
In the NIST SP 800-207 Zero Trust Architecture reference model, the Policy Enforcement Point (PEP) and the Policy Decision Point (PDP, also called the Policy Engine) serve distinct roles. Which statement correctly describes their separation of concerns?#
Options
Show answer
In NIST SP 800-207, the Policy Enforcement Point intercepts access requests and enforces the decision at the resource boundary, while the Policy Decision Point (Policy Engine) evaluates identity, device posture, and other context against policy to decide access. Keeping decision logic centralized while enforcement stays local is the purpose of this separation.
NIST SP 800-207 defines the PDP (Policy Engine) as the component that evaluates signals such as identity, device posture, behavioral analytics, and other contextual data against policy to render an access decision. The PEP sits between the subject and the protected resource and enforces that decision (allow, deny, or require step-up authentication). The two are deliberately separated so that decision logic stays centralized and consistent while enforcement is local to each resource. The statement that gives the PDP the enforcement role and the PEP the evaluation role reverses the roles. The statement merging both into one microservice contradicts the architecture's separation principle. The statement splitting them as pure authentication versus authorization oversimplifies, because both participate in the full access-decision flow rather than a clean credential-versus-session boundary.
A multi-tier application on AWS has an internet-facing Application Load Balancer, twelve application servers each with an Elastic IP in public subnets, and a managed RDS database in a private subnet. The security team wants to reduce the externally reachable attack surface, meaning the set of components an unauthenticated internet user can directly attempt to connect to. Which single change removes the most components from that set?#
Options
Show answer
Moving the twelve application servers into private subnets and releasing their Elastic IPs removes the most components from the internet-reachable set, shrinking it from the load balancer plus twelve servers to the load balancer alone. WAF filters requests, mTLS secures internal traffic, GuardDuty detects threats, and RDS security group rules limit internal access, but none of these change which components accept connections from the internet.
The externally reachable set is every component an unauthenticated internet user can directly open a connection to. In the original design that set is the load balancer plus the twelve application servers, each with a public Elastic IP. Moving the servers to private subnets and releasing their Elastic IPs removes all twelve from the set, leaving only the load balancer, a net reduction of twelve. Attaching WAF to the load balancer filters requests but leaves the reachable set unchanged. Requiring mutual TLS changes how authenticated traffic is secured but does not change which components accept connections from the internet. Enabling GuardDuty adds detection and may shorten dwell time but removes nothing from the reachable set. Restricting the RDS security group to the application servers only limits internal access to a database that already sits in a private subnet, so it removes zero internet-reachable components.
A multinational financial-services firm operates a hybrid estate: ~60% on-premises data centers with flat internal L2/L3 networks, ~30% in AWS across shared VPCs per business unit, and ~10% SaaS (including the corporate IdP). Remote access uses a legacy IPSec VPN that drops users onto a trusted internal subnet; east-west traffic is largely unrestricted except for a few segmented DMZs. A recent red-team exercise demonstrated lateral pivoting from a compromised developer endpoint to a critical trade-settlement database in under 8 minutes. The CISO has mandated a migration to a zero-trust security architecture. Design the target-state zero-trust architecture and a 12–18 month migration plan. Your design must explicitly address: (a) the identity and access-control plane, (b) network segmentation, (c) data-centric controls, (d) visibility and telemetry, and (e) how you sequence the brownfield rollout without business disruption.#
Show answer
Identity & access plane: Introduce a centralized Policy Decision Point (PDP) that evaluates every access request against identity, device-posture, behavioral, and environmental signals. Each request is authenticated and authorized at a separate Policy Enforcement Point (PEP) — e.g., a reverse-proxy, ZTNA agent, or service-mesh sidecar — before any connection is proxied to the resource. Enforce phishing-resistant MFA for all human and machine principals. Sessions are per-request, not per-login: if device posture degrades or location changes, the PDP revokes the session immediately. Legacy apps that cannot speak modern auth protocols are fronted by an identity-aware proxy that bridges to the IdP and enforces the same PDP/PEP contract, so no resource is exempt from the trust evaluation pipeline. Network segmentation: Replace the flat internal network with microsegmentation. In AWS, implement per-workload segmentation using security groups tightened to least-privilege egress and a service mesh with mTLS and per-service authorization policies. On-premises, deploy host-based microsegmentation agents or a software-defined perimeter overlay so that east-west traffic requires re-authentication through the PEP — lateral movement without a valid trust decision is denied by default. Inter-VPC traffic flows through a transit gateway with network firewall policies, not peering with open routes. Data-centric controls: Classify all data assets (trade-settlement, PII, non-sensitive) and bind access policy to classification labels, not just network or identity attributes. Enforce encryption at rest (KMS-managed, per-tenant keys) and in transit (mTLS everywhere); integrate DLP scanning at the PEP so egress of classified data triggers block or alert. The PDP consults the data label when computing the trust decision, so a trusted user on an unmanaged device cannot access restricted data even if the network path is allowed. Visibility & telemetry: Log every trust decision — principal, device, resource, decision, reason — to a centralized SIEM. Feed signals (anomalous access patterns, posture changes, failed authentications) back to the PDP for adaptive trust scoring and automatic step-up or revocation. Integrate with SOAR for automated incident response: a confirmed compromise triggers isolation of the device and revocation of all its active sessions in one action. Migration sequencing (12–18 months, brownfield): Phase 0 (months 1–3): stand up the IdP hardening, PDP/PEP foundation, and SIEM integration in parallel with the existing VPN — no production traffic is cut over. Phase 1 (months 4–8): pilot ZTNA for one business unit's remote-access workforce and the highest-risk resource (trade-settlement DB); run VPN and ZTNA in parallel with dual-path access to validate. Phase 2 (months 9–14): extend to all remote access, then begin east-west microsegmentation in AWS (greenfield VPCs first, then brownfield). Phase 3 (months 15–18): on-premises microsegmentation rollout and VPN decommission. Each phase has a rollback plan: the legacy path remains available until the ZT path is validated at full load for 30 days. Define 'done' as: (a) no unauthenticated east-west path exists to a restricted asset, (b) every access decision is logged and scoreable, (c) the red-team pivot time exceeds the SLA for detection-and-isolation.
This is an open-ended architecture design problem with many valid technology stacks. It is therefore scored by the rubric below: an answer earns the weight for each criterion by containing the concrete, falsifiable artifact that criterion names — independent of which vendor or pattern it chooses. The five criteria together distinguish a genuine zero-trust migration from a vendor slide deck.
You are the principal security architect for a global financial-services firm that must run critical trading and settlement workloads across AWS (us-east-1) and Azure (West Europe) simultaneously for regulatory redundancy. The firm operates under MiFID II, GDPR, and SOC 2 Type II obligations. Design a security reference architecture that establishes a zero-trust posture across both clouds. Your design must address: (1) east-west network segmentation, (2) unified identity and access, (3) key management and encryption at rest, (4) data residency and compliance enforcement, and (5) continuous monitoring and drift detection. Specify the concrete cloud-native services, control planes, and policy mechanisms you would use.#
Show answer
Network segmentation: on AWS, each workload tier runs in its own VPC or subnet tier with per-service security groups that deny by default; on Azure, each tier sits in a VNet with NSGs and Application Security Groups, and all PaaS access goes through Azure Private Link private endpoints with public network access disabled. Cross-cloud traffic crosses a dedicated private connection (AWS Transit Gateway to Azure via ExpressRoute or a site-to-site VPN through a transit VNet) and is not a flat trust boundary. East-west hops are authenticated per workload with mTLS and SPIFFE identities from a service mesh (Istio or Linkerd on EKS, Istio-based Azure Service Mesh on AKS), with authorization policies keyed to those identities. Unified identity: one IdP (for example Okta or Entra ID) is the source of truth, federated to AWS IAM Identity Center via SAML and to Azure via OIDC/SAML. Humans get just-in-time access: time-bound STS sessions with short durations and Azure PIM eligible role activation, with no standing privileged roles. Break-glass accounts in each cloud have no standing permissions, require hardware-token MFA, and alert in real time on any use. Key management: AWS KMS customer managed keys backed by a CloudHSM-based custom key store (FIPS 140-2 Level 3 HSMs) in us-east-1, and Azure Key Vault Managed HSM in West Europe. Keys stay in their own cloud and HSM root; no key material crosses the cloud boundary. Envelope encryption protects data at rest (SSE-KMS on S3, disk encryption on EBS and Managed Disks, TDE with CMKs on databases). Keys use automatic rotation and the firm controls lifecycle and revocation through its own key policies. Data residency: infrastructure is defined in Terraform with region constraints; AWS Organizations SCPs and Azure Policy (allowed locations) deny resource creation outside the approved regions; cross-region auto-replicating features (such as Aurora Global Database or Cosmos DB multi-region writes) are disabled or limited to approved regions; Amazon Macie and Microsoft Purview classify PII and trade data in storage. Continuous monitoring: CloudTrail and Azure Activity/Monitor logs stream into a central SIEM such as Splunk; AWS Security Hub and Microsoft Defender for Cloud (or Wiz or Prisma Cloud) provide CSPM and CIEM. OPA or Conftest policies run in the CI/CD pipeline and block Terraform plans that violate the reference architecture. Scheduled drift detection (terraform plan against live state, or a CSPM drift rule) raises tickets for unmanaged resources and triggers automated quarantine, such as removing public exposure or security group and NSG associations, in production.
This is an open design question that a staff-level answer must cover across all five pillars with named cloud-native services, so it stays a SHORT_ANSWER graded against the keywords and the reference answer. The strong answer names concrete services per cloud (security groups, NSGs, Private Link, service mesh with SPIFFE identities, IAM Identity Center and Entra ID with JIT elevation, KMS and Key Vault Managed HSM with envelope encryption, SCPs and Azure Policy for residency, Security Hub or Defender for Cloud, a central SIEM, and OPA or Conftest with scheduled drift detection) and keeps each cloud's key material and identity controls in-cloud without flat cross-cloud trust.
Related interview questions
Job market
See cloud-security salaries and hiring demand from live job postings.
The other 2 questions
This page shows 25 and marks what you pick. That's as far as a page can go. A free account opens the other 2 and keeps every answer. What you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 marked answers per 30 days · written feedback on the paid plan