Card 1 of 50
Front. Shared Responsibility. Why must shared responsibility be evaluated per cloud service?
These cards are original study material. They are not questions from a named employer or a live hiring loop.
All 50 cards in this deck
1.Shared Responsibility
Why must shared responsibility be evaluated per cloud service?
The provider handles different layers for virtual machines, managed databases, and serverless platforms. Identify who configures identity, data access, patching, backups, and logging for the actual service rather than assuming managed means secured.
2.Asset Inventory
What makes a cloud asset inventory useful for security?
Include account/project, region, owner, purpose, exposure, identity, data sensitivity, and lifecycle. Reconcile discovery with declared infrastructure; unmanaged resources and abandoned test systems often retain real access.
3.Account Boundary
Why separate production and development into accounts or projects?
It creates stronger policy, credential, billing, and failure boundaries than naming conventions alone. Cross-account trust, shared identity administration, and network links still need explicit review.
4.Organization Policy
What does an organization-level permission guardrail usually constrain?
It limits what subordinate accounts or principals may be allowed to do under the provider's policy model. It generally does not itself grant access; evaluate it together with identity, resource, session, and other applicable policies.
5.Effective Permission
Why is reading one IAM policy insufficient to establish access?
Effective authorization can combine identity policies, resource policies, role trust, boundaries, session restrictions, and organization controls. Follow the provider's evaluation rules, including explicit denies and context conditions.
6.Wildcards
When is a wildcard permission materially risky?
When it covers actions, resources, or future capabilities beyond the workload's need, especially privilege escalation or data access. Evaluate the effective scope and conditions; replacing '*' with a long broad list is not necessarily safer.
7.Assume Role
How do a role's trust policy and permission policy differ?
The trust policy controls who may assume it and under what conditions; its permissions control what the assumed role may do. A tightly scoped trust relationship does not compensate for excessive granted actions.
8.External ID
What problem does an external ID address in cross-account role assumption?
It helps a third-party service distinguish customers and avoid acting as a confused deputy. It is a binding condition rather than a substitute for trusted principal selection, least privilege, and secure provider implementation.
9.Workload Federation
Why prefer federated short-lived workload credentials to static cloud keys in CI?
They reduce long-lived secret storage and bind access to a verifiable workload identity. The trust policy must restrict issuer, audience, repository/workflow context, and environment; federation with broad trust can still grant attackers access.
10.CI Claims
A cloud role trusts every workflow in an organization. What should be reviewed?
Whether untrusted repositories, pull requests, or reusable workflows can produce accepted identity claims. Bind production access to the intended repository, branch or protected environment, and workflow conditions using the platform's supported claims.
11.Permission Escalation
Why can permission to modify a function or pass a role become privilege escalation?
A caller may deploy code that runs with a more privileged workload role. Review chains of create/update/attach/assume capabilities and constrain both which roles can be passed and which workloads can use them.
12.Metadata
What does restricting instance metadata access protect?
It reduces paths for workloads or SSRF flaws to retrieve instance identity and credentials. Use provider-specific hardened metadata settings and least-privilege roles; metadata protection does not make a compromised privileged workload harmless.
13.Network Layer
Why is a private subnet not an authorization boundary by itself?
Any reachable workload may still be compromised, and private routes can connect many systems. Authenticate and authorize service requests, restrict lateral paths, and inspect egress as well as public exposure.
14.Security Group
What should a security-group review consider beyond inbound ports?
Source identities/ranges, outbound destinations, attached resources, rule ownership, and reachable paths through peering or load balancers. Stateful behavior and provider-specific semantics determine the actual connectivity.
15.Public Ip
Does removing a VM's public IP guarantee it is unreachable from the internet?
No. A public load balancer, proxy, tunnel, or other forwarding path may expose it. Model the full route and application authentication rather than evaluating only the interface address.
16.Egress
Why restrict outbound traffic from sensitive workloads?
It limits exfiltration and contact with unauthorized services after compromise. Account for DNS, redirects, proxies, update services, and legitimate dependencies; a destination allowlist alone cannot prevent misuse of an allowed endpoint.
17.Private Endpoint
What does a private service endpoint change, and what remains necessary?
It changes the network path to a managed service, often avoiding public routing. It does not automatically grant or restrict data authorization; identity policies, endpoint policies, and service configuration still matter.
18.Dns
How can cloud DNS configuration affect a security boundary?
Private zones, resolver forwarding, and split-horizon names influence which endpoints a workload reaches. Verify ownership and resolution paths, and do not treat an internal-looking hostname as evidence the destination is trusted.
19.Storage Public
How should you verify that an object store is not publicly readable?
Evaluate account-level public-access controls, bucket/container policies, object ACLs where used, access points, and signed-link mechanisms. Test an unauthorized request and review effective access rather than relying only on a console label.
20.Signed URL
Why is a signed object URL a credential?
Anyone possessing it may exercise its granted operation until expiry or revocation conditions apply. Scope it to the object and method, keep lifetimes short, and avoid leaking it through logs, referrers, or analytics.
21.Encryption at REST
What threat does storage encryption at rest not solve?
An authorized application or stolen credential may still read plaintext through normal APIs. Encryption protects specified storage/media threats; identity, query authorization, and exfiltration controls remain separate.
22.Kms Policy
Why must both key access and data access be reviewed?
A caller may need permission to read ciphertext and use the decryption key, with provider-specific policy interactions. Broad decrypt access can undermine data boundaries, while denying key use can also disrupt recovery and availability.
23.Envelope
How does envelope encryption separate data and key protection?
A data-encryption key encrypts the payload, and a key-encryption key protects that data key. The system stores the encrypted data key with the ciphertext and controls unwrap/decrypt operations through the key service.
24.Key Delete
Why is deleting an encryption key different from rotating it?
Deletion can make retained ciphertext permanently unrecoverable; rotation normally changes key material or active versions while retaining authorized decryption of older data. Check backups, retention, and recovery dependencies before deletion.
25.Secret Runtime
How should an application consume a rotated secret without interruption?
Retrieve it through a controlled identity, support the planned overlap or refresh mechanism, and test connection renewal. Updating the secret store alone does not update every process or invalidate every existing session.
26.Secret Log
Why can environment-variable secrets still leak?
They may appear in process dumps, debugging tools, crash reports, child processes, or application logs. Restrict introspection and redact output; choose secret delivery based on the workload rather than assuming runtime injection is complete protection.
27.Container Root
Why is running as non-root useful but insufficient for container isolation?
It reduces privileges available inside the container, but capabilities, mounts, kernel vulnerabilities, and runtime configuration also matter. Combine it with restricted capabilities, filesystem controls, and an appropriate isolation boundary.
28.Privileged Pod
What risk does a privileged Kubernetes pod introduce?
It can gain broad host capabilities and bypass normal container restrictions, making host compromise much easier. Avoid it for ordinary workloads and tightly constrain any justified exception, including who can create such pods.
29.Host Mount
Why are host filesystem and container-runtime socket mounts dangerous?
They can expose host secrets or control of other containers and the node. A read-only application directory is different from mounting the runtime socket; review the actual path, permissions, and reachable operations.
30.Service Token
Why should a pod not automatically receive broad cluster credentials?
Compromise of the application could become compromise of cluster resources. Use dedicated service accounts with minimal RBAC, disable unnecessary token mounting, and use bounded tokens where supported.
31.Network Policy
What must be true for a Kubernetes NetworkPolicy to restrict traffic?
The network implementation must enforce it, and the selected pods and ingress/egress rules must express the intended policy. Policies are additive; creating one policy does not automatically isolate every pod or protocol.
32.Admission
What can admission policy enforce before a workload starts?
Rules such as allowed registries, required signatures, privilege restrictions, and resource constraints. Admission is a preventive gate, not runtime detection, and bypass identities or excluded namespaces must be reviewed.
33.Image Digest
Why deploy a container by digest rather than a mutable tag?
The digest identifies a specific artifact, preventing a tag from silently resolving to different bytes. This improves integrity and repeatability but does not establish that the artifact is trustworthy or vulnerability-free.
34.Image Signature
What does verifying an image signature establish?
That the artifact digest was signed by an identity or key accepted by policy. Verify signer identity and build provenance where needed; a valid signature can still cover malicious or vulnerable software.
35.Build Provenance
What should build provenance let a reviewer connect?
An artifact digest to source revision, builder identity, build inputs, and execution context. Trust depends on how provenance is produced and protected, not merely whether a JSON attestation exists.
36.Untrusted Build
Why isolate pull-request builds from release credentials?
Contributor-controlled code can execute during builds, tests, or dependency installation. Use separate trust contexts, minimal token permissions, and controlled promotion so unreviewed code cannot obtain deployment authority.
37.Iac State
Why treat infrastructure-as-code state as sensitive?
It may contain resource identifiers, credentials, or other secret values, even when source files appear safe. Encrypt and restrict the backend, protect locking and backups, and review access to exported plans and logs.
38.Plan Review
What should a security review of an infrastructure plan inspect?
Privilege expansions, public exposure, destructive actions, data/key retention, and changes to logging or security controls. Validate the actual plan against policy; reviewing only the high-level source diff can miss provider effects.
39.Drift
How can out-of-band cloud changes undermine reviewed infrastructure?
Live permissions or exposure can diverge from versioned intent. Detect drift, determine whether it is an authorized emergency change or compromise, and reconcile deliberately rather than automatically overwriting evidence.
40.Control Plane Log
What should cloud audit logging capture for investigations?
Identity/session context, API action, target resource, time, source context, result, and relevant configuration changes. Confirm coverage across accounts and regions and distinguish management events from optional data-access logs.
41.Log Protection
Why store audit logs outside the workload's administrative boundary?
An attacker controlling the workload should not be able to delete or rewrite the evidence. Restrict log administration, monitor ingestion gaps, and use immutable retention where appropriate to the threat and retention policy.
42.Flow Log
What can network flow logs establish, and what can they not?
They summarize connections or packets with fields such as endpoints, ports, and accept/reject status. They generally do not reveal full application content or prove what data was exfiltrated; correlate with other telemetry.
43.Serverless
What security work remains in a serverless deployment?
Function permissions, dependencies, input validation, event-source authorization, secrets, egress, and data handling. Provider-managed hosts reduce one layer of maintenance without removing application or identity risk.
44.Queue Policy
Why authorize both producers and consumers of a cloud queue?
An unauthorized producer can inject work, and an unauthorized consumer can read or delete messages. Bind allowed identities and sources, validate payloads, and avoid treating queue delivery as proof of trusted business intent.
45.Backup Isolation
How do you keep a compromised production account from destroying recovery options?
Use appropriately isolated backup administration, immutable or protected retention, and tested cross-boundary restore access. A second copy under the same destructive credentials may fail in the same incident.
46.Restore Keys
A backup exists but cannot be restored. Which security dependencies may be missing?
Decryption keys, IAM permissions, service identities, network paths, or trusted images may no longer be available. Restore exercises must test those dependencies as well as the presence of backup bytes.
47.Posture Alert
Why is a posture scanner's critical finding not automatically the top incident?
Prioritize effective exposure, reachable attack paths, data sensitivity, exploitation evidence, and existing controls. Validate the finding promptly; a severity label is useful input rather than a complete risk decision.
48.Asset Owner
An exposed test database has no owner. What is the immediate response?
Determine data sensitivity and active dependencies, contain unnecessary access safely, and assign accountable ownership. Preserve evidence if compromise is suspected; deleting an unknown resource can destroy both service and investigation data.
49.Resource Abuse
How can cloud credentials cause harm without reading sensitive data?
An attacker may create expensive compute, exhaust quotas, or disable services. Restrict provisioning authority, monitor unusual resource creation and spend, and use service quotas with tested response procedures; budget alerts alone usually do not stop charges.
50.Cloud Review
What evidence should close a cloud-security remediation?
The intended configuration is deployed, effective permissions or reachability are tested, monitoring confirms the change, and dependent services still function. Record the scope and residual risk so a passing policy check is not mistaken for complete security.
