Identity, secrets, supply chain and adversarial risk.
40 items · all topics
Explain how AWS IAM Role assumption works across different AWS accounts securely.
One account can use another account's resources without a password or an access key ever changing hands. The role's trust policy decides who is allowed in, its permissions policy decides what they can do once they're there, and STS hands out credentials that expire on their own.
Your EC2 instances in a private subnet need to reach S3 and a third-party API, but must never be reachable from the internet. Design the networking.
Outbound-only access comes from a NAT Gateway in a public subnet, but S3 traffic should skip it entirely through a VPC endpoint, which is free and never leaves the AWS network. Nothing can reach in because there's no route for it to take, not because a rule is blocking it, and that distinction is usually the real follow-up question.
A subnet holds your most sensitive data. Design the Network ACL rules around it as a second layer of defense behind Security Groups.
A NACL earns its place by doing the one thing a Security Group can't: an explicit, subnet-wide deny that survives a misconfigured Security Group rule. The design is a default-deny rule set with narrow, numbered exceptions, remembering that NACLs are stateless, so return traffic on ephemeral ports needs its own explicit allow.
Multiple teams share one AWS account. How do you structure IAM so each team can only touch the resources they own?
Individual users each get their own IAM role via SSO federation, never a shared login or a long-lived access key, and permissions are grouped by team into roles scoped with resource tags rather than hardcoded ARNs. Past a certain team count, the real fix is separate AWS accounts per team, not tighter policies inside one shared account.
How do you make sure data is encrypted everywhere it lives in AWS, both at rest and in transit, without it becoming a project unto itself?
At rest, nearly every AWS storage service takes a KMS key as a one-time setting at creation, and the actual work is deciding who can use that key, not the encryption itself. In transit, TLS terminated with a Certificate Manager certificate covers the external hop, but internal service-to- service traffic needs its own explicit decision, since nothing enforces it by default.
Design layered protection for a public-facing web application against DDoS attacks and common web exploits.
No single AWS service handles both problems, since a volumetric DDoS attack and a targeted web exploit look nothing alike at the network layer. CloudFront and Shield absorb and dilute volume before it reaches your origin, and WAF inspects individual requests for exploit patterns. Both sit in front of the origin, stacked, not swapped for each other.
How do you continuously monitor an AWS account for security and compliance drift, instead of only finding out during an annual audit?
Point-in-time audits catch a configuration that was wrong when someone happened to look. AWS Config evaluates resources continuously against rules and records every configuration change, CloudTrail records who made it, and Security Hub aggregates both into one place with a severity score so drift gets flagged the hour it happens, not the quarter someone checks.
How do you safely rotate IAM credentials or database secrets without downtime?
The safe pattern is overlapping validity. Create the new secret while the old one still works, get code that accepts either one deployed everywhere, confirm the new one is actually being used, then revoke the old one. Rotating in a single step guarantees a window where something is still holding a credential that no longer works.
You accidentally committed a .env file containing API keys. What do you do?
Rotate the credentials first. That's the only step that actually makes you safe, since the secret is already in every clone, fork and CI cache that pulled before you noticed. Cleaning up Git history is a second, separate job that comes after.
A secret was committed six months ago and exists in hundreds of commits. What do you do?
Treat it as a security incident, not a Git cleanup task. Rotate first, then work out the blast radius, then decide honestly whether rewriting history is worth the cost. The rewrite is the most visible part of the response and the least important one.
Your organization wants signed commits for production code. How would you implement it?
git config user.email is free text, not identity, so signing is what turns authorship into a cryptographic claim. Roll out SSH signing, enforce it with branch protection and a trusted-key list, and plan for the parts that actually break rollouts: bots, squash merges, and key rotation.
Someone moved a production Git tag to a different commit. Why is that dangerous?
A release tag is a promise that a version name means one exact, unchanging set of code. Moving it breaks that promise everywhere at once: rollbacks, audits, incident timelines, and any pipeline that deploys by tag now point somewhere different from what people believe, and some clones won't even notice the change.
Your organization wants production deployments to be reproducible six months later. How does Git help?
Git pins the source exactly and that's all it pins. Real reproducibility also needs locked dependencies, versioned infrastructure, immutable artifacts, and a stored record linking a deployment to its digest, plus keeping the actual artifact, because rebuilding it later is rarely byte-identical.
Someone force-pushed main at 2 AM. How do you investigate?
Preserve evidence first, then answer four questions: what was main before, what is it now, who did it, and was anything deployed from the rewritten history. Treat it as potentially malicious until the audit log says otherwise, because a force-push at 2 AM is an unusual enough event to earn that default.
An attacker steals a developer's Git credentials and pushes malicious code. How do you defend against this?
Assume one credential will eventually be stolen and design so that alone isn't enough to ship code. Layer identity, branch protection, review, signing, pipeline isolation and detection, and remember the attacker's real target is usually the CI workflow, not the application code itself.
A company hires an external cost-optimisation vendor that needs read access to resources in the company's AWS account. The vendor runs from its own AWS account and serves many other customers. Which solution meets this requirement MOST securely?
Third-party access is an IAM role the vendor assumes from their own account, never an IAM user with access keys. The detail that separates a good answer from a nearly-good one is the external ID condition in the trust policy, which is what stops another of the vendor's customers from tricking them into acting on your account.
An application running on Amazon EC2 instances in an Auto Scaling group needs to read objects from an Amazon S3 bucket. The instances are replaced frequently as the group scales. Which approach for granting access requires the LEAST operational overhead?
Anything running on EC2 gets its permissions from an instance profile, not from credentials placed on the instance. The role is attached to the launch template, so every instance the Auto Scaling group creates is already authorised and there is nothing to distribute or rotate.
A compliance review finds that an existing Amazon EBS volume attached to a production EC2 instance is unencrypted. The data on the volume must be encrypted at rest with an AWS KMS key. Which sequence of steps achieves this?
You cannot turn encryption on for an existing EBS volume in place. The supported path is to snapshot it, copy the snapshot with encryption enabled, create a new volume from the encrypted copy, and swap it onto the instance.
An application on Amazon ECS connects to an Amazon RDS for PostgreSQL database using a username and password stored in the task definition as plaintext environment variables. Security policy now requires that the database password be encrypted at rest and rotated automatically every 30 days. Which solution meets these requirements with the LEAST operational overhead?
Secrets Manager is the service that rotates credentials for you, and it has built-in rotation for RDS. Parameter Store SecureString encrypts a value perfectly well but has no native rotation, so choosing it means writing and owning the rotation yourself.
A company uses AWS Organizations with all features enabled. For compliance reasons, workloads may only run in two approved AWS Regions. Account administrators in member accounts currently hold the AdministratorAccess policy. The company must prevent resources from being created in any other Region. What should a solutions architect do?
A service control policy is the only control that an account administrator cannot remove, because it caps what identities in a member account may do no matter what their IAM policies say. IAM policies and permissions boundaries can both be edited by the very administrators you are trying to constrain.
A public web application runs on Amazon EC2 instances behind an Application Load Balancer and is fronted by Amazon CloudFront. The application has been targeted by SQL injection attempts and by volumetric network floods. A solutions architect must reduce exposure to both. Which TWO actions should the architect take?
These are two different attacks and they need two different controls. AWS WAF inspects HTTP requests and stops injection attempts, while AWS Shield Advanced adds managed protection and cost protection against large network floods. Security groups and network ACLs operate below the layer where SQL injection is visible.
An audit discovers that several Amazon S3 buckets across a company's AWS accounts have been made publicly readable by developers. The company must guarantee that no bucket in any account can be made public, and must be alerted to any bucket policy that grants access outside the organization. Which combination of actions meets these requirements?
S3 Block Public Access enforced at the account level is the preventive control, and IAM Access Analyzer is the detective one. The pairing matters: the exam separates stopping something from noticing it, and this stem asks for both.
You need to grant a user permission to list nodes. Which object must the permission be defined in, and why?
Nodes are cluster-scoped, so permission on them can only be expressed in a ClusterRole, granted through a ClusterRoleBinding. A Role covers namespaced resources only.
True or false: you can stop a user who has been granted cluster-wide pod read access from reading Pods in one sensitive namespace by adding a Role in that namespace that denies it.
False. RBAC permissions are purely additive and there are no deny rules. To take access away you have to change or remove the binding that granted it.
A ClusterRole named pod-reader grants get, list and watch on pods. You create a RoleBinding in the dev namespace that binds this ClusterRole to user alice. What can alice do?
A RoleBinding that references a ClusterRole grants those permissions only inside the RoleBinding's own namespace. The same ClusterRole reused this way is how one definition serves many namespaces.
An application Pod needs to call the Kubernetes API using a ServiceAccount named deployer. How does the Pod get a token in a current cluster?
Setting serviceAccountName on the Pod is enough. The kubelet requests a short-lived, automatically rotated token through the TokenRequest API and mounts it as a projected volume.
A developer says Secrets are safe to commit to Git because Kubernetes encrypts them. What is the accurate correction?
Secret data is base64 encoded, not encrypted. Anyone with API or etcd access can read it, so protecting Secrets means RBAC plus encryption at rest, which is off by default.
You apply a NetworkPolicy that should block all ingress to a namespace, but every Pod stays reachable. kubectl get networkpolicy shows the object exists. What is the most likely explanation?
NetworkPolicies are enforced by the network plugin. If the cluster's CNI plugin does not implement them, the objects are accepted by the API server and have no effect.
Write the smallest NetworkPolicy that denies all ingress traffic to every Pod in a namespace. Which spec achieves it?
An empty podSelector selects every Pod in the namespace, and policyTypes: Ingress with no ingress rules allows nothing. That combination is the documented default-deny policy.
A NetworkPolicy ingress rule has one from entry containing both a namespaceSelector (user=alice) and a podSelector (role=client). Which traffic is allowed?
Selectors inside one from entry are combined with AND. Splitting them into two entries in the from list makes it OR, and that single dash is the whole difference.
A shared Gateway lives in the infra namespace. A team applies an HTTPRoute in their own namespace referencing that Gateway, and it is not accepted. What is required?
A Gateway only accepts routes from its own namespace by default. Attaching a route from elsewhere requires the Gateway's listener to permit it through allowedRoutes.
A Pod is scheduled to a node but its status reads CreateContainerConfigError. The image pulled fine. What class of problem is this, and where do you look?
The kubelet could not assemble the container's configuration, usually because a referenced ConfigMap, Secret or key does not exist. The Pod events name the missing object.
An application using the ServiceAccount ci in the build namespace gets a 403 listing Pods. Which command confirms the permission gap without deploying anything?
kubectl auth can-i with --as impersonates the identity and answers yes or no against the real authorization layer, so you can test a ServiceAccount's access from your own session.