2. Secure Cloud Architecture and Threat ModelingIntroduction and ContextCloud security is not achieved by adding controls to an already deployed environment. It is achieved by designing the environment so that identity, connectivity, data, operations, and recovery are governed from the beginning. This distinction is important because cloud platforms expose organizations to both familiar and novel risks. Traditional threats such as credential theft, malware, insecure software, and data loss remain relevant, but cloud adoption introduces additional concerns: misconfigured storage, excessive permissions, vulnerable management interfaces, compromised automation pipelines, insecure service-to-service trust, and uncertainty about responsibility between provider and customer. A secure cloud architecture therefore combines structural decisions with continuous assurance. Structural decisions include how accounts, subscriptions, projects, networks, workloads, and data stores are organized. Assurance involves policies, logging, threat detection, vulnerability management, testing, and incident response. Threat modeling provides the analytical bridge between these two activities. It enables architects to ask what can go wrong, who might cause it, how an attack could progress, and which controls provide the greatest reduction in risk. This chapter presents a defense-in-depth approach to cloud architecture. It explains secure landing zones, account and subscription structures, policy guardrails, Zero Trust, least privilege, and the shared-responsibility model. It then applies STRIDE, attack trees, MITRE ATT&CK for Cloud, and Cloud Security Alliance guidance to the analysis of threats and abuse cases. The emphasis is not on one provider but on principles that can be implemented across public, private, hybrid, and multicloud environments. Learning ObjectivesAfter studying this chapter, the reader should be able to: 1. Explain the architectural purpose of a secure cloud landing zone. 2. Design account, subscription, project, identity, and network structures that support isolation and governance. 3. Distinguish preventive, detective, corrective, and compensating controls in a defense-in-depth architecture. 4. Apply Zero Trust and least-privilege principles to human, machine, and service identities. 5. Use STRIDE, attack trees, MITRE ATT&CK for Cloud, and CSA guidance to model cloud threats. 6. Develop abuse cases and translate them into security requirements and architectural controls. 7. Evaluate trade-offs involving security, cost, availability, usability, performance, and operational complexity. 8. Recognize common architecture mistakes and recommend improvements. The Architecture of Trust in the CloudCloud architecture should be understood as a set of trust relationships rather than merely a collection of technical services. A user trusts an identity provider to authenticate a person. A workload trusts a secret-management service to release credentials. An application trusts a database to preserve confidentiality and integrity. An organization trusts the cloud provider to operate physical facilities and foundational services. Each trust relationship is a potential control boundary and a potential attack path. The shared-responsibility model divides security obligations between the cloud service provider and the customer. The provider normally protects the physical facilities, hardware, and foundational services. The customer remains responsible, to varying degrees according to the service model, for identities, configurations, data, access permissions, applications, and endpoint security. Infrastructure as a Service generally leaves more operational responsibility with the customer than Platform as a Service, while Software as a Service transfers more infrastructure responsibility to the provider without eliminating customer obligations concerning accounts, data, configuration, and governance. Shared responsibility is not the same as shared accountability. A provider may operate a secure storage service, but the customer is still accountable for deciding whether a data repository is public, encrypted, appropriately retained, and accessible only to authorized workloads. Architecture must therefore make responsibility explicit through control ownership, service-level agreements, evidence requirements, and escalation procedures. Defense in DepthDefense in depth uses multiple, partially independent safeguards so that failure of one control does not automatically produce compromise. In a cloud environment, layers may include: - strong identity proofing and multifactor authentication;
- privileged access management and just-in-time administration;
- network segmentation and private service connectivity;
- secure application design and software supply-chain controls;
- encryption in transit and at rest;
- centralized logging, detection, and alerting;
- immutable backup and tested recovery;
- policy-as-code and configuration monitoring; and
- incident response procedures supported by rehearsals.
The value of layered controls depends on diversity and independence. Five alerts generated by the same misconfigured sensor do not constitute five independent defenses. Similarly, network segmentation cannot compensate for unrestricted administrative identities, and encryption cannot prevent an authorized but malicious user from reading decrypted data. Effective architecture combines preventive controls with visibility and recovery capabilities. Secure Landing ZonesA secure landing zone is a governed, repeatable foundation into which cloud workloads can be deployed. It is not a single network template. It is an architectural baseline that establishes identity, organizational hierarchy, networking, logging, security services, policy, and operational processes before application teams begin large-scale deployment. A landing zone commonly contains a management or organization layer, dedicated security and audit functions, shared networking, workload environments, and separate areas for development, testing, and production. The exact terminology differs among providers, but the design objective is consistent: separate functions according to risk and administrative purpose while maintaining centralized governance. A mature landing zone typically establishes the following capabilities: Identity foundation. A central identity provider, federated workforce access, multifactor authentication, role-based access, privileged access workflows, and lifecycle processes for joiners, movers, and leavers. Organizational separation. Production, non-production, security, logging, networking, and sandbox environments are placed in distinct accounts, subscriptions, or projects where practical. Separation limits blast radius and makes policy application clearer. Network foundation. Address allocation, routing, ingress and egress controls, private connectivity, DNS, firewall policy, and inspection points are designed centrally, while application teams receive controlled interfaces for workload connectivity. Security and audit services. Logs are sent to a separate, access-restricted destination. Security findings, configuration assessments, vulnerability data, and incident records are centrally correlated. Policy guardrails. Rules prohibit or constrain high-risk activity, such as disabling audit logs, creating public storage, using unapproved regions, deploying without encryption, or granting unrestricted administrative permissions. Automation and templates. Infrastructure is deployed through version-controlled templates and pipelines that perform validation, policy checks, testing, and approval. Manual configuration is minimized because undocumented changes are difficult to assess and reproduce. Landing zones should not become rigid barriers to innovation. A useful design distinguishes mandatory controls from configurable patterns. For example, encryption, logging, and identity federation may be mandatory, while the choice between two approved database services may remain with the application team. This balance is often described as centralized governance with delegated implementation. Account, Subscription, and Project StructuresThe administrative boundary is one of the most consequential design choices in cloud security. Organizations can isolate workloads by account, subscription, project, resource group, virtual network, or application namespace. These mechanisms do not provide identical security properties. A separate account or subscription commonly provides a stronger boundary for billing, policy inheritance, quotas, and administrative access than a mere logical grouping within the same administrative container. Separation should be based on risk and operational need. High-value production systems, regulated data, security tooling, and centralized logs generally merit stronger isolation. Development environments should not automatically have access to production data. Security administrators should be able to investigate workloads without receiving unrestricted rights to modify them. Dedicated security and audit environments reduce the risk that an attacker who compromises a workload can erase evidence. Over-segmentation also creates problems. Excessive accounts can produce duplicated controls, complex networking, inconsistent policy, and administrative fatigue. The appropriate question is not how many accounts an organization can create, but which boundaries reduce meaningful attack paths and simplify accountability. A useful design principle is to separate where trust, lifecycle, risk, or ownership differs, and to consolidate where separation would add complexity without reducing risk. Policy Guardrails and Control AutomationPolicy guardrails are enforceable constraints that prevent or identify unacceptable configurations. Preventive guardrails may deny creation of public storage, require approved regions, enforce encryption, restrict use of privileged roles, or require resource tags. Detective guardrails identify violations after deployment and initiate notification, remediation, or quarantine. Policies should be expressed as code where possible. A policy-as-code workflow can evaluate infrastructure templates before deployment, continuously scan deployed resources, and record exceptions with an owner, justification, expiry date, and compensating control. Exceptions are necessary in real environments, but permanent informal exceptions convert governance into preference. A guardrail must be assessed for scope, bypass resistance, operational effect, and evidence. A rule that blocks legitimate emergency response without an approved break-glass process may encourage administrators to circumvent it. Conversely, a rule that generates thousands of low-value findings will be ignored. Good governance therefore combines policy design with metrics such as violation age, exception duration, remediation time, and recurrence. Zero Trust and Least PrivilegeZero Trust is an architectural approach in which access is not granted merely because a request originates inside a corporate network or cloud virtual network. Each request is evaluated using relevant signals such as identity, device posture, workload identity, resource, action, location, time, and risk. The principle is commonly summarized as “never trust, always verify,” although verification is not a single event; it is a continuing process. In cloud environments, Zero Trust applies to human users, applications, containers, functions, automation pipelines, and service accounts. A workload should not receive broad permissions simply because it is located in a trusted subnet. A deployment pipeline should be authorized to update a particular service in a particular environment, not to administer the entire organization. Least privilege means granting only the permissions necessary for an identity to perform an authorized task, for only as long as necessary. It involves several dimensions: - Scope: resource-level permissions are preferable to account-wide permissions.
- Action: read, write, delete, and administrative actions should be separated.
- Time: temporary elevation is preferable to permanent privilege.
- Context: access can depend on device, network, authentication strength, and risk.
- Purpose: identities should be separated by function rather than shared among teams or applications.
Least privilege is difficult because permissions accumulate. Access reviews, entitlement analysis, permission-use data, and automated removal are therefore required. A role that appears minimal on paper may still be dangerous if it can alter identity policies, disable logging, or assume another privileged role. Privilege analysis must consider effective permissions and transitive trust, not only the permissions listed directly on an identity. Threat Modeling as an Architectural DisciplineThreat modeling is a structured method for identifying threats, vulnerabilities, attack paths, security requirements, and residual risk. It should begin during architecture and continue when systems, providers, data flows, or business processes change. The purpose is not to predict every attack. It is to make assumptions explicit and prioritize controls against credible misuse. A practical cloud threat-modeling process includes: 1. Define scope, business objectives, compliance obligations, and trust boundaries. 2. Inventory assets, identities, data stores, services, interfaces, and dependencies. 3. Draw data-flow and privilege-flow diagrams, including management-plane activity. 4. Identify entry points, exits, trust transitions, and concentration points. 5. Generate threats and abuse cases using more than one analytical method. 6. Assess likelihood, impact, exploitability, and control effectiveness. 7. Select preventive, detective, responsive, and recovery requirements. 8. Validate assumptions through testing, review, and adversarial exercises. 9. Track residual risk, ownership, and changes over the system lifecycle. Cloud threat models must include the control plane. The management plane can create identities, alter network routes, change storage permissions, disable logging, or deploy code. An application may be secure at the data plane while the identity able to administer it remains compromised. Management APIs, command-line tools, infrastructure pipelines, and provider consoles are therefore first-class attack surfaces. STRIDE in Cloud SystemsSTRIDE categorizes threats as spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Spoofing may involve stolen access tokens, compromised service identities, or forged workload credentials. Controls include strong authentication, short-lived tokens, workload identity, and anomaly detection. Tampering includes unauthorized modification of infrastructure templates, container images, routing rules, policies, or stored data. Controls include signed artifacts, protected branches, change approval, integrity monitoring, and separation of duties. Repudiation concerns the inability to prove who performed an action. Centralized, protected, time-synchronized logs and immutable audit trails are essential. Information disclosure may result from public storage, excessive permissions, misrouted traffic, exposed secrets, or insecure snapshots. Data classification, access control, encryption, and discovery tools reduce this risk. Denial of service may involve traffic floods, resource exhaustion, destructive administrative actions, or abuse of autoscaling. Rate limits, quotas, redundancy, protective services, and recovery plans are relevant controls. Elevation of privilege can occur when a user exploits an overly broad role, a vulnerable workload, a role-assumption path, or a pipeline with excessive authority. Privilege boundaries, permission analysis, and just-in-time access address this category. STRIDE is useful for systematic coverage, but it does not by itself rank business impact or describe a complete attack campaign. It should therefore be combined with attack trees and adversary-oriented knowledge. Attack Trees and Abuse CasesAn attack tree begins with an attacker objective, such as “obtain sensitive customer records,” and decomposes it into alternative or sequential conditions. The attacker might exploit a public storage endpoint, compromise a privileged identity, access a backup, or compromise an application that can query the database. Each branch can be assessed for prerequisites, cost, detectability, and control coverage. Abuse cases express legitimate functionality from an adversarial perspective. For example: “An attacker who compromises a developer identity uses an approved deployment pipeline to introduce code into production.” This abuse case reveals that authentication alone is insufficient. The architecture may need protected production branches, independent approvals, workload identity, artifact signing, deployment provenance, and monitoring of unusual changes. MITRE ATT&CK for Cloud and CSA GuidanceMITRE ATT&CK for Cloud provides an adversary-oriented vocabulary for tactics and techniques involving cloud accounts, identities, applications, data, and management interfaces. It supports detection engineering, threat-informed defense, and mapping observed behavior to an attack lifecycle. Examples of relevant behaviors include valid-account use, additional cloud role assignment, abuse of cloud service dashboards, collection from cloud storage, and exfiltration through legitimate services. ATT&CK should not be treated as a checklist of vulnerabilities. It describes adversary behaviors, allowing defenders to ask whether telemetry and controls would identify or prevent each behavior. A useful exercise maps attack techniques to identity logs, control-plane events, network telemetry, data-access records, and response playbooks. Cloud Security Alliance guidance emphasizes governance, identity and access management, data security, application security, resilience, compliance, and the cloud control matrix. The Cloud Controls Matrix can help map architectural requirements to control domains and provider responsibilities. Used together, STRIDE identifies categories of failure, attack trees expose paths to objectives, ATT&CK describes adversary behavior, and CSA guidance assists with governance and control completeness. Applied Design: From Threat to ControlConsider a cloud-hosted payment application. Its public web tier communicates with private application services, which access a payment database and an object store containing transaction documents. Administrators use a federated identity provider, while a continuous delivery pipeline deploys infrastructure and application code. A threat model may identify the following abuse cases: - An attacker steals a developer token and reads production documents.
- A compromised pipeline modifies a firewall rule and exposes the database.
- An administrator disables audit logging before extracting data.
- A vulnerable web service uses its workload identity to access unrelated storage.
- A malicious insider downloads excessive transaction records through a legitimate interface.
The architectural response should be layered. Production should be isolated from development accounts. Developers should not receive direct production-data access. The application should use a narrowly scoped workload identity, with separate identities for document access and database access. The pipeline should deploy through an approved role, require protected approvals for production, and use signed artifacts. Logs should be sent to a separate security account where workload administrators cannot delete them. Storage should be private, encrypted, monitored for anomalous access, and governed by retention rules. Data-loss prevention and query monitoring can address authorized-but-abusive access. This example illustrates an important principle: a threat is not “solved” by one control. The design reduces the probability of compromise, limits the blast radius if compromise occurs, detects suspicious behavior, and supports recovery and investigation. Illustrative Case Study: Northbridge Health ServicesBackgroundNorthbridge Health Services, a fictional regional healthcare organization, moved patient scheduling and diagnostic-document services to a public cloud. Its initial migration placed development and production workloads in a common subscription. Engineers used shared administrative accounts, logs were retained in the same environment as application resources, and a storage repository was made publicly readable during a troubleshooting exercise. Situation and AnalysisA security review found that a developer role could assume a production administrator role through a chain of permissions. The deployment pipeline also possessed permissions to change identity policies. Although multifactor authentication was enabled for workforce users, long-lived access keys remained active for automation. Threat modeling identified spoofing, information disclosure, tampering, repudiation, and elevation-of-privilege risks. An attack tree showed that compromise of one developer credential could lead to production access, log deletion, and document disclosure. Strategy and SolutionNorthbridge created separate organizational units for production, non-production, security, and shared services. Production workloads were moved into dedicated subscriptions. A centralized identity provider replaced shared accounts, and privileged access became time-limited and approval-based. Workload identities replaced long-lived application keys. The organization introduced preventive policies requiring encryption, approved regions, private storage, and centralized logging. Audit logs were replicated to a security-controlled destination with restricted deletion rights. The pipeline was divided into build and deployment roles; production deployment required protected approval and signed artifacts. Developers received masked test data rather than production records. Continuous configuration assessment and permission-use reviews were added to operations. OutcomeThe architecture reduced the number of identities with standing administrative access, improved evidence quality, and limited the impact of a compromised development account. The organization did not assume that preventive policies would eliminate all risk. It tested incident response by simulating stolen credentials and verified that security personnel could identify unusual role assumption, storage access, and policy changes. Learning PointsThe case demonstrates that secure architecture is organizational as well as technical. Account separation, identity governance, protected logging, pipeline controls, and data minimization addressed different parts of the attack path. It also shows why a landing zone should precede large-scale migration and why threat modeling must include automation and administrative operations. Challenges, Limitations, and Common MistakesA frequent mistake is treating cloud security as a network-perimeter problem. Private subnets and firewalls are valuable, but they do not control compromised identities or malicious service-to-service calls. Another mistake is creating a central security team that has unrestricted access everywhere. Investigation access should be powerful enough to collect evidence but constrained against unnecessary modification. Organizations also overuse broad roles for convenience, retain dormant accounts, and fail to review role-assumption chains. They may enable logging without protecting the logs, deploy encryption without managing keys properly, or purchase detection tools without assigning response ownership. Alert volume, policy exceptions, and manual infrastructure changes can undermine otherwise sound designs. Threat modeling has limitations. Models depend on assumptions, may omit provider-side failures or business-process abuse, and can become obsolete as services change. STRIDE may underemphasize economic motivation; attack trees may become unwieldy; ATT&CK mappings may create a false impression of coverage. These limitations are managed through periodic review, independent assessment, penetration testing, tabletop exercises, and measurement of control performance. Governance, Ethics, and Professional ResponsibilityCloud architects handle personal, financial, health, and operational data whose misuse can harm individuals and communities. Security decisions should therefore reflect data minimization, purpose limitation, proportional monitoring, retention limits, and respect for privacy. Continuous monitoring should be transparent, access to security telemetry should be controlled, and investigations should follow authorized procedures. Governance must address data residency, contractual obligations, breach notification, records retention, regulatory requirements, and provider concentration risk. Organizations should document provider dependencies, exit strategies, recovery objectives, and evidence responsibilities. Ethical practice also requires resisting unsafe shortcuts: disabling controls for convenience, sharing credentials during incidents, or collecting excessive data merely because cloud storage is inexpensive. Automation, Analytics, and Emerging DevelopmentsInfrastructure as code, policy-as-code, automated identity lifecycle management, and continuous compliance assessment are now central to cloud assurance. Analytics can identify unusual role assumptions, impossible travel, anomalous data downloads, changes to logging configuration, and deviations from normal deployment patterns. Machine-learning systems can support prioritization, but their outputs require validation because abnormal behavior is not always malicious and normal behavior can still be dangerous. Emerging architectures increasingly use ephemeral workloads, confidential computing, software supply-chain attestations, identity-aware proxies, and expanded use of workload identity. Multicloud and hybrid designs require consistent control objectives rather than assuming that identical technical implementations are possible everywhere. Generative AI services introduce additional concerns involving prompt data, model access, plugin permissions, training-data leakage, and machine identities. These developments strengthen the need for durable principles: explicit trust, least privilege, verifiable provenance, protected telemetry, and tested recovery. Best-Practice Design PrinciplesA defensible cloud architecture should: 1. Establish a governed landing zone before broad workload deployment. 2. Separate production, development, security, and audit functions according to risk. 3. Federate human identity and eliminate shared administrative accounts. 4. Use short-lived, narrowly scoped workload identities. 5. Treat management-plane APIs and pipelines as critical attack surfaces. 6. Enforce baseline requirements through policy-as-code and monitor exceptions. 7. Centralize and protect logs outside the administrative reach of workloads. 8. Combine preventive, detective, responsive, and recovery controls. 9. Model threats with both system-oriented and adversary-oriented methods. 10. Reassess the model whenever architecture, data, providers, or business processes change. 11. Test recovery, privileged access, detection, and incident response rather than merely documenting them. 12. Measure control effectiveness through evidence, not through tool ownership or policy count. Chapter SummarySecure cloud architecture begins with deliberate trust boundaries, clear responsibility, and a repeatable landing zone. Account or subscription separation, centralized identity, policy guardrails, protected logging, and automated deployment reduce the blast radius of failures. Zero Trust rejects implicit trust based on network location, while least privilege limits the scope and duration of access for people, applications, and automation. Threat modeling converts architectural assumptions into analyzable risks. STRIDE provides systematic threat categories; attack trees reveal alternative paths to an attacker objective; MITRE ATT&CK for Cloud describes adversary behaviors; and CSA guidance supports governance and control mapping. These methods are most effective when combined with data-flow analysis, privilege-flow analysis, abuse cases, continuous monitoring, and tested recovery. The central professional lesson is that cloud security is a lifecycle discipline: architecture, implementation, operations, and governance must continuously reinforce one another. Key TermsSecure landing zone: A governed cloud foundation containing baseline identity, networking, logging, policy, and operational controls. Shared-responsibility model: The allocation of security duties between a cloud provider and its customer. Defense in depth: The use of multiple complementary controls so one failure does not cause total compromise. Trust boundary: A point where assumptions about identity, authority, data, or control change. Policy guardrail: An enforceable rule that prevents, detects, or remediates unacceptable cloud activity. Policy-as-code: The expression and automated enforcement of governance rules in machine-readable form. Zero Trust: An approach that requires explicit, context-aware verification rather than implicit trust. Least privilege: Granting only the permissions, scope, and duration required for an authorized task. Workload identity: A non-human identity assigned to an application, service, function, or automated process. Management plane: Interfaces and services used to create, configure, administer, or delete cloud resources. Data plane: The interfaces and services used by workloads to process or access operational data. STRIDE: A threat-classification model covering spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Attack tree: A hierarchical representation of alternative paths to an attacker’s objective. Abuse case: A description of how legitimate functionality may be misused to harm a system or organization. MITRE ATT&CK for Cloud: A knowledge base describing adversary tactics and techniques relevant to cloud environments. Cloud Security Alliance: An industry body that publishes cloud-security guidance and control frameworks. Blast radius: The extent of damage or access possible after a security failure. Break-glass access: Exceptional emergency access subject to strict control, monitoring, and review. Residual risk: Risk remaining after controls have been implemented. Security exception: An approved, documented deviation from a required security control. Review QuestionsShort Answer Questions1. What is the purpose of a secure cloud landing zone? 2. Distinguish the management plane from the data plane. 3. Explain the relationship between Zero Trust and least privilege. 4. What is a policy guardrail, and how does policy-as-code support it? 5. Define an abuse case in cloud threat modeling. Long Answer Questions1. Explain how account or subscription structures can reduce cloud risk while avoiding unnecessary administrative complexity. 2. Discuss the shared-responsibility model and explain why customer accountability remains important when a provider operates the underlying service. 3. Describe a defense-in-depth architecture for a cloud-hosted application containing public, application, database, and logging components. 4. Compare STRIDE, attack trees, MITRE ATT&CK for Cloud, and CSA guidance as threat-modeling resources. 5. Explain how identity, pipelines, logging, and workload permissions should be designed in a Zero Trust cloud architecture. Analytical / Application Questions1. A developer account can deploy code to production, modify identity policies, and delete audit logs. Construct an attack tree for this situation and recommend controls at each major branch. 2. Design a landing-zone structure for an organization operating regulated production workloads, experimental applications, centralized security tooling, and shared networking. Justify each major boundary. 3. A cloud storage repository is accidentally made public during an incident investigation. Apply STRIDE and the shared-responsibility model to analyze the event, then propose preventive, detective, and corrective controls. 22. Multiple Choice Questions with AnswersQuestion 1Which feature most directly characterizes a secure cloud landing zone? A. A single large network in which all teams deploy freely B. A governed foundation for identity, policy, networking, logging, and operations C. A backup repository used only after an incident D. A provider-managed physical data center Correct Answer: B. A governed foundation for identity, policy, networking, logging, and operations Question 2Why should security and audit logs generally be stored outside the workload account or subscription? A. To increase application latency B. To allow developers to modify evidence quickly C. To reduce the ability of a compromised workload to delete or alter evidence D. To eliminate the need for incident response Correct Answer: C. To reduce the ability of a compromised workload to delete or alter evidence Question 3Which example best demonstrates least privilege? A. Giving every developer organization-wide administrator access B. Using one shared account for all deployment activities C. Granting a pipeline permission to update only its approved production service D. Allowing a workload to access all storage because it is in a private subnet Correct Answer: C. Granting a pipeline permission to update only its approved production service Question 4A compromised identity is used to change firewall rules and expose a database. Which STRIDE category is most directly represented by the unauthorized configuration change? A. Tampering B. Spoofing C. Repudiation D. Denial of service Correct Answer: A. Tampering Question 5What is the principal purpose of an attack tree? A. To list all cloud provider products B. To represent alternative paths toward an attacker objective C. To replace access reviews D. To calculate storage costs Correct Answer: B. To represent alternative paths toward an attacker objective Question 6Which statement best reflects Zero Trust in a cloud environment? A. Any workload inside a private subnet is trusted B. Users are trusted permanently after first authentication C. Each request is evaluated using identity, context, resource, and risk D. Only internet traffic requires verification Correct Answer: C. Each request is evaluated using identity, context, resource, and risk Question 7A deployment pipeline has permission to change identity policies even though it only needs to deploy application code. What is the primary architectural concern? A. Excessive privilege and an expanded blast radius B. Insufficient data compression C. Weak physical security at the provider D. Excessive backup retention Correct Answer: A. Excessive privilege and an expanded blast radius Question 8How should MITRE ATT&CK for Cloud primarily be used in threat-informed defense? A. As a catalog of cloud pricing tiers B. As a vocabulary for adversary behaviors, detection, and control mapping C. As a replacement for encryption standards D. As proof that an environment is risk-free Correct Answer: B. As a vocabulary for adversary behaviors, detection, and control mapping Question 9Which practice most effectively limits the risk of long-lived application credentials? A. Embedding credentials in source code B. Sharing one key among multiple services C. Using short-lived workload identity and managed secret mechanisms D. Disabling audit logging for service accounts Correct Answer: C. Using short-lived workload identity and managed secret mechanisms Question 10Why should threat models be revisited after a major change in provider, data, or architecture? A. Threat models are valid only for physical infrastructure B. Changes can create new trust boundaries, attack surfaces, and assumptions C. Revisiting models removes the need for testing D. Cloud services cannot be monitored after deployment Correct Answer: B. Changes can create new trust boundaries, attack surfaces, and assumptions
|
