Cloud Security Interview Questions and Answers

Use a role in the bucket's account that the other account can assume. Or use a bucket policy that names the other account's principal. Often you use both, together with IAM policies on the caller's side.

• Bucket policy approach: the bucket policy allows arn:aws:iam::<other-account-id>:role/app-role. The caller also needs an IAM policy that allows s3:GetObject on that bucket. Cross-account access needs both sides to allow it.
• Role approach: create a role in the bucket-owner account with S3 permissions and a trust policy for the other account. The caller runs sts:AssumeRole and gets temporary credentials.
• For an ECS task or Lambda in another account, give the task role the S3 permissions. Then add that role to the bucket policy. No access keys are needed.

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::222222222222:role/app-task-role"},
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::my-bucket/data/*"
}

If objects are encrypted with a KMS key, the key policy must also allow the other account.

What they are checking: Whether you know cross-account access needs permission on both the resource and the caller, and prefer roles over keys

Shift security left: run automated checks at every stage of the pipeline. Fail the build on serious findings.

• Secret scan and dependency scan (SCA) on commit or PR: Gitleaks, npm audit, Trivy, Dependabot.
• SAST (static analysis of source code): SonarQube runs in the build stage. A quality gate fails the pipeline on new vulnerabilities.
• Container image scan: Trivy or ECR scanning before you push.
• DAST (testing the running app): deploy to a test environment, then run OWASP ZAP against it. Run a baseline scan on every build and a full scan every night.
• IaC scan: tfsec or Checkov for Terraform.

- name: ZAP baseline scan
  run: |
    docker run --rm -v $(pwd):/zap/wrk ghcr.io/zaproxy/zaproxy:stable       zap-baseline.py -t https://staging.example.com -r report.html

SAST finds code flaws without running the app. DAST finds runtime and config problems. Save the reports and review the findings. Otherwise teams start to ignore the noise.

What they are checking: Whether you have wired real security gates into a pipeline and know the SAST versus DAST difference

Yes. TLS gives confidentiality, integrity and server authentication. A man in the middle cannot read or change the payload without being detected.

Handshake in short (TLS 1.3):

1. The client sends the ciphers it supports and a key share.
2. The server replies with its certificate and its key share. The client checks the certificate chain against trusted CAs and checks the hostname.
3. Both sides work out the same session key with a temporary key exchange (ECDHE). Asymmetric crypto is used here. The server proves its identity by signing with its private key.
4. All application data is then encrypted with the fast symmetric key (AES-GCM or ChaCha20). It also adds an authentication tag that detects tampering.

So asymmetric crypto is used to prove identity and agree on a key. Symmetric crypto is used for the bulk data. Caveat: HTTPS protects data in transit only. A bad client can still send tampered input, so the server must validate it.

What they are checking: Whether you understand why TLS mixes asymmetric and symmetric crypto

Both filter traffic in a VPC, but at different levels.

Use security groups as the main control (the app tier allows only the ALB's group). Use NACLs as a rough extra layer, for example to block a bad IP range. Other protections: WAF and Shield at the edge, GuardDuty, VPC Flow Logs, private subnets and Security Hub.

What they are checking: Whether you know stateful versus stateless filtering and the layers of defence

Injection happens when untrusted input is sent to an interpreter as part of a command or query.

Common types: SQL injection, NoSQL injection (for example {"$ne": null} to bypass a login), OS command injection, LDAP injection, and XSS (script injected into pages).

JSON tampering: an attacker can edit any request body with a proxy such as Burp. For example:

• Change "price": 100 to 1.
• Change "role": "user" to "admin" (mass assignment).
• Change an id to read another user's data (IDOR).

HTTPS does not stop this, because the client itself is the attacker.

Defences:

• Use parameterised queries and ORMs. Never join strings to build queries.
• Do server-side validation against a schema. Allow only known fields. Ignore roles and prices sent by the client.
• Check authorisation on every object access.
• Escape output. Use a WAF as an extra layer. Give database accounts least privilege.

cur.execute("SELECT * FROM users WHERE email = %s", (email,))

What they are checking: Whether you know injection types and that the server must never trust client input

They are the identity types in AWS IAM.

• IAM role: an identity with permission policies. Something else assumes it to get temporary credentials.
• Trust policy: the role's resource policy. It says who may assume it (for example ec2.amazonaws.com, another account, or an OIDC provider). The permission policies say what it can do. -...

Never hardcode secrets in code, images or Git. Keep them in a secrets manager. Give the app permission to fetch them at runtime.

Encoding changes data into another format so systems can use it. There is no secret, and anyone can reverse it. Encryption changes data with a key, so only someone with the key can read it.

Use Let's Encrypt (free, automated, 90 day certificates) or the free managed certificates from your cloud provider.

By default every pod can talk to every pod. NetworkPolicy objects limit this. But they only work if the CNI supports them (Calico, Cilium, or VPC CNI with network policy turned on).

Approach: apply a default deny policy in the namespace. Then add explicit allows.

Use short-lived, limited credentials instead of shared passwords.

Nmap is an open source network scanner. It finds hosts, open ports, running services and their versions. Sometimes it also finds the operating system.

A SIEM (Security Information and Event Management) collects logs and events from many sources. It puts them in one format, links related events, and raises alerts on suspicious patterns.

The CIA triad is the three core goals of information security.

Vulnerability scanning is automated checking of systems, images, code dependencies or web apps for known weaknesses (CVEs, misconfigurations, missing patches). Tools: Trivy, Nessus, OpenVAS, AWS Inspector, OWASP ZAP. It finds known issues, it does not prove they are exploitable.

Use OIDC federation. The CI system issues a short-lived signed token. AWS trusts it. The pipeline swaps it for temporary credentials. No secret is stored in the CI.

Setup:

1. In IAM, create an OIDC identity provider for the CI issuer (for example token.actions.githubusercontent.com).
2. Create an IAM role. Its trust policy allows sts:AssumeRoleWithWebIdentity from that provider, with conditions on the token's sub (repo and branch) and aud.
3. Attach least-privilege permissions to the role.
4. The pipeline requests a token and assumes the role.

permissions:
  id-token: write
  contents: read
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::111111111111:role/ci-deploy
      aws-region: ap-south-1

For a registry or cluster in a different account, create the role in that account (or chain: assume a role in the target account). Allow the role in the ECR repository policy. Always pin the sub condition. Otherwise any repo could assume the role. Credentials expire in about an hour.

What they are checking: Whether you can replace static keys with federation and know to scope the trust policy tightly

Native Kubernetes Secrets are only base64-encoded. They are not encrypted. Treat them as a way to deliver secrets, and keep the real source somewhere else.

Options, from basic to better:

• Turn on encryption at rest for etcd (EKS: envelope encryption with KMS). Lock down RBAC so only a few people can get secrets.
• External Secrets Operator or the Secrets Store CSI driver sync from AWS Secrets Manager, SSM Parameter Store or Vault into pods. Rotation happens in one place.
• Sealed Secrets or SOPS let you commit encrypted secrets to Git for GitOps.
• Workload identity (IRSA or EKS Pod Identity) lets pods read the secret store with IAM roles, not stored keys.

Good practice:

• Mount secrets as files or env vars only in the pods that need them.
• Never bake them into images or Helm values in plain text.
• Use separate namespaces and RBAC per team.
• Rotate regularly and audit access.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
spec:
  secretStoreRef: {name: aws-sm, kind: ClusterSecretStore}
  target: {name: db-creds}
  data:
    - secretKey: password
      remoteRef: {key: prod/db, property: password}

What they are checking: Whether you know Kubernetes Secrets are not truly secret and can use an external store with workload identity

Create a dedicated service account. Give it a narrow role on the bucket, not on the project.

Give access through audited, temporary, identity-based paths. Do not use open ports and shared keys.

They work together: detection, vulnerability checks and one combined view.

Reduce exposure right away. Then do the proper fix.

S3 has no real folders. It has only key prefixes. So limit access with prefixes in IAM policies or bucket policies.

Cover the cluster, the workloads, the network and the supply chain.

Grant only the permissions needed, to only the identities that need them, for only as long as needed.

An identity-based policy is attached to the caller. It says what the caller can do. A resource-based policy is attached to the resource. It says who may use it.

Combine Kubernetes and network-level controls.

Attach roles so applications get temporary credentials automatically, with no access keys in code.

EC2: create a role with the permissions, wrap it in an instance profile and attach to the instance. The SDK picks credentials from the instance metadata service. Enforce IMDSv2.

Set up the foundations first, because they are hard to change later.

SOC 2 checks whether your controls meet the Trust Services Criteria (security, availability, confidentiality, processing integrity, privacy). It is about proving steady practice, not only having tools.

SSH key authentication uses an asymmetric key pair. The public key sits on the server. The private key never leaves your machine.

How it works: the client offers a public key that the server has in ~/.ssh/authorized_keys. Then it signs data unique to the session with the matching private key. The server checks that signature with the public key. The private key never crosses the network, and no password does either.

Handling private keys:

• Keep the .pem file at chmod 400. Never commit it to Git or share it over chat.
• Use a passphrase and ssh-agent on your laptop.
• Use one key per person, not a shared key. Remove keys when people leave.
• Better: avoid keys altogether with SSM Session Manager or EC2 Instance Connect. Access then goes through IAM and is logged, and port 22 can stay closed.
• If you must use SSH, limit the security group on port 22 to known IPs.

chmod 400 mykey.pem
ssh -i mykey.pem ec2-user@<public-ip>

What they are checking: Whether you understand asymmetric keys and know safer modern options like Session Manager

Start with the legal basics. Sign a Business Associate Agreement (BAA) with AWS. Use only HIPAA-eligible services for anything that touches PHI (protected health information). Then build the controls around that.

• Account structure: a separate AWS account for PHI workloads under AWS Organizations. Use service control policies to block risky actions.
• Network: private subnets for compute and databases. No public database endpoints. VPC endpoints for AWS services. A WAF and load balancer at the edge.
• Encryption: TLS in transit. KMS encryption at rest for S3, EBS, RDS and backups, with customer managed keys and key rotation.
• Access: least-privilege IAM roles, MFA, SSO, and no long-lived keys on servers.
• Audit and monitoring: CloudTrail in all regions with log file validation, AWS Config rules, GuardDuty and CloudWatch alarms. Keep logs in a locked-down bucket.
• Data handling: keep as little PHI as possible. Mask or de-identify it in non-production. Define how long to keep data. Test backups and disaster recovery.

Being HIPAA-eligible does not make an application compliant. It is a shared responsibility model. AWS secures the platform. You must set up and run your part correctly.

What they are checking: Whether you can combine compliance requirements with concrete AWS controls and the shared responsibility model

Use defence in depth: private networking, tight rules at each layer, encryption everywhere, and logging.

• Topology: public subnets hold only the load balancer. App and database tiers sit in private subnets with no public IPs. Reach AWS services through VPC endpoints.
• Security groups: chain them. The database allows only the app group. The app allows only the load balancer group.
• Load balancer: use HTTPS listeners with ACM certificates. Redirect HTTP to HTTPS. Use a modern TLS policy. Use WAF for OWASP rules and rate limiting. Limit origin access to the CDN. Turn on access logs.
• Encryption: TLS in transit, KMS at rest for databases and S3.
• Access: no direct DB access. Use SSM or VPN, IAM auth, and secrets in Secrets Manager.
• Sensitive data: classify it (Macie) and keep as little as possible. Mask it in logs. Limit it by data residency. Keep audit trails (CloudTrail, Config).
• Compliance: map controls to the standard (PCI, HIPAA, SOC 2). Automate checks with Config and Security Hub.

What they are checking: Whether you layer controls from edge to data rather than relying on one

Secure the whole path: build, registry, runtime and the host.

Work out who is calling, what action, on which resource. Then check each policy layer.

Do not patch a running container. Containers are immutable (you do not change them after they are built). Fix the image and redeploy.

Prefer a proven identity provider or framework over writing your own, and follow these basics.

Make sure the only way in is through the CDN or proxy. Also harden the instance itself.

Keep private resources (databases, internal APIs) in private subnets, and expose only a controlled entry point.